A similar annoyance is the fact that excel's undo applies to all open excel files. Make a change in a.xls, make a change in b.xls. if you ctrl-z twice with b.xls focused, it'll undo both of the above changes!
This has bitten me more than once. Does anyone actually want this behavior?
I ran into this issue and looked it up. It was an intentional design choice, and kind of makes sense when you realize that Excel sheets can have reference of each other -- they are not necessarily independent. Of course a lot of people probably never do that in their entire lifetime when using Excel and can feel annoying.
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.
No, because I get the point about context very, very quickly. I can’t imagine anything worse than being asked every time when I know exactly what’s going to happen.
It's for when you want to have distributed data stores.
For example, if you're building out a doc to track your net worth, income, and spending habits:
- One main sheet that collates all the data required here (e.g. credit card statements, in-flows and out-flows from bank accounts, current debts and current assets)
- Have 3 more docs:
One that collates and summarizes your credit card charges
One that collates your bank statements
One that collates your assets and liabilities
///
Let's say my "credit card charges" sheet automatically pulls in my charges over API, and appends them to the "Charges" sheet in the "Credit Card.xls." Then the "Summary" sheet in this "Credit Card.xls" summarizes this information into something useful. My "Main.xls" (that collates all of my data into something even more readable and useful) can then pull data from this "Credit Card.xls" sheet (through API or locally), and automatically keep itself updated.
I could stuff this all into one single doc, with numerous sheets, but I don't want to deal with the cognitive overhead of having to navigate through an enormous amount of sheets I rarely (if ever) need to touch (again).
Perhaps I don't even have access to the physical "Credit Card.xls" doc, because my personal assistant automatically appends to it, and keeps it uploaded somewhere.
I could stuff this all into one single doc, with numerous sheets, but I don't want to deal with the cognitive overhead of having to navigate through an enormous amount of sheets I rarely (if ever) need to touch (again).
So instead, everybody else has to deal with the cognitive overhead of a document model that is used by no other mainstream PC software program known to Man.
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.
This is the thing with Excel. It has such a long history that it had to invent a ton of GUI interactions. A boatload of those interactions were codified in Excel before we created standard ways of doing things that even macOS, Windows and Linux share. In that sense, the modern history of Excel is the slow regression of the app to OS conventions.
For the longest time, Excel had its own windowing system within the app. It's only recently that the Office team saw the light and let the whole OS called Windows control window management in Excel.
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 first and last global variables of interest, then dumping all memory in that range to disk. The flag was something like -bzalign. The bz stood for Bozo, which hints at the compiler team's thoughts on the practice.
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.
I know we shipped p-code for general usage, not just internal like Excel. But it might have been internal-only in the mid to late 80s. I found a link [1] talking about some p-code internals, from April 1992, by the guy who hired me at Microsoft about a year before that. The compiler team definitely viewed Excel as one of their most important customers, and were willing to do lots of work to satisfy them.
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.
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, etc. I just copy them all and store them in the clipboard list.
I think there is a program "clipmenu" which does this for X11, but haven't used it too much.
This is my must have extension. Gnome has one and there's an app for that on MacOS. Multiple clipboard entries are such a trivial but useful change that I can't go back to the old way anymore
I'm continually bewildered by some of Excel's design choices. You can't have two files with the same filename open at the same time even if the files are in different directories. And you can't, for some reason, save to a path with square brackets in it. (You can save it with round brackets, rename the file, and then load the file perfectly fine, though.)
I think Excel is still the old mdi application that has been hacked to look like a sdi application. It’s only a recent innovation that it is possible to have two files open with the same filename.
I haven't used Excel much in the past decades but I'm surprised to see the undo behaviour remaining unchanged. Next time you tell me 1904 date formatting is still a thing...
Excel has several UI quirks that date back decades. It's never been consistent with the rest of Office even. If Microsoft changed it the accountants would revolt.
You can expect data to be destroyed when automatically parsing csv/tsv (default behaviour), especially because it's dependent on the last settings used in the text-to-columns wizard.
Then there's all well-known bugs like floating point addition and locale-dependent function names and 1904 dates.
Conditional formatting accidentally pasting is all over the place.
As others have mentioned, copying and pasting in Excel is bizarre. Highlight the cells to copy; select copy - the source cells now have marching ants around them; perform any action that causes the marching ants to disappear and that content can no longer be pasted. It’s as if those cells are locked as the copy buffer as opposed to some in memory copy like every other copy operation.
This has bitten me more than once. Does anyone actually want this behavior?