Live data from Hacker News

Neovim 0.5 is overpowering

crispgm.com

411–420 of 429 posts

Re: Neovim 0.5 is overpowering

#411
post #406

I see a lot of hate on Lua here. Anecdotal but I never wrote any plugins in vimscript. Since moving to Lua a week ago i’ve already written one, and will continue to where I find a use case. Vimscript sucks, using Lua will make it easier for people to contribute I think.

I agree that vim script needs replacement, but I don't know that Lua was the correct answer. It's not a super-popular language and makes some things harder than necessary. Base 1 arrays means you are almost certain to bake in bugs accidentally. Meta tables are even worse though. They result in many subtly different object systems. Maybe that's not as bad in a unified project, but it's the path to a fractured ecosyste…

1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both.

The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's frustrating when different libs are each using own OOP implementation. It doesn't matter too much because all those implementations are light and don't pollute the code base. Fractured ecosystem is both good and bad thing.

The string handling is kind of a pain point, especially if you are spoiled by Python. I have no idea how Neovim + Lua handle Unicode text?

Python is huge & complex language, as well as 10x slower than Lua. JS has more rough edges due to historical baggage, also a fast VM would be much much harder to integrate than Lua. I'd say they would both be worse choices for maintainability and Neovim usability.

Re: Neovim 0.5 is overpowering

#412
post #367

Earlier quoted context omitted.

There is a point when it doesn't make any difference if the language sucks or not. What matters is if it is capable. You can say the same about most successful languages: C sucks, shell script sucks, eLisp sucks, LaTeX sucks, but they're all there and will continue to be because they have been capable of support the communities for which they were designed. Now, you can freely dream about the perfect extension langua…

> Now, you can freely dream about the perfect extension language for UNIX, or vi, or TeX, or emacs, but it won't make any difference because nobody will move from something that works to an unproven extension language just because some people (usually the minority) feel that it is a more comfortable language for them. Lua ia an extremely powerful and popular extension language. It probably has at least 10x the users…

> Vimscript will most likely die with Vim

Which is just fine! Vimscript was created to create simple vim scripts, not to build full programs.

And if you need to do more than Vimscript can do, Vim already provides this: it has native bindings to Lua, among other languages. If Lua was such in demand to write vim scripts, at this point it should have taken over VimScript as the main extension language, but it hasn't, and I guess that unless something huge happens in the community, it won't.

Re: Neovim 0.5 is overpowering

#413

I'm a long time (20+ years) vim user, and neovim doesn't fit my use case. I've tried it, most recently today, to have a look at LSP and treesitter. Treesitter added different syntax colors, but the result wasn't necessarily better than vanilla vim. More like an overly decorated christmas tree. LSP and other "make it into an IDE" I usually turn off after a few minutes, it's more of a hindrance than a help. I mainly co…

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

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...)

Re: Neovim 0.5 is overpowering

#414
post #304

Earlier quoted context omitted.

Aren't these features are subject to external configuration to behave properly? For example, C/C++ and #defines. The user has to configure yet another file for this to work properly. If the build system/tree is so complicated that I can't figure out what the final #defs are (like building MBED programs with literally a thousand #defs), I end up shutting off this feature entirely. This kills me with VSCode & Sublime,…

You make your build system emit a compile-definitions.json file that has all the compiler flags for every file you compile and feed it to a language server (rtags or clangd usually, either standalone or part of another plugin like YouCompleteMe). CMake has a flag to do that as part of its configuration step (and remembers it), for other build systems you can use something like bear: https://github.com/rizsotto/Bear .

For future reference, as I found this information to be difficult to find: the flag for CMake is `CMAKE_EXPORT_COMPILE_COMMANDS=YES`. In out-of-source builds, the output file will be in the build directory, therefore one has to create a symlink to ensure the language server finds it in the project root.

Re: Neovim 0.5 is overpowering

#415
post #307
post #275

Earlier quoted context omitted.

I've always wanted to write Vim plugins, and as soon as 0.5 hits stable, I'm looking forward to trying! I won't touch VimScript with a 10-foot pole, and I write code for a living. It's not worth my time, and it does not commute to other things that I'd rather be spending my time coding.

But you can use Python to write Vim and NeoVim plugins already. It's arguably an even better language than Lua.

