101–110 of 110 posts
Windows should just prompt for confirmation if the file differs. A reg key should allow a user to disable the confirmation.
Windows 7 does have a delete confirmation for Undo Copy. However, either Windows 8 or 10 removed that confirmation. More reason why people missed Windows 7.
Earlier quoted context omitted.
Can confirm this is how macOS does it. They remove the file from the stack of Undo actions after it's been modified post-copy.
MacOS also doesn’t let you cut a file and then lose it by accidentally copying something else to the clipboard, because to “cut and paste” you copy, then use option-command-v to move the file instead of copying. I think this mistake is usually recoverable in Windows, but
This mistake is usually unrecoverable but sometimes not, when you’re in file explorer but it’s not a normal file explorer view. For example, when viewing the images of an attached iPhone.
Earlier quoted context omitted.
Excel is a law unto itself. The 'feature' that irritates me the most is how a cell copy is forgotten unless you paste immediately. Bear in mind that this is an application so iconoclastic that it had its own C compiler.
Own C compiler? IIRC, that's not quite true. I worked on the C/C++ compiler team at Microsoft from 1991 to 2007, and I don't remember us producing a drop of the compiler just for Excel. I do think there was a special compiler flag for them, though, that fixed the order in which global variables were laid out to duplicate the source order. It was either Excel or Word that saved state by taking the addresses of the fir…
Earlier quoted context omitted.
They may be referring to a telephone version of the story that excel was originally compiled to p-code for compactness.
That sounds reasonable. I'd forgotten about the p-code version. I think that was dead by the time I started. I was also fortunate enough to avoid working on the 16-bit compiler backend, and just worked on the 32-bit, referred to internally as the n386 backend, which was pretty much a complete rewrite. The p-code backend would have been a variant of the 16-bit version.
I treat every file that's important to me the same when I have to edit it, I hit save first, then edit what needs attention. After making any change more then a few minutes of work, hit save. Undo is always the last option. I am a terribly slow typist, so this is a habit I formed many years ago.
No amount of hitting save would have saved the author here
Earlier quoted context omitted.
As a daily Excel power user, I'd prefer to just know that there is one expected behaviour, and not to be bothered by a context window. The fact that ctrl-z just changes context to the other workbook is enough notification in itself, and I can just ctrl-y otherwise.
Wouldn't it be a good compromise to ask you on the first occurrence?
Earlier quoted context omitted.
That sounds reasonable. I'd forgotten about the p-code version. I think that was dead by the time I started. I was also fortunate enough to avoid working on the 16-bit compiler backend, and just worked on the 32-bit, referred to internally as the n386 backend, which was pretty much a complete rewrite. The p-code backend would have been a variant of the 16-bit version.
The 'own C compiler' is from Joel Spolsky from when he worked at Microsoft: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-... . And indeed this states that it was p-code. I'm old enough to remember when p-code was - briefly - a very hot idea.
So p-code wasn't actually dead when I started, but instead shipped with the C/C++ 7.0 compiler, which predated Visual C++. I never worked on C7, since that was 16-bit, and p-code wasn't part of any 32-bit compiler, as I recall.
[1] https://techshelps.github.io/MSDN/BACKGRND/html/msdn_c7pcode...
Earlier quoted context omitted.
It makes sense if you accidentally paste somewhere to immediately be able to undo. But, just like in a text editor, undo should undo the most recent change. Once a copied file has edits, the copy operation isn't most recent, so that's not what should be undone. Of course, file explorer would need to be aware of changes to files it hadn't made for this to work.
i guess simple check for file size and last modification would do the job
Or instead of adding even more code, they could remove the feature and let the user Delete the copy.
"Undo copy" seems like it should not even exist. Delete does the same. Seems like the result of trying to hard to "improve" the UI.
It makes sense if you accidentally paste somewhere to immediately be able to undo. But, just like in a text editor, undo should undo the most recent change. Once a copied file has edits, the copy operation isn't most recent, so that's not what should be undone. Of course, file explorer would need to be aware of changes to files it hadn't made for this to work.
Earlier quoted context omitted.
Excel is a law unto itself. The 'feature' that irritates me the most is how a cell copy is forgotten unless you paste immediately. Bear in mind that this is an application so iconoclastic that it had its own C compiler.
One program that does copying right IMO is tmux, it keeps a list of recently copied things, which you can view by pressing Ctrl-B = and choose which clipboard to paste. Very useful when you need to copy multiple separate strings without going back and forth between windows. I've caught myself doing optimistic copying - if I see something that i might need to paste in the future, like git commit hashes, file names, et…