Live data from Hacker News

The extensible vi layer for Emacs

github.com

51–60 of 104 posts

Re: The extensible vi layer for Emacs

#51

Earlier quoted context omitted.

NeoVim has got native LSP support, and works pretty well for me out-of-the-box for most languages. LSP servers need to be installed externally, but I hope they manage to bundle them somehow in the future. LunarVim already provides automatic LSP server installation.

I've always preferred having LSPs installed in my user bin folder (or system wide). I like to hop nto other editors and some of them, like Helix, do not have auto installer for LSPs and tries to use the locally installed package. In other words, I like to have 1 LSP installed in my system for all of them.

one kill ring to rule them all

Re: The extensible vi layer for Emacs

#54

Earlier quoted context omitted.

Neovim isn't emacs, and you can't make it emacs no matter how hard you try - Emacs is writen mainly in lisp, neovim has a lot of c. You don't have to worry about if something is possible in emacs, you can just hack onto it, on neovim you have to spend an awful lot of time seeing if something is possible - Emacs has decades of ecosystem, neovim does not - Emacs is build on lisp and has first class support, fennel is a…

As I said, If you're trying to use vim like emacs, you're doing it wrong. You can and people do, but that's not the point. See my second link on the subject.

On a thread about emacs, you posted about telling people to use vim. why do it if you aren't trying to get emacs users to use vim?

If someone told me to change my workflow just to use the same bindings, that gives me every reason not to do it more.

Re: The extensible vi layer for Emacs

#55

Just use vim. Yes, emacs has a lisp engine, but so does nvim[1]. Really, though, using vim properly means that it doesn't need to swallow the kitchen sink[2]. Just use vim. 1: https://github.com/Olical/aniseed 2: https://blog.djha.skin/p/emacs-users-im-okay-i-promise/

Very silly advice. I use both emacs (Doom, as my IDE) and vim (as my CLI editor - git commits, etc) and telling people to use either one instead of the other is like telling them to use a car instead of a bicycle, when they already have made a transit plan and are happy with their situation. Emacs is just simply bigger in scope than vim; its ecosystem of packages and functions is completely unparalleled in vim-world; and as for vim it is useful for simplicity, efficiency, and ubiquity. They serve different purposes and they are both good tools.

Re: The extensible vi layer for Emacs

#57
post #9

A light bulb went off in my head, is Neovim able to use Emacs as a GUI yet? Why emulate VIM in 2023 when you can just become a GUI for it. I'm still waiting for JetBrains to wake up from sleeping at the wheel and implement a Neovim client for their IDE core.

It's kinda embarrassing, JB wants to push their new editor, but even months after public beta, the vim emulator is still barely usable, and afaict it's maybe like 1-2 people working on this. I don't get it, if you are targeting developers, why is it that having Vim keybindings not a top priority? Or am I living in my own circle? https://youtrack.jetbrains.com/issue/FL-10664

In my experience anyone using something other than VSCode, or Major IDE is a noteworthy signal that the developer cares about their tools and is probably better than the median.

There's an interesting blog post from a recruiting company breaking down the data they have on editors and developer success in their interview process. https://triplebyte.com/blog/technical-interview-performance-...

Re: The extensible vi layer for Emacs

#59

I used that settings for a few years, then tried to move entirely to vim, and now I'm very happy with vscode + vim. I like vim as a touch typer, I think it's a setting that minimize end motions. It's also very convenient in the terminal. On the other hand, I think it's not convenient as an IDE: too many shortcuts, clumsy integration with LSPs, especially when you need to work with different languages. For me it works…

NeoVim has got native LSP support, and works pretty well for me out-of-the-box for most languages. LSP servers need to be installed externally, but I hope they manage to bundle them somehow in the future. LunarVim already provides automatic LSP server installation.

I doubt Neovim would bundle them.

I asked for two things which are conceptually much simpler:

1. a project manager/file explorer solution (file browser plugins have always been super popular for Vim; plus Sublime, VS Code, etc, all offer file explorers, they're extremely useful for... exploring projects for folks.

2. moving the command bar at the top

And they were both closed as WONTFIX mentioning that the Neovim core is meant to be compact and everything else should be built on top.

So that would require someone making and maintaining a super popular Neovim "distribution". I'm not saying it won't happen, but both in the Vim world and the Emacs one it doesn't seem like any distribution "won out" and you're always worried your distribution will just go away at some point.

Re: The extensible vi layer for Emacs

#60
post #48

Earlier quoted context omitted.

Spacemacs is also a good option. I use VSCode + vim for remote development which is super nice now, I think VSCode has by far the best remote development experience, I even use it as my main terminal. For local development I use Webstorm, Rubymine, intellij etc. with IdeaVim, this is mainly because I prefer not fiddling around with plugins and configs I want my IDE to “just work” no matter what language I am using. F…

Intellij/Webstorm doesn't "just work", at least for javascript: https://youtrack.jetbrains.com/issue/WEB-57184/wrong-warning... It's a real turn off that a commercial IDE can't get fundamental stuff like the one show in the bug tracker correct (or fixed in a timely manner). You start to question why you are even paying for the thing.

That's just a warning, though. Annoying, but it's not like you can't work because of it.
Post reply on HN