5 ms·

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn

by toomim 6y ago

I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". It has weird keyboard shortcuts. Every third command also copies to the clipboard as a side-effect, which means you constantly obliterate the contents of the clipboard while getting ready to paste what you thought was there. Oh, but to address this problem, it makes the clipboard into a ring of clipboards, so that when you replace the clipboard with something else, you can still access the other clipboards in a ring by hitting the paste command multiple times in a row. Oh, but if you press another key in between, you get lost in clipboard madness. Emacs also has an "undo", but no "redo" command. Except that when you "undo", it actually pushes the "undo" itself onto the list of "things to undo", so that you can undo that undo, in order to redo. But people also need to undo multiple undos before getting interrupted with a redo, so Emacs only undoes the undos if you press some other key after undoing a few dos in a row. But hey, this means it doesn't need a "redo" command. So, I agree that the elisp runtime is a weird thing about Emacs, and something that is rational to change. But the thing is... if you're going to change that... why not everything else about Emacs? I mean, at some point Emacs looks a lot like Bitcoin Core, or Wikipedia -- a beautiful historical community with weird consensus rules that flowered into a very exotic, strange, and usually-functional artifact. Although sometimes it doesn't work as well as the newer technologies.

shadowgovt 6y ago
it is fascinating to see how (particularly in older software / systems) radically different decisions were made about what is nowadays considered "fundamental" UX, and to imagine what the world would have been like if this other thing happened to become the consensus standard. Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. Quite internally consistent; a bear to get into if you learned 3DS Max or Maya first.
- outworlder 6y ago
  > Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.
  - shadowgovt 6y ago
    I use Blender all the time; it's a great tool. What I mean is that its default keybindings, UI manipulation metaphors, etc. are notably different from the applications that live closer to 3DSMax and Maya on the family tree of 3D editors. * Moving an object in Blender: Select, press 'G', now the mouse floats the object without the need to hold a mouse button down, optionally hit 'x', 'y', or 'z' to constrain to those axes. You can also take advantage of the 3D cursor. * Moving an object in 3DS Max: Select to bring up manipulation widgets, click and drag the image of the widgets to move the object. Starting to learn Blender if you learned 3D scene creation in Max is like starting to use emacs if you learned word processing in Microsoft Word. The metaphors aren't categorically better or worse; they're very different.
skissane 6y ago
> But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. (Unlike Emacs, vim doesn't have the "frame" concept, because vim doesn't appear to support multiple GUI windows.)
- bitwize 6y ago
  > Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer. That's the metaphor people are used to. It may not make sense, but saying "well, ackshually, files refer to the copies on disk while buffers refer to the copies in memory" just confuses people more. Have we learned nothing since Macintosh 1984? Actually, we haven't; we've gone backwards. The spatial Finder was based on very deep psychological notions of how humans relate to the world: through spatial orientation and object manipulation. Meaning that there is only one place on the screen where a given file appears, and it appears at the same place every time unless the user moves it. In short, it works like an actual desktop with real physical pieces of paper. And Apple brushed it aside in favor of NeXT's Unixoid "file manager". > Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. Again, it doesn't matter. The ordinary user's concept of a "window" maps directly to a GUI window, so if you expect your program to be used in a graphical environment without confusing the shit out of people, you need to adopt that environment's terms and concepts. Meet. Your. Users. Where. They. Are.
throwanem 6y ago
You're underplaying your hand, you know. Why leave out that cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else, and can't be rebound to match muscle memory in any way that's really useful? I mean - if you're going to ignore everything that makes Emacs great on your way to cavil about how it's different, why not go all out, right?
- hvis 6y ago
  > cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else Try `C-w`, `C-k` and `C-y` inside a Bash shell sometime, you might be surprised. `M-w` is an exception, though.
  - throwanem 6y ago
    Oh, interesting. I knew about C-s and C-r there, and knew C-k as kill to end of line, but didn't know yank worked there too - thanks for the tip!
hnedeotes 6y ago
I like emacs, and I'm not a lisp wizard, but it's an amazing editor and sure it has problems (long lines can grind you, although I've never halted emacs even with gb single line files - I did have to kill buffers though, and there's probably other things, on the other hand, I did grind plenty of other editors with much less) but... > Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows" Well, as someone pointed out, buffers are buffers, files are files, why would your editor try to fool you regarding the fact that what you have in front of you is in a buffer (that might be persisted into a file) and not exactly a file? Every buffer tells you if it's pointing to some file... Frames aren't windows. Like tabs in a browser aren't browsers or windows either? > It has weird keyboard shortcuts. Yeah, the worse part of it all is you can't even change them, right? > Oh, but if you press another key in between, you get lost in clipboard madness. Yeap sometimes that happens, on the other hand the times it doesn't and you can cycle through things in ways that are not easy to do in other editors is great. > Emacs also has an "undo", but no "redo" command This ties back to the ring design? You can switch the direction you're going with two key-strokes. Granted, if you change the buffer (outside of just navigating the ring or copying into buffer, save, etc) then it does get weird, but it's usually pretty consistent and useful. It's like having a step by step git to your inputs into the buffer. But `this`, this, this: > I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. If the JS runtime, with the million of hours and $ poured into it to make it performant at the runtime engine, libraries and general language improvement, when compared to others created decades ago (and mostly voluntarily kept) didn't have an edge in some things, it would probably be the biggest facepalm in programming history ever. Having said all this, I'm happy people keep experimenting and building stuff for others to use, even if in JS, or Rust, or Zig, or brainfuck.
hvis 6y ago
> Emacs also has an "undo", but no "redo" command They don't have default bindings (unfortunate), but try installing a recent build of Emacs 28 and binding these commands to the keys of your choice: - undo-only - undo-redo

