Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of the Vim Project

groups.google.com

Post reply on HN
Print view View original

281–290 of 376 posts

Re: The Future of the Vim Project

#281

Post by arp242 »

nequo wrote: post #250
arp242 wrote: post #138

Earlier quoted context omitted.

- It's not backwards compatible. - Features I find useful have been removed. - I dislike Lua, and significantly prefer Vim9Script. - Gvim is useful at times.

Out of curiosity to better understand the ways in which Vim can be used: > Features I find useful have been removed. Which ones specifically? > significantly other Vim9Script What do you like more in Vim9Script? > Gvim is useful at times. What are your use cases for the GUI?

I'm pretty sure I wrote a long comment about all of this at some point, but I can't seem to find it right now; this is the closest: https://news.ycombinator.com/item?id=21954164

If I look at some Lua plugins and compare that to some of my Vim9Script (or even "legacy VimScript") plugins then I think /Vim9?Script/ "wins" hands-down; it's just much more convenient for programming an editor. It also doesn't help that IMHO Lua isn't all that great of a language to start with – it's not horrible either, just not great.

On Windows gvim works loads better (even on Unix systems gvim is arguably better, because terminals kind of suck and you run in to loads of graphical and input limitations pretty quickly).

But in general: neovim doesn't offer me anything I want or need, I will have to spend time on migrating (e.g. my vimrc would error out, I need to deal with changed defaults, etc.), and for most things I prefer the "highly compatible" attitude from Vim/Bram, which is a trade-off that's not without its downsides, but I really like it (for most software).

Re: The Future of the Vim Project

#282

Post by ed »

pr0zac wrote: post #248
atoav wrote: post #202

Earlier quoted context omitted.

I'd say a regular will, sealed at a notary is just okay. If you are really paranoid, why not write a service that works like a dead mans switch and when you don't trigger it for n days it sends all the keys to the kingdom to those who should receive them.

Google actually provides this service: https://myaccount.google.com/inactive?pli=1 At this point I've moved almost everything off Google and basically now only use my Gmail account for logins on websites I don't want to give my real email address to and to keep Inactive Account Manager setup to send the necessary info to get into my 1Password account to my brother if I die. I have a will setup with all my financial d…

That’s a helpful link! Do you know if google allows access to Gmail once inactivity is triggered? Ideally my contacts could use it to recover access to my password manager.

Re: The Future of the Vim Project

#283

Post by NobodyNada »

random_mutex wrote: post #258
kzrdude wrote: post #40

Earlier quoted context omitted.

One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. I'm sure neovim dropped a lot but I don't have the full overview. Prominently it dropped support for giving !commands access to the actual tty. Commands that access the tty have to be used through the command :term instead. Neovim prominen…

>One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. What's wrong with all features enabled by default? > I'm sure neovim dropped a lot but I don't have the full overview. https://neovim.io/doc/user/vim_diff.html >Prominently it dropped support for giving !commands access to the actual tty.…

> Why would you run an interactive command with `:!` ?

I ran up against this limitation recently. The kitty terminal exposes APIs allowing processes to communicate with the terminal using escape codes. I wanted to configure Neovim to access the system clipboard using kitty’s API, so that I could copy/paste from within Neovim even over SSH. However, this would require Neovim to give the clipboard subprocess access to the controlling TTY. (Running it within :term would not work, as the escape sequences would thus be passed to Neovim’s virtual terminal emulator, not the instance of kitty that Neovim itself is running within.)

Re: The Future of the Vim Project

#284

Post by jagged-chisel »

atoav wrote: post #202
sshine wrote: post #181

Earlier quoted context omitted.

I call this a Horcrux. Also, unless your arbitrary number of friends are cryptographers, it's a sure way for them to collectively lose your shit.

I'd say a regular will, sealed at a notary is just okay. If you are really paranoid, why not write a service that works like a dead mans switch and when you don't trigger it for n days it sends all the keys to the kingdom to those who should receive them.

Step 1: Kidnap $target

Step 2: keep for N+1 days

Step 3: …*

Step 4: profit!

* where “…” just means “wait”

Re: The Future of the Vim Project

#285

Post by cossatot »

nequo wrote: post #250
arp242 wrote: post #138

Earlier quoted context omitted.

- It's not backwards compatible. - Features I find useful have been removed. - I dislike Lua, and significantly prefer Vim9Script. - Gvim is useful at times.

Out of curiosity to better understand the ways in which Vim can be used: > Features I find useful have been removed. Which ones specifically? > significantly other Vim9Script What do you like more in Vim9Script? > Gvim is useful at times. What are your use cases for the GUI?

