What Emacs got right, or how modern apps were more like 50 year old text editor | Hacker News Reader

What Emacs got right, or how modern apps were more like 50 year old text editor

danielde.dev

31 pointsasicsp16 comments

We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have become an OS with many fine features - simply lacking a good web browser.

>“Why are windows called frames, and tabs called windows?”

Windows are called frames in Emacs, yes, but it is panes, not tabs, that are called windows. Tabs are called buffers. (More precisely, the closest analog to a browser tab is an Emacs buffer, and a tab in VSCode is an almost-perfect analog to a buffer in Emacs.)

Keep in mind that modern Emacs also has tabs out of the box, but really they're what other software calls 'workspaces'.

>Scripting Emacs in small ways is really easy and really useful

While I agree, for some reason I have a hard time with lisp, will have to revisit again :)

But I do use emacs a bit of 50% of the time for development and I find it better than the fancy code environments like M/S VScode

everything is a command. If you don't like what that command does, monkeypatch it. Congrats, you're not a user any more, and never were.

I wonder what an alternate timeline would look like if Microsoft has used Emacs as the foundation for Visual Studio Code? Would extensions be easier to write? Would Emacs get a lot more commands rewritten as asynchronous?

Without the "I wish," that title doesn't make any sense.

Yeah, sorry. I was trying to fit the title to the character limit and messed it up!

Honestly, the real meat of Emacs is in buffer/split management. If VSCode did those well, then maybe I’d consider switching lol

> I won’t lay this on too thick, but keeping your hands entirely on the keyboard allows for a fluency that is unmatched when you’ve sometimes got to reach for a mouse instead. And there’s additional trust I can place in Emacs knowing that it’s always a matter of finding the way to do something with the keyboard, rather than wondering if it’s possible at all.

Here we go again. From https://ux.stackexchange.com/questions/30682/are-there-any-r... :

> We've done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts: — Test subjects consistently report that keyboarding is faster than mousing. - The stopwatch consistently proves mousing is faster than keyboarding.

> Previous research comparing methods of issuing commands found that selecting a toolbar item is faster than selecting an item from two menus with either a mouse or keyboard shortcut. Over the course of 90 trials, however, the keyboard method showed the most improvement, nearing the toolbar response time.

> In contrast, a more recent study [10] suggests that more complex key sequences do not have such a clear advantage over toolbar selection.

TL;DR: Keyboard shortcuts are faster for some actions some of the time, but using the mouse vs keyboard is mostly preference

> The stopwatch consistently proves mousing is faster than keyboarding.

I've heard this before. An obvious problem with the claim is that a stopwatch doesn't measure distraction. It might take longer to use the keyboard for a task, but using the mouse introduces a number of other things like moving off the keyboard, grabbing the mouse, figuring out where the cursor is, etc.

It's kind of like a colleague asking a "30 second question". It's only 30 seconds if you don't count the cost of the distraction.

That's a weak response because unlike answering a question from a coworker, "moving off the keyboard, grabbing the mouse, figuring out where the cursor is," then moving the cursor are all "perceptual" tasks that most people can do without disturbing the "cognitive" tasks involved in programming or communication.

But (zooming out now) many users of Emacs use the mouse a lot and do not make any attempt to keep their hands on the keyboard: in a survey of Emacs users, 80% responded that they use graphical Emacs (Emacs not running in or communicating with a terminal), one of the main advantages of which is that the mouse behaves much like it does in a typical GUI app. I use graphical Emacs exclusively (the code I've written to extend Emacs does not even work right in terminal-based Emacs) and I make extensive use of the mouse, the menu bar and a pop-up menu on my right mouse button.

Are you surprised that 80% of Emacs users use graphical Emacs? That is probably because for some unknown reason, users (Emacs users and user in general) who like to always keep their hands on the keyboard are much more vocal than users who alternate frequently between keyboard and a pointing device. One consequence of this is that although VSCode has the majority of the usage share according to all the surveys, there are many more HN comments extolling the benefits of Vim or Emacs than there are pro-VSCode comments.

> unlike answering a question from a coworker, "moving off the keyboard, grabbing the mouse, figuring out where the cursor is," then moving the cursor are all "perceptual" tasks that most people can do without disturbing the "cognitive" tasks involved in programming or communication

I explained why $50 million spent measuring how long it takes to do a task isn't measuring the right thing, and therefore doesn't support the claim that users are wrong. You're telling me your opinion, which of course you're entitled to have, but that doesn't fix the flawed claims of the research.

> Are you surprised that 80% of Emacs users use graphical Emacs?

No.

> users who like to always keep their hands on the keyboard are much more vocal than users who alternate frequently between keyboard and a pointing device

This has no relevance to my comment, which is that the research didn't measure what it needed to measure, and therefore one should not conclude that users have been proven wrong.

That article claims that exactly the same thing but swapped:

> People new to the mouse find the process of acquiring it every time they want to do anything other than type to be incredibly time-wasting. And therein lies the very advantage of the mouse: it is boring to find it because the two-second search does not require high-level cognitive engagement.

> It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. Not only is this decision not boring, the user actually experiences amnesia! Real amnesia! The time-slice spent making the decision simply ceases to exist.

> While the keyboard users in this case feels as though they have gained two seconds over the mouse users, the opposite is really the case.

That's still focused exclusively on the time spent doing the task. Maybe a more extreme example will clarify why the methodology was seriously flawed. Suppose there's a bug in the app such that it frequently crashes shortly after using the mouse. You have to restart the app and reload the data after every crash.

We can all agree that using the mouse is not faster than the keyboard if you have a bug like that. 100% of users would say that using the keyboard is faster. Yet their methodology would lead to exactly the same conclusion that users are wrong and $50 million of research has shown it's faster to use the mouse. Assuming "all else equal" when it's not can lead to really bad decisions.

> That's still focused exclusively on the time spent doing the task.

What do you think the sentence “acquiring it every time they want to do anything” means? Buying it from the store??

Reply on news.ycombinator.com