5 ms·

2021 and Emacs still my preferred editor (and I'm young enough, in my 30's). Yes it requires a bit more setup (not much more however, VSC also misses functiona

2021 and Emacs still my preferred editor (and I'm young enough, in my 30's). Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box). However that setup is saved forever, across machines in the form of your .emacs file, so whatever changes you make to make it personal stay with you. And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files and as a programming language, it's pretty easy to understand that you invoke a function and then just pass it parameters, and that's about all you need to understand about it to set up the editor anyway. But there's literally nothing I don't have with Emacs that other editors provide. I have code completion in a bunch of languages (that pops up, with documentation pop-ups), linting, snippets, a project tree preview, project awareness, etc...

deleted 5y ago
[deleted]
criddell 5y ago
> But there's literally nothing I don't have with Emacs that other editors provide. Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly.
- Mikeb85 5y ago
  > Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly. Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. That isn't a feature unique to IDEs.
  - ReleaseCandidat 5y ago
    >Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. Yes, but Emacs (at least the LSP-modes of the languages I use) doesn't offer the same refactorings and code fixes like the same LSPs do with e.g. Code. Treesitter doesn't work with many languages, so syntax highlighting is also lacking for many languages.
  - criddell 5y ago
    For example, in C++ in Visual Studio I can click on a class member variable or method and rename it and the IDE will rename all uses of that variable or method and not get confused about other classes with the same name. struct Foo { std::string name; int age; }; struct Bar { std::string name; double weight; }; Foo f1 = ...; Foo f2 = ...; Bar b = ...; std::cout << f1.name; In the code above I can select "name" on the last line and rename it. The Foo struct and all instances of name via f1 or f2 are updated to use the new name. Bar and instance b are untouched. AFAIK, Emacs can't do this.
    - the-smug-one 5y ago
      You use clangd and get it (as part of lsp-mode).
    - yaantc 5y ago
      Such renaming is part of the LSP protocol, so any LSP supporting editor (Emacs, nvim, etc.) will support this as long as the used language server does. I can do this with clangd and Emacs, but it's not Emacs specific anymore. There may still be some gap with some very advanced integrated IDE support, but the LSP ecosystem is still evolving and getting there. Which is not a surprise as Microsoft designed it for VS Code. The difference now is not so much between an IDE and a given editor, but between and IDE built-in language support and LSP servers for a given language. For C/C++ the progress of clangd is real over a few years, and it's very usable now.
canaus 5y ago
VSCode allows you to export settings and keybinds via JSON files. Also, saying EMacs Lisp is more intuitive than JSON is quite absurd. You could give a 15 minute presentation on how to read JSON to someone who knows how to use Word and they’d at least be able to read it. The same wouldn’t be possible with any subset of lisp.
- Jtsummers 5y ago
  Well, JSON is "just" a serialization format. I'd expect that to be much easier to teach someone than a programming language. That's a rather bizarre comparison. If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
  - canaus 5y ago
    Yes, it is a bizarre comparison because of that fact. A programming language will never be more intuitive than "just a serialization format". Also, the argument that lisp's s-expressions are just as intuitive as JSON is verifiably false because you can use a simple natural experiment: what is used more for serialization, JSON or s-expressions? It's extremely ironic to try and argue these points on a post that's entire theme is how to get more people to use an editor that is quickly losing market share to easier to understand and configure applications.
    - Jtsummers 5y ago
      Be careful not to mistake ubiquity with intuitive. It’s arguable that BASIC is more intuitive than Javascript, but Javascript is more ubiquitous. That only tells us that it’s more popular, but not why.
      - canaus 5y ago
        Would you say that BASIC is more intuitive for web development than JavaScript? The syntax of something is only one part of its intuitiveness. A large part is the context of which it is used.
ReleaseCandidat 5y ago
> But there's literally nothing I don't have with Emacs that other editors provide. Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP provides them), a Tramp mode that actually works. Oh, and I would like to be able to continue editing my file while Emacs is doing something else ;)
- gpderetta 5y ago
  Fix-it and renames work with lsp+clangd. More complex refactoring would be nice, but in the end what is supported depends on the lsp-server capabilities. Emacs hanging at times has unfortunately been the reality for a looong time. There is extensive async support, but it is not always used were needed.
  - ReleaseCandidat 5y ago
    > Fix-it and renames work with lsp+clangd More complex refactoring would be nice I used (the paid version of) Xrefactory a long time ago with Emacs and C++, that really worked well. The Clojure-LSp has many code actions too. > Emacs hanging at times has unfortunately been the reality for a looong time. Well, at least 25 years :D
