Live data from Hacker News

From Vim to Emacs in fourteen days (2015)

blog.aaronbieber.com

161–170 of 182 posts

Re: From Vim to Emacs in fourteen days (2015)

#161

Earlier quoted context omitted.

This isn't about LSP but specifically pylance. Let's not confuse the issue. (Incidentally, I don't even use lsp on Emacs, although I may give it a try).

I think the thing is that pylance is a python LSP. And it's proprietary. So they embraced python LSP, extends it so that the additions are proprietary. And pylance might become the defacto python LSP. Typical EEE. Python is hugely popular, it's everywhere - so even if one hates it, might end up having to use it. Also the remote extensions are proprietary [1]. This has been discussed on HN before. [1] https://github.c…

> So they embraced python LSP

They did not embrace LSP. They invented it. LSP came from MS.

> And pylance might become the defacto python LSP.

Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.

Re: From Vim to Emacs in fourteen days (2015)

#162

Earlier quoted context omitted.

I tried that too for a bit over two weeks. In the end I had a comfortable configuration, but with noticably worse performance and a lot of inconsistencies. Whenever I use Emacs I kind of like the concept but at the same time feel like the good parts are buried beneath countless random additions that should have been optional plugins. I dare to claim that >95% of Emacs users do not use its integrated Tetris implementa…

You might be right, though I do not have a good reference to compare Emacs + evil with. I think by default Emacs is a somewhat mediocre editor, the one thing that saves it is the unparalleled customizability, which should allow you to slowly prune the randomness and inconsistencies. But it is a commitment, not everybody wants a relationship with their editor. Btw, I regularly play Tetris in emacs ;-)

Definitely. But the thing is, coming from Vim with a custom configuration I'm at a point where I'd first need to reverse engineer parts of Emacs and reconfigure a ton just to get back to where I left Vim. And if I learned something when trying it out then it's the futility of trying to cram Vim into it expecting it to work without a Frankenstein's monster vibe. There's always something off or incomplete. I don't think I'll try it again soon, but if I do it would be with something like God mode; for one because Evil mode somehow breaks Emacs when run in the terminal, and also because Vim and Emacs just don't mesh together well imho. They are both excellent at doing very similar things, but their approaches are just not compatible.

Re: From Vim to Emacs in fourteen days (2015)

#163
post #41

Earlier quoted context omitted.

Vi's sense of composability. For example, 'd' is the delete command, but what does it delete? It deletes across a motion. What is a motion? Could be any movement mode supported by the editor, which ranges from simple cursor motions to motions involving words or blocks to forms of searching to raw line number jumps. So, once you learn a vi command, you can use it with all the motions you already know, and once you lea…

I've used vim for more than 20 years, but lately I'm finding that now that `prettier` and `black` can just reformat code wholesale, I don't have to care as much about the precise tiny edits that vim is so good at. And when I'm not worried about those things, I start to notice that modern IDEs have much smarter syntax checking and whole-project search than I've ever seen in vim, even with plugins. So I think I'm movin…

Yep, for me the peak right now is an IDE that has a great VIM plugin. You get the best part of vi (the insane productivity and wrist health increase that is modal editing) with all the best parts of a modern IDE.

I don't feel like I'm missing anything from a VIM-only setup in any way right now

Re: From Vim to Emacs in fourteen days (2015)

#164
post #153

Earlier quoted context omitted.

As always, the Emacs experience is better: https://github.com/zachcurry/emacs-anywhere :)

It's literally inspired by vim-anywhere.

I know. I use vim-anywhere because I never bothered to set up Emacs Daemon.

Re: From Vim to Emacs in fourteen days (2015)

#165

Earlier quoted context omitted.

I think the thing is that pylance is a python LSP. And it's proprietary. So they embraced python LSP, extends it so that the additions are proprietary. And pylance might become the defacto python LSP. Typical EEE. Python is hugely popular, it's everywhere - so even if one hates it, might end up having to use it. Also the remote extensions are proprietary [1]. This has been discussed on HN before. [1] https://github.c…

> So they embraced python LSP They did not embrace LSP. They invented it. LSP came from MS. > And pylance might become the defacto python LSP. Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.

> LSP came from MS.

Thanks, today I learned.

Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.

MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.

Re: From Vim to Emacs in fourteen days (2015)

#166

Earlier quoted context omitted.

> So they embraced python LSP They did not embrace LSP. They invented it. LSP came from MS. > And pylance might become the defacto python LSP. Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.

> LSP came from MS. Thanks, today I learned. Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions. MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.

I get where you're coming from. It's just amusing that many people talk about how great it is to use LSP with Emacs, but are simultaneously recommending not to use MS tools :-)

If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.

Re: From Vim to Emacs in fourteen days (2015)

#167

Earlier quoted context omitted.

Maybe, but prolonged emacs use causes carpal tunnel syndrome!

Only if you don't use a keyboard the way it was intended. For example, Ctrl-c should involve both hands. If you press Ctrl-c with only your left hand (there's a reason your keyboard has a right Ctrl), you will gradually hurt your wrists. Emacs can accelerate this, since a lot of things begin with Ctrl-x, assuming that you never use the right side Ctrl.

Macs don't have a right Ctrl, unfortunately.

Re: From Vim to Emacs in fourteen days (2015)

#168

I love emacs as a lisp environment to work in and have used it for 20 years but the emacs LSP picture is starting to look seriously sketchy in comparison with what more language-specific IDEs such as VSCode and PyCharm etc offer. Especially now that static typing is becoming standard in languages like Python and Javascript. If you have a lot of spare time you can probably make eglot and lsp-mode work in your favorite…

My experience with lsp-mode is quite the opposite. I was able to configure it with rust-analyzer/gopls/pyright for half a day and I would say that it is very close to "just works". Previously I was using VScode and emacs only for org-mode.

Re: From Vim to Emacs in fourteen days (2015)

#169
I want to love emacs with default bindings but find them unergonomic to the extreme. However I think VIMs bindings and multimodal text editing is a false economy, so I don't want to just use evil-mode (spacemacs or DOOM). In other IDEs and OSs there is a consistent scheme for copy, paste, undo, redo but no consistent scheme for new-line-above/below or movement near the home row keys using modifiers. I've been experimenting with alt+[some homerow keys] for movement and left-hand w/modifiers for changes similar to ergoemacs, in vscode. The realisation I've had is that there is an absence of standardized keybindings for text editing across IDEs/editors and the complexity and lack of interoperability rolling-your-own make that approach universally avoided. This means we are in a rut going back and forth between emacs and vim and OS keybindings, and the editor wars are just a symptom of a greater problem. The real issue is that there is not enough R&D on efficiency and human-oriented design and/or this hasn't influenced current standards to a great enough degree. Aside from in a terminal I'm not convinced (if timed/tested) the average coder using the mouse heavily with left-hand shortcuts would be any less capable than a vim guru. Accuracy with a mouse is something that can be improved too, just look at competitive FPS games. I'd also posit the mouse coder spent more time learning coding and less time fiddling with his tools.

Does anyone know where I could find more info about this stuff?

Does anyone know of any research comparing the efficiency/speed/stress of VIM users to, say, VS Code keybindings or emacs ones?

I am a productive vim user already and have just learned standard emacs bindings and ergoemacs bindings within a few hours. This is not a matter of a vim-naiive person avoiding learning the tool. I do have a preoccupation with tools rather than getting stuff done with them... That's our curse isn't it?

Re: From Vim to Emacs in fourteen days (2015)

#170

Earlier quoted context omitted.

> LSP came from MS. Thanks, today I learned. Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions. MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.

I get where you're coming from. It's just amusing that many people talk about how great it is to use LSP with Emacs, but are simultaneously recommending not to use MS tools :-) If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.

LSP is great. The thing about VSCode is dark patterns. VSCode is great, one sees that it's MIT licensed, downloads it uses it and is like wow nice. After a while realises that the official build is not FOSS licensed and contains telemetry code. So one finds 'VSCodium' which is a community port without telemetry. You carry on working but now remote things are not working. One looks why - the only reason is MS made it proprietary. Remote is essential for lots of developers. One feels f*cked by MS. Few years ago, Github's 'Atom' editor was getting popular. Then MS bought GH now Atom reduced to atoms - can't see it anywhere - though getting updated.
Post reply on HN