6 ms·

The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boost

The main reason I quit Emacs was the lack of context and semantically aware code completion and re-factoring tools. Such tools are invaluable productivity boosts for me. I have never gotten that to work in Emacs to a satisfactory degree.

wry_discontent 7y ago
This is true for me too. I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors. Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.
- AndrewBissell 7y ago
  I've seen posts about how to set up vim as a frontend for a headless Eclipse server, but it always looked to me like the payoff wasn't worth the effort.
billfruit 7y ago
OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.
- jonnycomputer 7y ago
  Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.: PyCharm: Yes VS Code: Yes Eclipse: Yes
  - olejorgenb 7y ago
    Vs code can't open two windows properly though..
    - jonnycomputer 7y ago
      I'm curious what you mean, as I've not had any issues thus far. I'm only an occasional VS Code user however.
      - olejorgenb 7y ago
        Only one os-level window per workspace is supported AFICT. It's possible to tile editors within this window, bit you can't detach an editor.
- dmortin 7y ago
  Completion and refactoring are much more important than these. When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually. When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool. Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
  - gmueckl 7y ago
    The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.
    - dmortin 7y ago
      On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion. It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree. So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes. An efficient text editor with completion + powerful refactoring. This is the winning combination.
      - gmueckl 7y ago
        You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared to a text editor.
lorenzhs 7y ago
Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.
- worldsayshi 7y ago
  I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
  - taeric 7y ago
    Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some. Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
  - didibus 7y ago
    Interesting angle. That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold: 1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is. 2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
  - didibus 7y ago
ilikehurdles 7y ago
Coincidentally, I quit java for almost the same reason.
- worldsayshi 7y ago
  Really? What languages have better IDE support than Java? I guess C#?
  - ilikehurdles 7y ago
    It was more abandonding languages that are a slog to write without somewhat advanced IDE tooling. Committing thousands of lines per PR was common for the typical Java project, and much of had to be aided by IDE tooling to keep your sanity. I'm sure there's some amount of plugins I can throw at emacs or vim to get good-enough Java assistance or I can use languages with a higher productivity-to-lines of code ratio.
drbojingle 7y ago
The creation of the Language Server Protocol has changed this kind of thing considerably. Any editor now is able to use goto definition, goto reference, rename, etc for a variety of languages (assuming they have a plugin LSP client). I've been using one in NeoVim for a while for JavaScript and it works pretty good.

wry_discontent 7y ago

This is true for me too. I still do some of my personal projects in Emacs, and I still use Magit, and dired, and a few others, but by and large my professional development is mostly in the family of JetBrains editors. Ideally, their code analysis could work through a server and use Emacs as a frontend, but the existing tools don't even come close to what those IDEs can do. Emacs is great, but it's not the most productive tool for me to edit large projects.

AndrewBissell 7y ago
I've seen posts about how to set up vim as a frontend for a headless Eclipse server, but it always looked to me like the payoff wasn't worth the effort.

billfruit 7y ago

OTOH hlmost many modern IDEs can't even open two copies of the same file and display it side by side or record arbitrarily complex macros and play them back any number of times.

jonnycomputer 7y ago
Don't know about the second, but displaying two copies of the same file side by side is pretty common in my experience, e.g.: PyCharm: Yes VS Code: Yes Eclipse: Yes
- olejorgenb 7y ago
  Vs code can't open two windows properly though..
  - jonnycomputer 7y ago
    I'm curious what you mean, as I've not had any issues thus far. I'm only an occasional VS Code user however.
    - olejorgenb 7y ago
      Only one os-level window per workspace is supported AFICT. It's possible to tile editors within this window, bit you can't detach an editor.
dmortin 7y ago
Completion and refactoring are much more important than these. When working with code it's very powerful to work on a higher abstraction level. E.g. move this method to an other class and update all references to it automatically keeping the code correct. It takes a few seconds in a modern IDE while in a text editor you have to do most of it manually. When you get used to the power of refactoring, you start to use it more and more, like a sculptor getting a more powerful tool. Open source editors should pool their resources to create such powerful refactoring tools which can be accessible in any editor via LSP or something.
- gmueckl 7y ago
  The sad part is that text based representations of programs are holding back programmer productivity by raising the bar for these refactoring tools unreasonably. If programs were represented and edited directly as syntax trees, 80 to 90 percent of the complexity of refactoring tools would go away.
  - dmortin 7y ago
    On the other hand, when writing new code it is quite efficient to simply type, supported with proper completion. It would be much less efficient to create a program in a point and click gui, dragging visual elements onto the syntax tree. So both is necessary. Efficient text editing is required to work quickly with the code, edit things locally efficiently. And refactoring is also needed if you want to perform bigger operations which span methods or classes. An efficient text editor with completion + powerful refactoring. This is the winning combination.
    - gmueckl 7y ago
      You're jumping to conclusions when you're associating a syntax tree based program representation with the forced use of a mouse or cumbersome navigation for editing. Nothing could be further from the truth. A completely usable and fast keyboard based editing method for such a program representation is entirely possible. The only downside is that it's harder to create a minimal working version of such a tool compared to a text editor.

lorenzhs 7y ago

Language Server Protocol brings this to many editors that historically lacked it, including Emacs' lsp-mode. I use it a lot (with clangd), it's great. Because it's a common interface used by all editors, there is a lot of interest in and work on the language backends.

worldsayshi 7y ago
I'm all for standardizing this but I can't hear about the Language Server Protocol without thinking about this rant: https://youtu.be/pW-SOdj4Kkk?t=2549 https://youtu.be/pW-SOdj4Kkk?t=2549 The rant itself is probably misdirected towards LSP when it should be directed to the circumstances that it has to deal with.
- taeric 7y ago
  Thanks for that link. I confess I have my own prejudices against LSP. This view just strengthened it some. Specifically, I feel that there is an anti-fragility to agreeing that we should all be able to write a program that can tell us about the programs we are writing. Getting languages that make this so that we all have to use a central server seems to put us at the mercy of who wrote that server. When it is that same group that wrote the compiler, it seems more likely that they will have the same blind spots.
- didibus 7y ago
  Interesting angle. That said, LSP is more supposed to be thought as the backend to the editor, not just a library. And the problem it solves are twofold: 1. Having to rewrite the same logic in all the programming languages used by all editors. Since as far as know, there are no language agnostic libraries, but a server is. 2. A strong boundary protects from accidental coupling of the UI/UX and the business logic. Without this, maybe at first you'd think you use some part of some other editor in yours until slowly over time it becomes more and more coupled to that particular editor's UX/UI. Even LSP actually suffers a little from that in that the APIs are totally designed with VSCode in mind first, but that stronger boundary protects it getting even worse.
- didibus 7y ago

ilikehurdles 7y ago

Coincidentally, I quit java for almost the same reason.

worldsayshi 7y ago
Really? What languages have better IDE support than Java? I guess C#?
- ilikehurdles 7y ago
  It was more abandonding languages that are a slog to write without somewhat advanced IDE tooling. Committing thousands of lines per PR was common for the typical Java project, and much of had to be aided by IDE tooling to keep your sanity. I'm sure there's some amount of plugins I can throw at emacs or vim to get good-enough Java assistance or I can use languages with a higher productivity-to-lines of code ratio.

drbojingle 7y ago

The creation of the Language Server Protocol has changed this kind of thing considerably. Any editor now is able to use goto definition, goto reference, rename, etc for a variety of languages (assuming they have a plugin LSP client). I've been using one in NeoVim for a while for JavaScript and it works pretty good.