josteink 5y ago
> But there's literally nothing I don't have with Emacs that other editors provide. I like Emacs, have an extensive personalised config and use it as my primary editor across OSes. That said, I wish its debugging-support was better. Some simpler “just click to start debugging” options for a few popular platforms would be nice (Node, Python, .NET, Rust, whatever). I’ve heard there are similar efforts like LSP, except for debugging. Maybe they can help out Emacs’ debugging-support, just like LSP helped improve Emacs’ auto-completion and refactoring support?
- User23 5y ago
  You’re looking for the DAP[1], which is pretty much LSP for debuggers. [1] https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode
slightwinder 5y ago
> However that setup is saved forever, across machines in the form of your .emacs file Until you use a plugin which is dead after the next update. Which happens a lot... > Emacs lisp is more intuitive than JSON files Not really. In the first place JSON is just data-format which usually is used through a proper GUI. There is not much you can do break there. > But there's literally nothing I don't have with Emacs that other editors provide. Which only means your horizon is too small to know the missing parts. Or your work is not specific enough to demand something not available in emacs. If you are satisfied with emacs, ok. Good for you. But how will it benefit the popularity of emacs?
kamaal 5y ago
>>But there's literally nothing I don't have with Emacs that other editors provide. Time. Other editors save you play time you need to spend with emacs to get it to anywhere close to usable.
coldtea 5y ago
>Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box) Not even comparable. The functionality VSC misses you can get with installing some extension, which works out of the box, with hardly any configuration, and with a very simple way to find, select, install, enable, and disable it. >However that setup is saved forever, across machines in the form of your .emacs file Even that's something you need to do manually in Emaca. In VSCode it's automagically synced to GitHub, and indeed is "saved forever, across machines" -- and with smart ways to handle conflicts and such if you change it elsewhere, etc. >And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files VS Code has a graphical UI that abstracts away the JSON configuration files, provides autocomplete of options, limits you to available enumerated options, picks up automatically the proper UI for the config of an extension, and so on. And even when if you want to edit the raw JSON to change the configuration, it's of course vastly easier than Lisp (a full programming language), plus it also has autocomplete for key names and values, and so on.

deleted 5y ago

[deleted]

criddell 5y ago

> But there's literally nothing I don't have with Emacs that other editors provide. Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly.

Mikeb85 5y ago
> Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly. Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. That isn't a feature unique to IDEs.
- ReleaseCandidat 5y ago
  >Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. Yes, but Emacs (at least the LSP-modes of the languages I use) doesn't offer the same refactorings and code fixes like the same LSPs do with e.g. Code. Treesitter doesn't work with many languages, so syntax highlighting is also lacking for many languages.
- criddell 5y ago
  For example, in C++ in Visual Studio I can click on a class member variable or method and rename it and the IDE will rename all uses of that variable or method and not get confused about other classes with the same name. struct Foo { std::string name; int age; }; struct Bar { std::string name; double weight; }; Foo f1 = ...; Foo f2 = ...; Bar b = ...; std::cout << f1.name; In the code above I can select "name" on the last line and rename it. The Foo struct and all instances of name via f1 or f2 are updated to use the new name. Bar and instance b are untouched. AFAIK, Emacs can't do this.
  - the-smug-one 5y ago
    You use clangd and get it (as part of lsp-mode).
  - yaantc 5y ago
    Such renaming is part of the LSP protocol, so any LSP supporting editor (Emacs, nvim, etc.) will support this as long as the used language server does. I can do this with clangd and Emacs, but it's not Emacs specific anymore. There may still be some gap with some very advanced integrated IDE support, but the LSP ecosystem is still evolving and getting there. Which is not a surprise as Microsoft designed it for VS Code. The difference now is not so much between an IDE and a given editor, but between and IDE built-in language support and LSP servers for a given language. For C/C++ the progress of clangd is real over a few years, and it's very usable now.

canaus 5y ago

