3 ms·

Good points, but rn it seems that Emacs is playing a game of catching up. Thinks like LSP integration, tree-sitter are coming now but it's still really rough. I

Good points, but rn it seems that Emacs is playing a game of catching up. Thinks like LSP integration, tree-sitter are coming now but it's still really rough. I'm glad they are! But we're not there yet.

pritambaral 4y ago
Merging into core is not really needed for a feature; it just bakes it in. That's the point of emacs: it's made to be extended, no need to draw a line between a user and a developer. LSP integration has been available for very long time, just not from the core emacs repo. For example, Ubuntu does not ship with Blender, because no official build of Ubuntu is available with Blender pre-installed in the iso, but that doesn't mean Blender is not available on Ubuntu. Emacs is a lot like that. Similarly for tree-sitter. Available as a package for a while, only now also available built-in. An Emacs release is not needed to get a feature in Emacs.
- NeutralForest 4y ago
  I just don't agree, a text editor/IDE should have user ergonomics in mind. The fewer steps there are between your spinning the IDE and having a working setup, the better it is for the end user. Extensibility is important and useful but it also comes at a heavier mental load for users because it introduces complexity, and Emacs is already complex enough imo.
  - tazjin 4y ago
    > The fewer steps there are between your spinning the IDE and having a working setup What you're overseeing here is that Emacs configurations are usually highly individual, and that "a working setup" for _you_ does not mean the same as it does for _me_. For example, regarding LSPs, I only use them in very rare cases because usually LSP implementations themselves (regardless of the editor you use them in) are buggy and/or slow. For me it's much more important that the actual _text editing_ experience is consistent across languages, than the tooling for any particular language.
    - NeutralForest 4y ago
      I just disagree with this view, lots of people use it to code. It should be easy to setup a coding environment with it. That's all I mean.
      - _a_a_a_ 4y ago
        Long term emacs user, and I agree. I need to learn to program it but more importantly, I should be able to install a package and have it work because I use emacs for just that - work. There's too much 'add this include your .emacs' etc. But it's getting better.
      - pritambaral 4y ago
        > I just disagree with this view, lots of people use it to code. I agree. It wasn't obvious to me, at first, that Emacs is not a code editor, rather just a Lisp program for editing lots of text. And I didn't even know what Lisp was at the time, so it wouldn't have helped either way. But ... > It should be easy to setup a coding environment with it. It kinda is. I started using Emacs with just a Spacemacs install. And I didn't need to learn anything about Emacs for a long time after that. It was only when Spacemacs stopped being maintained, and I started facing issues due to that, that I looked deeper. It helped that I had learned what Lisp is (Common Lisp, though, not Emacs Lisp) for it to finally click, so I got lucky that way. Now, even when I know Emacs (and Emacs Lisp) rather well, I still stick to Doom Emacs to "setup a coding environment with it".
      - celeritascelery 4y ago
        The Emacs frameworks (doom, spacemacs, etc) make it pretty easy to setup. That being said, if your primary concern is ease, vscode would be a better choice. Emacs is more focused on power and extensibility.
        NeutralForest 4y ago
        I know, I'm using Emacs everyday. And I dislike the frameworks because they obfuscate what's going on in Emacs, at least to me. I just think that since we're pushing features like eglot or tree-sitter to core, we should also focus on making them easy to use.
  - Forge36 4y ago
    It's a text editor first. I'm not using it for code. I'm using it for magit and org-mode
  - yaantc 4y ago
    It's a reasonable position for most text editors / IDE, but not a good fit for Emacs IMHO. Emacs is atypical here. Emacs is best understood as an editor construction kit with a default editor as an example. It's a "build your own editor" Lisp environment. And it's really more "text based applications" rather than just editor. Add some support for images and SVG on top too, although it's not as central as text. Nobody fully build its own Emacs variant of course, there's a lot in the core Emacs (with a surprising amount of features disabled/hidden by default!) and it's most of anyone Emacs variant. Still, the approach of putting up one's "own" Emacs is important. I'm using over 50 packages, with a ~100 kB init file and Emacs distros are way above this I guess. The basic experience is if I want something to work some way, I'll look for supporting package(s) and tune them as I want, or much more rarely write some Elisp. Making Emacs more approachable to newcomers is a recurring discussion in the Emacs world. For historical reasons there's a barrier, as Emacs predates a lot of things (GUI windows so in Emacs a "window" is what's a text pane in other editors, Ctrl-X/C/V so it's C-w/M-w/C-y in Emacs, etc.). Changing this would be disruptive to current users, and Emacs puts a lot of weight on being backward compatible. It's not possible to please everyone here. In the end, I don't think Emacs "alieness" is a problem. The differences are rather superficial and easy to learn (with some motivation). For people not interested in this, there are plenty of alternate editors that focus on being user friendly, and it's perfectly fine. Choice is good. Much more important to the Emacs experience is the ease of customization and adaptation. The Lisp environment is a big part of this: once you know the basics the embedded documentation is very extensive and always accessible. It's trivial to get the documentation on any function or variable, and go to its source code. It's also straightforward to adjust any behavior. There is no difference between core elisp code and the user code. Changes to the core are done in a conservative way to avoid breaking all the current users customization (there are breaking changes, but with early obsolescence warnings and good change documentation). All this is a much more important part of Emacs than the early experience. It's also quite specific to Emacs, I'm not sure there are many alternatives? If any, they're also "not so user friendly" (like neovim with Lua now?). In summary, there's a tradeoff being first user experience, backward compatibility with such a long history, and flexibility to accommodate very different needs and use-cases (some of them incompatible). Emacs has a specific situation here. It may not be to everyone taste, but it's OK: there are plenty other alternatives. There's a thriving community, improvements have never been as speedy. I'm a happy user seeing no reason to change, on the contrary: I really feel it's getting better and better!

