4 ms·

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

31 points by asicsp 2y ago

drewcoo 2y ago
Without the "I wish," that title doesn't make any sense.
- asicsp 2y ago
  Yeah, sorry. I was trying to fit the title to the character limit and messed it up!
deleted 2y ago
[deleted]
superkuh 2y ago
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.
hprotagonist 2y ago
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.
subjectsigma 2y ago
> 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-recent-studies-of-the-keyboard-vs-mouse-issue 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
- bachmeier 2y ago
  > 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.
  - hollerith 2y ago
    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.
    - bachmeier 2y ago
      > 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.
bloopernova 2y ago
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?
hollerith 2y ago
>“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.)
- alt0_ 2y ago
  Keep in mind that modern Emacs also has tabs out of the box, but really they're what other software calls 'workspaces'.
jmclnx 2y ago
>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
djaouen 2y ago
Honestly, the real meat of Emacs is in buffer/split management. If VSCode did those well, then maybe I’d consider switching lol

31 points by asicsp 2y ago

drewcoo 2y ago

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

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

deleted 2y ago

[deleted]

superkuh 2y ago

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.

hprotagonist 2y ago

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.

subjectsigma 2y ago

> 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-recent-studies-of-the-keyboard-vs-mouse-issue 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

bachmeier 2y ago
> 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.
- hollerith 2y ago
  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.
  - bachmeier 2y ago
    > 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.

bloopernova 2y ago

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?

hollerith 2y ago

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

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

jmclnx 2y ago

>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

djaouen 2y ago

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