Hacker News Reader

Comment by cka | Hacker News Reader

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?

View on HN

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.

Sheets or docs?

Within one doc, and multiple sheets makes sense, I guess.

Across docs doesn’t make sense to me.

You can definitely reference cells across workbooks

Docs.

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.

If the point is to only have to work with one doc, then undo across docs is still not useful.

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.

They could solve that by keeping track of references and asking you though.

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?

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.

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.

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

notepad++ has this feature, and I think current windows versions do as well

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.

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.

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.

[1] https://techshelps.github.io/MSDN/BACKGRND/html/msdn_c7pcode...

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.)

All of that sounds perfectly sensible.

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.

They fixed that "same file name" annoyance? We have Office 2021(?) at work and it still has that "feature".

That must be a very recent change - I'm sure I've run into that limitation not more than a few months ago.

You can work around this by starting a fresh instance of Excel. Run -> "Excel.exe /x"

Excel is an MDI app pretending to have one document per window. It still has the unified undo buffer from that architecture.

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 is the archetypal backwards compatible program.

Since Windows 11 includes extensive telemetry, it is possible that Microsoft intentionally designed it this way for user productivity.

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.

do you have some examples of that quirks?

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.

It is neither copy nor paste. The copy is "remember this as reference" and paste is "do to this cell to make it relatively similar to the other".

Cut and paste is even better. If the cell to be cut is being referenced, the referencing cell can magically update to the place to paste to.

Selecting and copying the /content/ of a cell is a very normal copy and paste operation.

> If Microsoft changed it the accountants would revolt.

What's stopping other trades from forming a similarly powerful lobby, like accountants seem to have?

Reply on news.ycombinator.com