by toomim 6y ago

shadowgovt 6y ago

it is fascinating to see how (particularly in older software / systems) radically different decisions were made about what is nowadays considered "fundamental" UX, and to imagine what the world would have been like if this other thing happened to become the consensus standard. Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. Quite internally consistent; a bear to get into if you learned 3DS Max or Maya first.

outworlder 6y ago
> Blender is, I think, another example of this... It's quite good, but relative to the other 3D editing tools available, it has an absolute space-alien UI. When did you last start Blender? This used to be true. Nowadays it's at least on par with commercial tools if not better.
- shadowgovt 6y ago
  I use Blender all the time; it's a great tool. What I mean is that its default keybindings, UI manipulation metaphors, etc. are notably different from the applications that live closer to 3DSMax and Maya on the family tree of 3D editors. * Moving an object in Blender: Select, press 'G', now the mouse floats the object without the need to hold a mouse button down, optionally hit 'x', 'y', or 'z' to constrain to those axes. You can also take advantage of the 3D cursor. * Moving an object in 3DS Max: Select to bring up manipulation widgets, click and drag the image of the widgets to move the object. Starting to learn Blender if you learned 3D scene creation in Max is like starting to use emacs if you learned word processing in Microsoft Word. The metaphors aren't categorically better or worse; they're very different.

skissane 6y ago

> But dynamic scope, and e-lisp, isn't the only thing weird about Emacs. Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows". Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. (Unlike Emacs, vim doesn't have the "frame" concept, because vim doesn't appear to support multiple GUI windows.)

bitwize 6y ago
> Using "buffer" as a name for text being edited is hardly worthy of the title weird, vim does it too. Lots of other text editors as well. "Buffer" != "file", the first exists in the memory of the text editor process, the second exists on the file system. Their contents may differ, and one may exist without the other. It doesn't matter. When people talk of editing documents in Word, they speak of opening a file, not a buffer. That's the metaphor people are used to. It may not make sense, but saying "well, ackshually, files refer to the copies on disk while buffers refer to the copies in memory" just confuses people more. Have we learned nothing since Macintosh 1984? Actually, we haven't; we've gone backwards. The spatial Finder was based on very deep psychological notions of how humans relate to the world: through spatial orientation and object manipulation. Meaning that there is only one place on the screen where a given file appears, and it appears at the same place every time unless the user moves it. In short, it works like an actual desktop with real physical pieces of paper. And Apple brushed it aside in favor of NeXT's Unixoid "file manager". > Likewise, calling the subdivisions of the screen "windows" is something which vim does too, and likely other editors also. For a text mode editor, it makes perfect sense. When you then port such an editor to a GUI, you end up with "windows" which are subdivisions of the GUI "window" – vim has that too, not just emacs. Again, it doesn't matter. The ordinary user's concept of a "window" maps directly to a GUI window, so if you expect your program to be used in a graphical environment without confusing the shit out of people, you need to adopt that environment's terms and concepts. Meet. Your. Users. Where. They. Are.

throwanem 6y ago

You're underplaying your hand, you know. Why leave out that cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else, and can't be rebound to match muscle memory in any way that's really useful? I mean - if you're going to ignore everything that makes Emacs great on your way to cavil about how it's different, why not go all out, right?

hvis 6y ago
> cut, copy, and paste have keyboard shortcuts in Emacs that are used nowhere else Try `C-w`, `C-k` and `C-y` inside a Bash shell sometime, you might be surprised. `M-w` is an exception, though.
- throwanem 6y ago
  Oh, interesting. I knew about C-s and C-r there, and knew C-k as kill to end of line, but didn't know yank worked there too - thanks for the tip!

hnedeotes 6y ago

I like emacs, and I'm not a lisp wizard, but it's an amazing editor and sure it has problems (long lines can grind you, although I've never halted emacs even with gb single line files - I did have to kill buffers though, and there's probably other things, on the other hand, I did grind plenty of other editors with much less) but... > Emacs also calls "files" "buffers", and calls "windows" "frames" and "frames" "windows" Well, as someone pointed out, buffers are buffers, files are files, why would your editor try to fool you regarding the fact that what you have in front of you is in a buffer (that might be persisted into a file) and not exactly a file? Every buffer tells you if it's pointing to some file... Frames aren't windows. Like tabs in a browser aren't browsers or windows either? > It has weird keyboard shortcuts. Yeah, the worse part of it all is you can't even change them, right? > Oh, but if you press another key in between, you get lost in clipboard madness. Yeap sometimes that happens, on the other hand the times it doesn't and you can cycle through things in ways that are not easy to do in other editors is great. > Emacs also has an "undo", but no "redo" command This ties back to the ring design? You can switch the direction you're going with two key-strokes. Granted, if you change the buffer (outside of just navigating the ring or copying into buffer, save, etc) then it does get weird, but it's usually pretty consistent and useful. It's like having a step by step git to your inputs into the buffer. But `this`, this, this: > I agree that using a JS runtime makes more sense that Emacs's weird e-lisp runtime, with all of its dynamic-scope weirdness. If the JS runtime, with the million of hours and $ poured into it to make it performant at the runtime engine, libraries and general language improvement, when compared to others created decades ago (and mostly voluntarily kept) didn't have an edge in some things, it would probably be the biggest facepalm in programming history ever. Having said all this, I'm happy people keep experimenting and building stuff for others to use, even if in JS, or Rust, or Zig, or brainfuck.

hvis 6y ago

> Emacs also has an "undo", but no "redo" command They don't have default bindings (unfortunate), but try installing a recent build of Emacs 28 and binding these commands to the keys of your choice: - undo-only - undo-redo