Hacker News Reader

Yeah, I've used Vim since the mid-nineties too. At first it was my "edit a config file in my RedHat 5.2" tool. Later, the more and more actual software dev I did, it became a daily driver. I am pretty sold on the "Vim way".

I have a workflow. It's hard for me to adopt new things into my worflow because my workflow works so well. I finally made the switch to NeoVim just over a year ago because I wanted to see what the fuss was about. I have to say, it's now firmly entrenched in my workflow. It's to the point where I'd be annoyed if I had to go back.

The one sticky point about your post that I wanted to highlight:

>I personally don't like Lua much

I can say that almost anything is better than VimScript... I hate every moment I have to mess around with it. The hardest part is, I don't use it for anything else so every time I dive in, I have to remember how it works. At least Lua is a multipurpose language and documentation/help are plentiful.

But, I get that the whole intellisense, popup windows, bling... those things are not for everyone. If they don't enhance your workflow, then you're never going to desire them.

I'll ignore the other parts I disagree with in this post, since it's cool to have different views but I just wanted to post that it may someday be possible to run vim9script plugins in neovim :)

I'm working on a project that might allow at least 90% or higher compat here: https://github.com/tjdevries/vim9jit

Of course, vim9script isn't complete yet, so the spec isn't all the way done, but it may someday be possible to run them in neovim.

Additionally, if someone actually just wanted to port all the C code to run or has some other way to make vim9script run, neovim is not opposed to making that happen.

> Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree.

The problem here is that people use treesitter to add more colours to distinguish more types of tokens. For me this is too much and the colours lose their meaning. I recently switched to a colour scheme that only changes the colours for strings, numbers and comments. Treesitter allowed be to add very targeted minimal highlighting. For example, I know highlight the first line of a function definition. This makes it very easy to see function scopes.

We don't really need more highlighting, but meaningful highlighting. With treesitter you can do both.

Just a note on stability, you reference Neovim crashing when setting up Treesitter. That means you’re using an unstable version of Neovim as Treesitter and Lua configuration are in the unreleased version 0.5.

I’ve been using only stable Vim and Neovim and have not had either of them crash on me that I can remember.

> they removed gvim (which is what I use in most cases). There is no comparable third party GUI like gvim available. They're all either abandoned, unstable or simply very different with lots of bling and gimmicks.

I'm not sure I understand what you're missing from neovim-qt?

https://github.com/equalsraf/neovim-qt

I suppose maybe we have diffuse cases - but I'm fairly certain I'm running qt neovim, and not nvim in a terminal - and I'm not aware of any issues?

Thanks. I'd previously tried and failed a couple of times to get a NeoVim gui installed, mainly because I wanted to try one of those ligature fonts that display -> as → and the like. There seemed to be a few different options, in various states of being abandoned, or unpackaged, or needing libraries not in my OS, or ...

Turns out now all that's needed for Ubuntu is sudo apt install neovim-qt. Thank you for prompting me to look at this again.

However, on running it, the window seemed very wide, so one of the first things I tried was `:set columns=80` — and nothing happened. Checking :h 'co`, it looks like it's supposed to work.

Ah, and it seems the (released version of) QT gui doesn't support ligature fonts yet. The FiraCode website says it works with NeoVim-gtk: https://github.com/tonsky/FiraCode#user-content-editor-compa...

Maybe I'll give that another go ...

Does your language not support Unicode?

Some of my stuff is in Raku, which indeed supports Unicode operators. But other coding isn't, and it'd be nice to use ligature fonts for those.

Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1].

The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.

[1] https://www.youtube.com/watch?v=pW-SOdj4Kkk&t=2546s

I didn't watch the whole talk just the part you linked. I'm sure he makes some good points. But yeah, this guy does not understand why we have lsp's at all.

An LSP is a program that parses and internalizes a project written in a particular language and serves information, diagnostics, and edits, to a generic editor. The protocol is broad enough to serve all the "smart" language-aware functions provided by full-blown IDEs.

This allows one LSP to be used in ... many different editors. The advantage to the users is obvious: if go has one standard LSP, people who use neovim, vscode, vim, emacs etc all have an interest in maintaining that one LSP and will contribute to it in various ways.

Let me give you a few reasons why not only is it fine that it's a separate process, but you want it to be in a separate process.

1. LSPs will be better written if they themselves are written using runtime and the language that they serve.

2. LSPs can potentially hold a lot of memory. Sometimes you need to manage them, and potentially even cut them off, for example if you have a few very large java projects that you're switching between. Generally if they are separate processes, you can just kill them without affecting the editor. Additionally this also means the editor itself doesn't risk a memory leak caused by a rouge LSP server.

3. Subprocess management is not that hard. The editors can do it. Neovim does it pretty well in my experience. The presenter acts as if the server is some totally separate thing that you have to manage yourself. In reality the language server process is launched, managed, and owned by the editor, and often just communicates over stdin and stdout, not that there's anything wrong with ports.

Using multiple processes to distribute work among programs that do one thing well has always been the UNIX way.

He's definitely got a point. I had some memory problem with a business calculation I was running, I needed all the memory I could get.

So I looked at the various memory hogs on the linux installation and could see that every Vim invocation had a node process hanging off of it as a child, that's the Coc code completion/language server client running. (Action => only trigger coc for certain filetypes)

And I had vscodium running too, and it had its own long lived subprocesses hanging off of it, for language support, etc.

A lot of apps are like this - humongous clusters of processes (firefox, teams, vscode, and also Vim with the right plugins...)

I agree with you when it comes to basic config. Vimscript is better for setting options, basic mappings and events. Anything more complex then that is a pita in vimscript.

Agree totally. My experience with NVim 0.5, which is what most configs require, was errors and instability all over the place. I also don't like telescope which froze nvim on me completely.