Personally, I do heavy coding and writing in Neovim (with more extensive config, like LSP and Copilot), but I use macvim and gvim (depending on which OS I'm using) for quick edits or file viewing, because I often need to open files from Finder or Nautilus and I don't have a terminal open in that directory.

Re: The Future of the Vim Project

#286

Post by massysett »

throwaway290 wrote: post #240
massysett wrote: post #212

Earlier quoted context omitted.

My Vim needs are very modest. I just don’t need anything Neovim has. It’s complication I don’t need. If Vim got no new features, I wouldn’t care. If Vim became unmaintained but still available from distributions, I’d still use it. If Vim became unavailable (e.g. due to lack of maintenance) I’d be more likely to switch to nvi than Neovim. I could probably switch to nvi now, but I have no reason to.

FWIW you can use Neovim like Vim with your existing config, without any of the other stuff. That made the switch easy for me. Of course this means you'd rely on Neovim maintainers honoring that compatibility in future...

One of the things I really like about Vim is how it maintains compatibility with Vi. The manual obsessively points out features Not in vi. It retains some ill-advised things like :Print because Vi had them. Ancient platforms still work, supposedly.

I care about this not because I used Vi (I never have) but because it’s less likely that some new Vim with a newer distribution release will do something I don’t expect. Vim does want I need it to do. I don’t want it to change.

Neovim on the other hand exists entirely to change things. That’s all well and good. I just don’t want it. My editor is complete.

Re: The Future of the Vim Project

#287

Post by JetSetIlly »

Dobbs wrote: post #76
ftaghn wrote: post #27

Earlier quoted context omitted.

I would not be so prompt to compare the situation with Apple and Jobs. Apple is a company that provides something no one else does while also holding a lock on its users. You can't go and install iOS apps on android. On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim. I would not be very optimistic for the future of vim considering that nobody…

> On the other hand, vim and neovim are almost the same thing, and wherever they diverge, it is always to the detriment of vim. They are quite different at this point and personally I prefer vim over neovim. I've never gotten NeoVim to work satisfactorily. I've had issues with the async setup where the backend and frontend start having issues with each other or lag. So on. Personally I find vim to be a lot simpler to…

You've hit the nail on the head for me. From my point of view, vim is simpler than neovim. I value that and wouldn't like to see neovim subsume it (although I'm sure people are happy with neovim for very good reasons)

Re: The Future of the Vim Project

#288

Post by kps »

random_mutex wrote: post #258
kzrdude wrote: post #40

Earlier quoted context omitted.

One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. I'm sure neovim dropped a lot but I don't have the full overview. Prominently it dropped support for giving !commands access to the actual tty. Commands that access the tty have to be used through the command :term instead. Neovim prominen…

>One "meta feature" that was dropped was the ability to build the editor with or without different features. vim --version shows a long list of +/- features, neovim doesn't do that. What's wrong with all features enabled by default? > I'm sure neovim dropped a lot but I don't have the full overview. https://neovim.io/doc/user/vim_diff.html >Prominently it dropped support for giving !commands access to the actual tty.…

> Why would you run an interactive command with `:!` ?

Why wouldn't you? Vi's `:!` is simple and general.

If neovim has an equivalent, it must be obscure enough that no one has mentioned it yet, and it seems to me that the obvious thing to do would be to make `:!` do it by default, and put neovim's current `:!` behaviour behind a `compatible` flag for those who want it.

Re: The Future of the Vim Project

#289

Post by tuwtuwtuwtuw »

medeshago wrote: post #274
tuwtuwtuwtuw wrote: post #227

Earlier quoted context omitted.

I don't know, I'm not the one who made the claim that X was faster than Y. Are you saying that studying how efficient various text editors are for some groups of people is not possible? Here's what I believe to be an example of some study on how text editors compare: https://mjambon.github.io/vim-vs-emacs/ Not saying that this is a good study - I haven't even read it. Merely providing it as an example that at some po…

I'm not saying that you can't do it, you obviously can. It's just weird asking for studies for something that was clearly a personal annecdote. It's like asking someone: "Which knife is your favorite knife?" getting an answer and asking for a study that validates the answer.

Sorry, English is not my first language so I guess I misinterpreted it. What I was replying to was:

> Assuming you've given time to learn it, editing with vim takes less mental effort and is faster.

What gave away that it was a personal anecdote? I interpreted the "you" part as if he was speaking generally about other people and not only himself

In my main language, we would have written something like below if it was a personal anecdote (rough direct translation):

> I was able to edit faster using Vim after taking the time to learn it.

Re: The Future of the Vim Project

#290

Post by __tmk__ »

pmoriarty wrote: post #105
infinitezest wrote: post #62

Earlier quoted context omitted.

Maybe not important to some but the ability to use Lua over VimScript is a big win in my opinion. In fact, I use a mix of thr two where necessary.

How much of the rest of the vim ecosystem is Lua-based, though? As far as I know it's still mostly vimscript. Vimscript's dominance in vim is one of the things that got me to switch to emacs when I got interested in Lisp and Scheme more than a decade ago. Sure, even then I could write scripts for vim using Vim's scheme compatibility mode, but I'd probably be one of the only ones doing so. Pretty much everyone else wa…

I've also seen neovim plugins written in fennel [0], so if you want something lispy, that's possible now.

[0]: a Lisp that compiles to Lua, https://github.com/bakpakin/Fennel

Post reply on HN