16 ms·

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs

Sometimes I think people trick themselves into thinking that all their fiddling with Emacs counts as part of their productivity. Don't hate on me. I use Emacs just about every day. I used to use Emacs as my go to editor for writing code ... and it almost worked. But it was never hassle free, and things often worked more poorly than I would have liked, or ended up requiring too much fiddling to get it to work right, or packages were inadequately maintained. So now, I tend to use it for quick, short code writes, especially when I'm remoted in to a server. I also use it for org-mode, and for writing my book. Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs. I use VSCode for quick scripts, and for when I need to do maintenance work on some old php code. I like it fine. It fits in this really nice place between a full IDE and a bare bones text editor like Notepad or even BBEdit (ha!).

jonnycomputer 6y ago
Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it. Maybe language support will get better with LSP; anyone know how that is going in the emacs world?
- justinlilly 6y ago
  I use lsp. It's not as good as pycharm, et al, but it's good.
- mplanchard 6y ago
  I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something performant for a very large python codebase, and I did some more fiddling to adjust some delays and whatnot to get everything feeling snappy with the way I edit text. I still find that it feels faster on Linux than on Mac, but I don’t use the latter much anymore anyway. My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
  - jonnycomputer 6y ago
    It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.
    - mplanchard 6y ago
      Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster. There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board. Definitely a lot of exciting things happening!
      - TeMPOraL 6y ago
        Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there. Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems. The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time. -- [0] - https://digip.org/jansson/ https://digip.org/jansson/
  - neutronicus 6y ago
    It doesn't really work for C++ Like it can, but not on our codebase
- amake 6y ago
  I use Emacs professionally for Ruby development and LSP (Solargraph) is a huge part of what makes it work smoothly. I also do a lot of hobby Flutter/Dart development and the same is true there. Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
- OrderlyTiamat 6y ago
  I use lsp for python and c++. It's usually good, but lsp will sometimes have the clang seever crash repeatedly, which can usually only be fixed by restarting emacs. I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself) All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
  - hvis 6y ago
    If Clang server crashes, surely that means some bug in it was triggered? lsp-mode only converses with it over JSON, after all. Clang's developers might appreciate the corresponding bug reports.
- sokoloff 6y ago
  JetBrains has a straightforward way to pay for all that development and polishing time, which is lacking (due to sound but foundational reasons) on the emacs side.
- legends2k 6y ago
  I use LSP for Rust (rust-analyzer) and C++ (ccls) and I would say the experience is pretty good. For C++ projects I generate a compile_commands.json (Ninja, CMake or meson should help) and after that it's smooth sailing. I get contextual auto complete suggestions (yasnippet and complete even fills function arg placeholders), definition lookups, find all references, alternate between header and source, etc.
dmortin 6y ago
> Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs. It can be said for any other text editor. Of course, specialized tools are better most of the time. The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features. LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.
- jolux 6y ago
  >LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages. Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
  - dmortin 6y ago
    The main thing is having the capability. Adding the interface for it is the easier task.
    - jolux 6y ago
      I don’t think it’s easier, actually, but it does translate in a way that the language-specific servers don’t.
rcdwealth 6y ago
Use Emacs in simpler way like you use other editors and it will always work. Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.
- legends2k 6y ago
  Haha... Good joke. But jokes apart, I've been using it to write book, refcards, blogs and programs I've never faced this 'feature'. In a proficient hand a good tool shines; Emacs ia no exception.
- OrderlyTiamat 6y ago
  Can you clarify this? It makes no sense to me, and I'm a daily emacs user. How is that a good thing?
d0mine 6y ago
Could you name one thing that you use every day in PyCharm but that is not available in Emacs?
Hedepig 6y ago
As usual it boils down to the right tool for the job. Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed. Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.
- TeMPOraL 6y ago
  I thought about it a lot, and realized there's one big obstacle for Emacs to be as close to a silver bullet as you can get - reconciling the following needs: - Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI. - Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other. - Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web. The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot). Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM. (And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)