VSCode allows you to export settings and keybinds via JSON files. Also, saying EMacs Lisp is more intuitive than JSON is quite absurd. You could give a 15 minute presentation on how to read JSON to someone who knows how to use Word and they’d at least be able to read it. The same wouldn’t be possible with any subset of lisp.

Jtsummers 5y ago
Well, JSON is "just" a serialization format. I'd expect that to be much easier to teach someone than a programming language. That's a rather bizarre comparison. If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
- canaus 5y ago
  Yes, it is a bizarre comparison because of that fact. A programming language will never be more intuitive than "just a serialization format". Also, the argument that lisp's s-expressions are just as intuitive as JSON is verifiably false because you can use a simple natural experiment: what is used more for serialization, JSON or s-expressions? It's extremely ironic to try and argue these points on a post that's entire theme is how to get more people to use an editor that is quickly losing market share to easier to understand and configure applications.
  - Jtsummers 5y ago
    Be careful not to mistake ubiquity with intuitive. It’s arguable that BASIC is more intuitive than Javascript, but Javascript is more ubiquitous. That only tells us that it’s more popular, but not why.
    - canaus 5y ago
      Would you say that BASIC is more intuitive for web development than JavaScript? The syntax of something is only one part of its intuitiveness. A large part is the context of which it is used.

ReleaseCandidat 5y ago

> But there's literally nothing I don't have with Emacs that other editors provide. Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP provides them), a Tramp mode that actually works. Oh, and I would like to be able to continue editing my file while Emacs is doing something else ;)

gpderetta 5y ago
Fix-it and renames work with lsp+clangd. More complex refactoring would be nice, but in the end what is supported depends on the lsp-server capabilities. Emacs hanging at times has unfortunately been the reality for a looong time. There is extensive async support, but it is not always used were needed.
- ReleaseCandidat 5y ago
  > Fix-it and renames work with lsp+clangd More complex refactoring would be nice I used (the paid version of) Xrefactory a long time ago with Emacs and C++, that really worked well. The Clojure-LSp has many code actions too. > Emacs hanging at times has unfortunately been the reality for a looong time. Well, at least 25 years :D

josteink 5y ago

> But there's literally nothing I don't have with Emacs that other editors provide. I like Emacs, have an extensive personalised config and use it as my primary editor across OSes. That said, I wish its debugging-support was better. Some simpler “just click to start debugging” options for a few popular platforms would be nice (Node, Python, .NET, Rust, whatever). I’ve heard there are similar efforts like LSP, except for debugging. Maybe they can help out Emacs’ debugging-support, just like LSP helped improve Emacs’ auto-completion and refactoring support?

User23 5y ago
You’re looking for the DAP[1], which is pretty much LSP for debuggers. [1] https://github.com/emacs-lsp/dap-mode https://github.com/emacs-lsp/dap-mode

slightwinder 5y ago

> However that setup is saved forever, across machines in the form of your .emacs file Until you use a plugin which is dead after the next update. Which happens a lot... > Emacs lisp is more intuitive than JSON files Not really. In the first place JSON is just data-format which usually is used through a proper GUI. There is not much you can do break there. > But there's literally nothing I don't have with Emacs that other editors provide. Which only means your horizon is too small to know the missing parts. Or your work is not specific enough to demand something not available in emacs. If you are satisfied with emacs, ok. Good for you. But how will it benefit the popularity of emacs?

kamaal 5y ago

>>But there's literally nothing I don't have with Emacs that other editors provide. Time. Other editors save you play time you need to spend with emacs to get it to anywhere close to usable.

coldtea 5y ago

>Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box) Not even comparable. The functionality VSC misses you can get with installing some extension, which works out of the box, with hardly any configuration, and with a very simple way to find, select, install, enable, and disable it. >However that setup is saved forever, across machines in the form of your .emacs file Even that's something you need to do manually in Emaca. In VSCode it's automagically synced to GitHub, and indeed is "saved forever, across machines" -- and with smart ways to handle conflicts and such if you change it elsewhere, etc. >And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files VS Code has a graphical UI that abstracts away the JSON configuration files, provides autocomplete of options, limits you to available enumerated options, picks up automatically the proper UI for the config of an extension, and so on. And even when if you want to edit the raw JSON to change the configuration, it's of course vastly easier than Lisp (a full programming language), plus it also has autocomplete for key names and values, and so on.