pritambaral 4y ago

Merging into core is not really needed for a feature; it just bakes it in. That's the point of emacs: it's made to be extended, no need to draw a line between a user and a developer. LSP integration has been available for very long time, just not from the core emacs repo. For example, Ubuntu does not ship with Blender, because no official build of Ubuntu is available with Blender pre-installed in the iso, but that doesn't mean Blender is not available on Ubuntu. Emacs is a lot like that. Similarly for tree-sitter. Available as a package for a while, only now also available built-in. An Emacs release is not needed to get a feature in Emacs.

NeutralForest 4y ago
I just don't agree, a text editor/IDE should have user ergonomics in mind. The fewer steps there are between your spinning the IDE and having a working setup, the better it is for the end user. Extensibility is important and useful but it also comes at a heavier mental load for users because it introduces complexity, and Emacs is already complex enough imo.
- tazjin 4y ago
  > The fewer steps there are between your spinning the IDE and having a working setup What you're overseeing here is that Emacs configurations are usually highly individual, and that "a working setup" for _you_ does not mean the same as it does for _me_. For example, regarding LSPs, I only use them in very rare cases because usually LSP implementations themselves (regardless of the editor you use them in) are buggy and/or slow. For me it's much more important that the actual _text editing_ experience is consistent across languages, than the tooling for any particular language.
  - NeutralForest 4y ago
    I just disagree with this view, lots of people use it to code. It should be easy to setup a coding environment with it. That's all I mean.
    - _a_a_a_ 4y ago
      Long term emacs user, and I agree. I need to learn to program it but more importantly, I should be able to install a package and have it work because I use emacs for just that - work. There's too much 'add this include your .emacs' etc. But it's getting better.
    - pritambaral 4y ago
      > I just disagree with this view, lots of people use it to code. I agree. It wasn't obvious to me, at first, that Emacs is not a code editor, rather just a Lisp program for editing lots of text. And I didn't even know what Lisp was at the time, so it wouldn't have helped either way. But ... > It should be easy to setup a coding environment with it. It kinda is. I started using Emacs with just a Spacemacs install. And I didn't need to learn anything about Emacs for a long time after that. It was only when Spacemacs stopped being maintained, and I started facing issues due to that, that I looked deeper. It helped that I had learned what Lisp is (Common Lisp, though, not Emacs Lisp) for it to finally click, so I got lucky that way. Now, even when I know Emacs (and Emacs Lisp) rather well, I still stick to Doom Emacs to "setup a coding environment with it".
    - celeritascelery 4y ago
      The Emacs frameworks (doom, spacemacs, etc) make it pretty easy to setup. That being said, if your primary concern is ease, vscode would be a better choice. Emacs is more focused on power and extensibility.
      - NeutralForest 4y ago
        I know, I'm using Emacs everyday. And I dislike the frameworks because they obfuscate what's going on in Emacs, at least to me. I just think that since we're pushing features like eglot or tree-sitter to core, we should also focus on making them easy to use.
- Forge36 4y ago
  It's a text editor first. I'm not using it for code. I'm using it for magit and org-mode
- yaantc 4y ago
  It's a reasonable position for most text editors / IDE, but not a good fit for Emacs IMHO. Emacs is atypical here. Emacs is best understood as an editor construction kit with a default editor as an example. It's a "build your own editor" Lisp environment. And it's really more "text based applications" rather than just editor. Add some support for images and SVG on top too, although it's not as central as text. Nobody fully build its own Emacs variant of course, there's a lot in the core Emacs (with a surprising amount of features disabled/hidden by default!) and it's most of anyone Emacs variant. Still, the approach of putting up one's "own" Emacs is important. I'm using over 50 packages, with a ~100 kB init file and Emacs distros are way above this I guess. The basic experience is if I want something to work some way, I'll look for supporting package(s) and tune them as I want, or much more rarely write some Elisp. Making Emacs more approachable to newcomers is a recurring discussion in the Emacs world. For historical reasons there's a barrier, as Emacs predates a lot of things (GUI windows so in Emacs a "window" is what's a text pane in other editors, Ctrl-X/C/V so it's C-w/M-w/C-y in Emacs, etc.). Changing this would be disruptive to current users, and Emacs puts a lot of weight on being backward compatible. It's not possible to please everyone here. In the end, I don't think Emacs "alieness" is a problem. The differences are rather superficial and easy to learn (with some motivation). For people not interested in this, there are plenty of alternate editors that focus on being user friendly, and it's perfectly fine. Choice is good. Much more important to the Emacs experience is the ease of customization and adaptation. The Lisp environment is a big part of this: once you know the basics the embedded documentation is very extensive and always accessible. It's trivial to get the documentation on any function or variable, and go to its source code. It's also straightforward to adjust any behavior. There is no difference between core elisp code and the user code. Changes to the core are done in a conservative way to avoid breaking all the current users customization (there are breaking changes, but with early obsolescence warnings and good change documentation). All this is a much more important part of Emacs than the early experience. It's also quite specific to Emacs, I'm not sure there are many alternatives? If any, they're also "not so user friendly" (like neovim with Lua now?). In summary, there's a tradeoff being first user experience, backward compatibility with such a long history, and flexibility to accommodate very different needs and use-cases (some of them incompatible). Emacs has a specific situation here. It may not be to everyone taste, but it's OK: there are plenty other alternatives. There's a thriving community, improvements have never been as speedy. I'm a happy user seeing no reason to change, on the contrary: I really feel it's getting better and better!