wodenokoto 6y ago
Don't you miss having the same keyboard shortcuts across programs? Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line? Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.
- rodelrod 6y ago
  That's less of a problem when you use Vim keybindings everywhere.
- pjmlp 6y ago
  All my IDEs share common settings for copy paste, searching and basic text editing, for everything else there is mouse and graphical tooling.
- rerx 6y ago
  A sizable portion of the Jetbrains IDE functionality can be accessed by the keyboard. Moreover, the keybindings can be configured very similar to Emacs quite easily (I don't want to live without C-x C-2 etc. for splits for instance). There's a couple of helpful plugins, too. And for hardcore, straightforward editing I've bound Cmd-e to launch emacsclient right at cursor position. This goes quite a long way, IMHO.
- marcosdumay 6y ago
  Personally, I miss Notepad++'s tab and shift-tab behavior with multiple selected lines on nearly everything, but except for that, I don't usually miss a tool behavior on another tool. It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL. 1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
- jonnycomputer 6y ago
  A lot of IDEs have options to enable emacs-like key bindings. But the mapping is imperfect, and sometimes it gets frustrating. But I tend to work in one environment at a time, so after the initial frustration, I'm fine. I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.
TeMPOraL 6y ago
I don't hate you :). You have a good point. But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time. It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need. -- See https://xkcd.com/974/ https://xkcd.com/974/, https://xkcd.com/1205/ https://xkcd.com/1205/ and https://xkcd.com/1319/ https://xkcd.com/1319/ for the common arguments.
da39a3ee 6y ago
I'm in the same position. I've used Emacs intensively for 20 years and I'm the author of Emacs packages that other people use. Nowadays I work on Python, Rust, and Typescript/$JSFramework projects. Here are some of the requirememts: - Completions need to take the type system into account (even in Python), etc. - Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc - It has to be easy to set the interpreter path for every one of the executables involved. - This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume. Clearly nowadays this has to be done with LSP. I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering. So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.
- TeMPOraL 6y ago
  To the four bullet points you mention, I'll add a meta-point: this all needs to be easy to set up simultaneously, per language. That's where commercial IDEs and editors shine - you get all these things properly set up out of the box. In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
  - da39a3ee 6y ago
    It's definitely possible in principle with LSP in Emacs I think at the very least if I'm going to put time in the future into getting this working well in Emacs then it makes sense to take a break and see what the cutting edge is like in a mainstream thing like VS Code, so I know what we're really aiming for in Emacs.
vector_spaces 6y ago
I hear what you're saying, as I regularly run up against the rough edges of emacs too, but buffers and org-mode are absolute gamechangers for me and my productivity. I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity. That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1]. I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching [1] https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4
agumonkey 6y ago
Everything except magit. magit is life magit is love.
- b0afc375b5 6y ago
  Magit was the emacs killer app for me. I'm now slowly learning other parts of emacs, such as org-mode.
  - agumonkey 6y ago
    I was in college around the svn days, then git came then IDEs tried to integrate.. at best you had cute crud. First use of magit was a shocker. It's so good it makes you usage better.. crafting thin coherent commits in 2 seconds. Out of curiosity and objectivity I tried Eclipse / IDEA git integration (a few years ago tbf).. they were still complex and distracting. I'm not fond of org-mode it's too large imo but maybe it will fit your brain and you'll have a blast. Best feature to me is the source block (~tiny adhoc notebook).
    - b0afc375b5 6y ago
      Yes code snippets is most of the reason why I forced myself to learn org-mode. I have several *.notes files (node.notes, ruby.notes, linux.notes) in which I place important things I've learned about a particular subject, but the code snippets in them aren't executable (yet). Ultimately I want the code snippets in them to be executed in a docker container so that I won't have to install various dev tools in my host machine.
    - e3bc54b2 6y ago
      Org-mode is too big, but you don't have to use all of it. You can only learn the tiny subset you need and simply ignore the rest.
- jonnycomputer 6y ago
  its funny, I still haven't tried. I almost always use git on the command line
cmrdporcupine 6y ago
I was fully down the path you're talking about, and would have agreed with you... until COVID happened and I've been stuck working from home on a fairly low bandwidth (rural) Internet connection with source code that can't (because of BigCorp policy) be on my local machine. So it's SSH for most things, and suddenly my 25+ year old emacs skills (such as they are) have come back to be a big help. That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems. So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.
- xxpor 6y ago
  TRAMP used to be my reasons to use emacs too, but VS code's ssh remote plug in is amazing.
  - Scarbutt 6y ago
    He meant running Emacs on the remote server which IMO is even better than using vscode's remote plugin.
    - jonnycomputer 6y ago
      Yeah, I do use Tramp mode, but have, at times, had problems with it and actually found an smb mount to be more reliable (ha!) when editing files. But often what is the case is that I'm using a variety of bash tools while ssh'd in, and then quickly find I need to edit a file and so launch the server's copy of emacs. Theoretically, I could do everything in Emacs terminal mode, or eshell, either using Tramp, or in the remote instance of Emacs, but I never seem to find that it works hassle free, which is too bad, because I really like being able to move about the terminal field as if it were a text file (e.g. doing a regex on already existing output, etc.).
  - cmrdporcupine 6y ago
    Remote SSH plus indexing a code base of my size over a 10mbpsa connection is just... oh nope, no way. Can't even reliably index it locally.
sodapopcan 6y ago
I'm a Vim user, not Emacs and don't know anything about the ecosystem, but I just wanted to say I've never ever convinced myself that the hundreds of hours I've put into hacking on my Vim setup is "productivity". It's all recreational. I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. I imagine it's the same for many Emacs users.
- gpanders 6y ago
  > I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...
hellothrow4418 6y ago
A heads-up that VSCode's remote extensions and Python LSP (pylance) are proprietary. So they can't be used in forks like VSCodium. Pylance is set to replace the current Python LSP. So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary. Possibly more core extensions could become proprietary. PS: I know MS created LSP, so no need to remind in reply.
- oblio 6y ago
  https://news.ycombinator.com/item?id=26513727 https://news.ycombinator.com/item?id=26513727 Why do you keep creating throwaway accounts for this? Write a full blog post about it and get it on HN. People will for sure upvote it to the front page.
wildermuthn 6y ago
Same experience here, but as a Vim and IntelliJ user. I can edit a single file or a few buffers in Vim maybe twice as fast as I can in IntelliJ. However, I can navigate through a codebase 5x as fast, which means that when I’m doing anything that requires an understanding of parts of the codebase I haven’t memorized (95% of it), my IDE is speeding up my development by nearly 5x. I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.
- jonnycomputer 6y ago
  That's an insightful comment, thank you, and one that mirrors my own experience.

jonnycomputer 6y ago

Don't get me wrong, a lot of these problems aren't really Emacs's fault. Jetbrains puts a lot of money and effort into its IDEs. If some commercial or nonprofit entity was actually committed to developing and maintaining elisp packages providing superb language support, then Emacs would have it. Maybe language support will get better with LSP; anyone know how that is going in the emacs world?

justinlilly 6y ago
I use lsp. It's not as good as pycharm, et al, but it's good.
mplanchard 6y ago
I’ve used lsp-mode for python, go, typescript, rust, and haskell. Had to do a little bit of fiddling with settings and trying different servers to get something performant for a very large python codebase, and I did some more fiddling to adjust some delays and whatnot to get everything feeling snappy with the way I edit text. I still find that it feels faster on Linux than on Mac, but I don’t use the latter much anymore anyway. My general impression of lsp-mode is that it’s great, once you get the settings the way you like them. Errors and warnings are nicely integrated into flycheck, and the lsp-ui package provides some niceties like automatically showing function signatures, showing error information inline with the code, and so on.
- jonnycomputer 6y ago
  It does actually sound like things have improved since when I started moving away from primary development in emacs circa 2016-17. It might be time to revisit my config file. I still end up coding in emacs a lot of the time.
  - mplanchard 6y ago
    Emacs 27 helped a ton with language server performance, I believe because they reworked the JSON parser to be quite a lot faster. There’s also a “native-comp” feature that’s available experimentally in 28, which does native compilation of most of the .el files in emacs. I’ve played with it a bit and it does seem like a significant speed up across the board. Definitely a lot of exciting things happening!
    - TeMPOraL 6y ago
      Yup, Emacs switched to Jansson[0] for JSON parsing. Since LSP uses JSON a lot, this means big performance improvements there. Also seconding "native-comp" branch. It's technically experimental, but in practice it's pretty much stable. I've been running on it daily for the past 6+ months, with zero problems. The way it works is, it uses GCC (libgccjit) to compile Emacs Lisp down to native (vs. the EL bytecode Emacs normally uses) on the fly, and then replaces the byte-compiled function with its native-compiled version. It does it transparently, across all elisp code you use - built-in and thrid party alike. What you get is a huge performance boost, and occasional messages that something gets compiled, when you run some new elisp for the first time. -- [0] - https://digip.org/jansson/ https://digip.org/jansson/
- neutronicus 6y ago
  It doesn't really work for C++ Like it can, but not on our codebase
amake 6y ago
I use Emacs professionally for Ruby development and LSP (Solargraph) is a huge part of what makes it work smoothly. I also do a lot of hobby Flutter/Dart development and the same is true there. Languages that I’ve tried to work with this way but failed include Java, Kotlin, Swift, and C#. But I could see any of them working great if the LSP implementation was robust enough.
OrderlyTiamat 6y ago
I use lsp for python and c++. It's usually good, but lsp will sometimes have the clang seever crash repeatedly, which can usually only be fixed by restarting emacs. I do debugging with gdb, which is rather nice actually (you can easily set breakpoints and it will show the pointer walking through all the files), but even there there are some rough edges (the in/output buffer will show up on all frames for example, and will pop up, closing the gdb buffer itself) All in all this is a rather good setup imo, with a little polishing I'd never have to use anything else I think. Maybe I'll try out Doom again, it might be that my config is contributing to the unstableness...
- hvis 6y ago
  If Clang server crashes, surely that means some bug in it was triggered? lsp-mode only converses with it over JSON, after all. Clang's developers might appreciate the corresponding bug reports.
sokoloff 6y ago
JetBrains has a straightforward way to pay for all that development and polishing time, which is lacking (due to sound but foundational reasons) on the emacs side.
legends2k 6y ago
I use LSP for Rust (rust-analyzer) and C++ (ccls) and I would say the experience is pretty good. For C++ projects I generate a compile_commands.json (Ninja, CMake or meson should help) and after that it's smooth sailing. I get contextual auto complete suggestions (yasnippet and complete even fills function arg placeholders), definition lookups, find all references, alternate between header and source, etc.

dmortin 6y ago

> Now I use Pycharm for python and web development for things that can reasonably be called a "project"; the level of language support, introspection, and intelligent code prediction exceeds anything I ever achieved in Emacs. It can be said for any other text editor. Of course, specialized tools are better most of the time. The open source community should pool resources to create code inspection, refactoring libraries for all kinds of languages, so all extendable editors can use these libraries to provide these features. LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages.

jolux 6y ago
>LSP is a first step for this, but there needs to be a deeper language integration to give intelligent tips, refactoring operations, etc. for all popular languages. Emacs specifically also needs a lot of user interface-side polish to deal with the increase in the complexity of these plugins.
- dmortin 6y ago
  The main thing is having the capability. Adding the interface for it is the easier task.
  - jolux 6y ago
    I don’t think it’s easier, actually, but it does translate in a way that the language-specific servers don’t.

rcdwealth 6y ago

Use Emacs in simpler way like you use other editors and it will always work. Use it in complex way and you will stumble upon plethora of troubles. That is feature, not bug.

legends2k 6y ago
Haha... Good joke. But jokes apart, I've been using it to write book, refcards, blogs and programs I've never faced this 'feature'. In a proficient hand a good tool shines; Emacs ia no exception.
OrderlyTiamat 6y ago
Can you clarify this? It makes no sense to me, and I'm a daily emacs user. How is that a good thing?

d0mine 6y ago

Could you name one thing that you use every day in PyCharm but that is not available in Emacs?

Hedepig 6y ago

As usual it boils down to the right tool for the job. Emacs hits the mark a great deal and it is a very versatile and adaptable tool, but of course it will have it limitations. As much as one truly desires to find the silver bullet, one will be always disappointed. Having said that, I do often wonder what emacs could be been if it saw the adoption levels Vim has seen.

TeMPOraL 6y ago
I thought about it a lot, and realized there's one big obstacle for Emacs to be as close to a silver bullet as you can get - reconciling the following needs: - Everything - especially any GUI element - having a fallback to text, so that you can get equivalent workflow for terminal and GUI. - Everything being kept "in the open", in easily parseable data structures, from the POV of Elisp, so that things can easily interoperate with each other. - Rendering arbitrary fonts and graphics, which is super useful for more advanced UI elements, and about any time you need something from the Web. The usual "next step" for an editor to suddenly gain a lot of functionality would be, "embed a webview". Except this fails the first two points. But on the other hand, there's only so much you can do with text if you want to use more complex tools for the mind - like graphs. Or even if you want to pack data more densely (overlapping icons, semi-transparent or pixel-aligned popups, whatnot). Perhaps what we need to advance Emacs is to first standardize on terminal emulators, and associated protocols, that can render pixel and vector images - and some kind of mental framework to make them seamlessly work with text, in a way that doesn't turn into DOM. (And also threading. If we could just get proper multithreading to work reliably in Emacs, things would improve greatly.)

wodenokoto 6y ago

Don't you miss having the same keyboard shortcuts across programs? Or the tiny things, like, does backspace at the beginning of text delete one space, back to the nearest indentation (e.g. 4 spaces) or back to the beginning of the line? Moving between sublime on MacOS and VSCode on windows is death by a thousand needles to me. I can only imagine what moving between 3-4 editors must be like.

rodelrod 6y ago
That's less of a problem when you use Vim keybindings everywhere.
pjmlp 6y ago
All my IDEs share common settings for copy paste, searching and basic text editing, for everything else there is mouse and graphical tooling.
rerx 6y ago
A sizable portion of the Jetbrains IDE functionality can be accessed by the keyboard. Moreover, the keybindings can be configured very similar to Emacs quite easily (I don't want to live without C-x C-2 etc. for splits for instance). There's a couple of helpful plugins, too. And for hardcore, straightforward editing I've bound Cmd-e to launch emacsclient right at cursor position. This goes quite a long way, IMHO.
marcosdumay 6y ago
Personally, I miss Notepad++'s tab and shift-tab behavior with multiple selected lines on nearly everything, but except for that, I don't usually miss a tool behavior on another tool. It helps that I set tooling based on language, so if I decide to use Pycharm for Python¹, I will expect Pycharm's behavior on every Python file. But I won't expect it on C, or Haskell, or SQL. 1 - I do change my opinnion over "a specialized IDE is best than emacs when it exists" a lot, currently I'm liking the interaction-free emacs interface more.
jonnycomputer 6y ago
A lot of IDEs have options to enable emacs-like key bindings. But the mapping is imperfect, and sometimes it gets frustrating. But I tend to work in one environment at a time, so after the initial frustration, I'm fine. I also find myself using emacs short cuts when using Excel, which doesn't work, at all, of course.

TeMPOraL 6y ago

I don't hate you :). You have a good point. But in my experience, it's a wash. I've wasted a lot of time customizing my Emacs over the years, but I also wrought a lot of time savings out of it, which compound over time. It's also a part of a bigger discussion about automation and developing support tools. The popular opinion is, better not spend time on it[0], but I feel that we tend to err too much on the side of doing things the hard way and waiting until someone on the Internet develops just the tool we need. -- See https://xkcd.com/974/ https://xkcd.com/974/, https://xkcd.com/1205/ https://xkcd.com/1205/ and https://xkcd.com/1319/ https://xkcd.com/1319/ for the common arguments.

da39a3ee 6y ago

I'm in the same position. I've used Emacs intensively for 20 years and I'm the author of Emacs packages that other people use. Nowadays I work on Python, Rust, and Typescript/$JSFramework projects. Here are some of the requirememts: - Completions need to take the type system into account (even in Python), etc. - Emacs has to provide intelligent completions, linting, type-checking, compiler error annotations, type information, format-on-save, jump-to-definition, code search, etc - It has to be easy to set the interpreter path for every one of the executables involved. - This all must work in a dockerized development environment, including setting breakpoints in 3rd party code that may exist only in a container volume. Clearly nowadays this has to be done with LSP. I initially got a bad impression of lsp-mode and tried Eglot. However, (a) Eglot has been under heavy development, and (b) it has a complicated relationship to other core Emacs modules such as eldoc and flycheck/flymake (who can remember which is which) and (c) it threatens to become part of Emacs which means that its development will no longer be done openly with PRs but in an old-school mailing list with a lot of bickering. So, it now looks like I'm switching to VS Code for programming on real projects, but sticking to Emacs for Magit and everything else.

TeMPOraL 6y ago
To the four bullet points you mention, I'll add a meta-point: this all needs to be easy to set up simultaneously, per language. That's where commercial IDEs and editors shine - you get all these things properly set up out of the box. In Emacs, I ordinarily have to wire half a dozen components to get this to work, and a different language may use different components. LSP is a great step forward here, in that most of the data and actions for aforementioned features come through a single pipe, so it's a matter of patching up the UI to taste.
- da39a3ee 6y ago
  It's definitely possible in principle with LSP in Emacs I think at the very least if I'm going to put time in the future into getting this working well in Emacs then it makes sense to take a break and see what the cutting edge is like in a mainstream thing like VS Code, so I know what we're really aiming for in Emacs.

vector_spaces 6y ago

I hear what you're saying, as I regularly run up against the rough edges of emacs too, but buffers and org-mode are absolute gamechangers for me and my productivity. I have ADHD, so not being able to switch between active files/tabs/whatever + my TODO list at lightning speed + having to constantly use the mouse devastates my productivity. That's to speak nothing of the embrace-extend-extinguish behaviors Microsoft has been exhibiting in its development of VS Code -- e.g., deprecating their open source, editor-agnostic Python language server in favor of a proprietary, closed-source VSCode-only server[1]. I regularly update and play around with VSCode in an effort to keep an open min, but frankly I haven't found it to offer anything worth the trouble + spiritual taint (I'm saying this sort of tongue in cheek!) of switching [1] https://github.com/microsoft/pylance-release/issues/4 https://github.com/microsoft/pylance-release/issues/4

agumonkey 6y ago

Everything except magit. magit is life magit is love.

b0afc375b5 6y ago
Magit was the emacs killer app for me. I'm now slowly learning other parts of emacs, such as org-mode.
- agumonkey 6y ago
  I was in college around the svn days, then git came then IDEs tried to integrate.. at best you had cute crud. First use of magit was a shocker. It's so good it makes you usage better.. crafting thin coherent commits in 2 seconds. Out of curiosity and objectivity I tried Eclipse / IDEA git integration (a few years ago tbf).. they were still complex and distracting. I'm not fond of org-mode it's too large imo but maybe it will fit your brain and you'll have a blast. Best feature to me is the source block (~tiny adhoc notebook).
  - b0afc375b5 6y ago
    Yes code snippets is most of the reason why I forced myself to learn org-mode. I have several *.notes files (node.notes, ruby.notes, linux.notes) in which I place important things I've learned about a particular subject, but the code snippets in them aren't executable (yet). Ultimately I want the code snippets in them to be executed in a docker container so that I won't have to install various dev tools in my host machine.
  - e3bc54b2 6y ago
    Org-mode is too big, but you don't have to use all of it. You can only learn the tiny subset you need and simply ignore the rest.
jonnycomputer 6y ago
its funny, I still haven't tried. I almost always use git on the command line

cmrdporcupine 6y ago

I was fully down the path you're talking about, and would have agreed with you... until COVID happened and I've been stuck working from home on a fairly low bandwidth (rural) Internet connection with source code that can't (because of BigCorp policy) be on my local machine. So it's SSH for most things, and suddenly my 25+ year old emacs skills (such as they are) have come back to be a big help. That and even when I was able to do development locally, it has been on a massive codebase (Chromium) that CLion literally cannot index (freezes, fails, lags etc.) and yet somehow clangd & lsp etc. don't have problems. So hoorah for the continued excellence of emacs and assorted related open source tools. They may not be slick or well packaged but they are on the whole resilient because they're flexible.

xxpor 6y ago
TRAMP used to be my reasons to use emacs too, but VS code's ssh remote plug in is amazing.
- Scarbutt 6y ago
  He meant running Emacs on the remote server which IMO is even better than using vscode's remote plugin.
  - jonnycomputer 6y ago
    Yeah, I do use Tramp mode, but have, at times, had problems with it and actually found an smb mount to be more reliable (ha!) when editing files. But often what is the case is that I'm using a variety of bash tools while ssh'd in, and then quickly find I need to edit a file and so launch the server's copy of emacs. Theoretically, I could do everything in Emacs terminal mode, or eshell, either using Tramp, or in the remote instance of Emacs, but I never seem to find that it works hassle free, which is too bad, because I really like being able to move about the terminal field as if it were a text file (e.g. doing a regex on already existing output, etc.).
- cmrdporcupine 6y ago
  Remote SSH plus indexing a code base of my size over a 10mbpsa connection is just... oh nope, no way. Can't even reliably index it locally.

sodapopcan 6y ago

I'm a Vim user, not Emacs and don't know anything about the ecosystem, but I just wanted to say I've never ever convinced myself that the hundreds of hours I've put into hacking on my Vim setup is "productivity". It's all recreational. I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. I imagine it's the same for many Emacs users.

gpanders 6y ago
> I really enjoy it and it comes with a nice shot of adrenaline when you're able to tweak your environment just how you want it. This is so true. I too enjoy tweaking my Vim setup recreationally. It’s fun for me. Sometimes my wife will ask what I’m doing on the computer, and I have to try and figure out a way to explain that I’m customizing a text editor...

hellothrow4418 6y ago

A heads-up that VSCode's remote extensions and Python LSP (pylance) are proprietary. So they can't be used in forks like VSCodium. Pylance is set to replace the current Python LSP. So, it's like android - touted as open source but with gotchas that you stumble upon once you are invested in the software, and that creates a lock-in effect. Also, the VSCode binaries released by Microsoft are non-FLOSS licensed and contain telemetry. That's why VSCodium exists, but they are crippled due to at least 2 core extensions being proprietary. Possibly more core extensions could become proprietary. PS: I know MS created LSP, so no need to remind in reply.

oblio 6y ago
https://news.ycombinator.com/item?id=26513727 https://news.ycombinator.com/item?id=26513727 Why do you keep creating throwaway accounts for this? Write a full blog post about it and get it on HN. People will for sure upvote it to the front page.

wildermuthn 6y ago

Same experience here, but as a Vim and IntelliJ user. I can edit a single file or a few buffers in Vim maybe twice as fast as I can in IntelliJ. However, I can navigate through a codebase 5x as fast, which means that when I’m doing anything that requires an understanding of parts of the codebase I haven’t memorized (95% of it), my IDE is speeding up my development by nearly 5x. I used to try out Vim binding plugins every six months or so, until I realized that my IDE is forcing me to adopt a kind of hammock-driven-development, by being significantly faster at codebase comprehension while being significantly slower at codebase manipulation. With Vim I would never clone of a repo of a compiled 3rd party dependency in order to understand the dependency. I’d be forced to read through its repo on GitHub, since Vim’s speed-up of navigating through unfamiliar code is marginal. But with IntelliJ, I always clone the repo, create a project, and in a short time find the knowledge I’m looking for.

jonnycomputer 6y ago
That's an insightful comment, thank you, and one that mirrors my own experience.