I don't have experience with Vimscript, but I know both Lua and Python. It seems that the biggest benefit is gained by stepping up from Vimscript to any of those two. Switching to the other would only have diminishing returns, if at all.

Apart from that, Lua was explicitly designed to be embedded. Python is designed as a scripting language that can bind to C code, and embedding seems to be an afterthought.

Re: Neovim 0.5 is overpowering

#416
post #406

Earlier quoted context omitted.

I agree that vim script needs replacement, but I don't know that Lua was the correct answer. It's not a super-popular language and makes some things harder than necessary. Base 1 arrays means you are almost certain to bake in bugs accidentally. Meta tables are even worse though. They result in many subtly different object systems. Maybe that's not as bad in a unified project, but it's the path to a fractured ecosyste…

1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both. The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's…

1-based indexing matters if you only code Lua occasionally (as you say, you get used to it when coding it all the time).

JS has better string builtins than Python IMO.

QuickJS is made for embedding and has similar performance to Lua (slightly slower). I don't think you'd want to embed a large VM like v8 anyway.

https://sabotage-linux.neocities.org/blog/9/

Re: Neovim 0.5 is overpowering

#417

It always feels really nice knowing that people are getting excited by your work. Thanks for the shoutout! (I'm tjdevries) Happy to answer any nvim questions while I'm here.

When is it going to get released?

There's a milestone and date here https://github.com/neovim/neovim/milestone/19 But the meme probably is just as accurate

Re: Neovim 0.5 is overpowering

#418

Earlier quoted context omitted.

Or, you could have hit qt, recorded your commands for the first change, and then replicated it for every other line with a simple @t, instead of redoing all the changes each time. You don't have to learn command. You simply need to know how to edit with VIM. And multi cursors only work for tabular data. The macro recordings can work for the entire document where you call a macro on a word/regex you searched for, for…

I always find it strange that people recommend a different letter for the register when recommending macros. Why not just use `qq` and `@q` (with the added advantage that clearing the register is `qqq`) ?

The reason I don’t use q is it’s far too easy for me to accidentally hit a 3rd q when I didn’t intend to and not even realize it.

This was a bigger problem when Apple decided to go with those butterfly keys.

Re: Neovim 0.5 is overpowering

#419
post #416

Earlier quoted context omitted.

1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both. The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's…

1-based indexing matters if you only code Lua occasionally (as you say, you get used to it when coding it all the time). JS has better string builtins than Python IMO. QuickJS is made for embedding and has similar performance to Lua (slightly slower). I don't think you'd want to embed a large VM like v8 anyway. https://sabotage-linux.neocities.org/blog/9/

I didn't know about QuickJS, last time I checked Duktape was most suitable for these cases. I see QuickJS was made by Fabrice Bellard himself. While linked benchmark is impressive for QuickJS, in case of Neovim they chose to embed LuaJIT which is ~10x faster than "official" PUC Lua. I see your point though, QuickJS would still be a good choice. JS and Lua are not that different once you set aside syntax differences.

http://luajit.org/performance_x86.html

Re: Neovim 0.5 is overpowering

#420
As long as I a can keep my fingers on the keyboard, and never touch the mouse, I may give it a try.

BTW: unlearning and editor is almost harder than learning a new one. I started with 'ed' in 1984, then 'vi' and plain text terminals (HP-2621) until the mid 1990s, when I get my first actual XTerminal. Then VIM from the mid 1990s until now.

The command aspect is highly underrated by people that don't know the commands. The ability to :>% a full block. Things like that.

I think that is why most long term Vim users sound like they are insane to other people. Note: In the early 2000s, I worked with a guy that only ever programmed on Windows with Visual Studio. We were coediting (side by side) a large file during some architectural changes, discussing it as we went, and I did one of those :g/this_old_thing/s//new_thing/gp changes on the file and he just yelled "stop". I though I had broken something. He just said what did you just do and how did you do that? So I undid, and slowly retyped the line explaining what each step did, and hit enter. He went out and got a vim book that night. I have to apologize for the mental damage that might have caused him (lol). He picked it up quickly, I showed him a couple plugin I use. (I don't use many, mostly plain stock Vim).

I have messed with VSCode a little. I may take a look at Neovim. I looked at it about four years ago, and I guess it just wasn't really ready yet.

Post reply on HN