Live data from Hacker News

The Future of the Vim Project

groups.google.com

351–360 of 376 posts

Re: The Future of the Vim Project

#351

Earlier quoted context omitted.

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. V…

Uhm if you read my comment it is specifically about how nvim doesn't change the preexisting behavior of vim. And if I were to believe you then compatibility with vim means compatibility with vi

I did read your comment word for word: “Of course this means you'd rely on Neovim maintainers honoring that compatibility in future.”

I knew that maintaining compatibility was extremely important to Bram Moolenaar. I also knew that Neovim made a big deal out of removing “cruft” and old stuff they decided no one needed. I preferred Bram’s values.

Re: The Future of the Vim Project

#352
post #293

Earlier quoted context omitted.

My config is a horrible frankenstein of both. I use lua when examples are in lua or when I need some "logic" (such as assigning defaults to a var and then passing that around/overriding). And that's embedded in vimscript. I don't really like either. VimScript has always been a horror to me, eventhough I've been using vim for some 20 years now, almost exclusively. Lua is "that thing that I should really sit down and l…

Lua is faster than Python and also easier to embed in vim [1] which are both big advantages for the end user. It means fast plugins and no hassle with having the correct python version. Why Bram build is own language and then doubled down on it with vimscript9 I don't really understand. [1] https://neovim.discourse.group/t/why-was-lua-chosen-for-neov...

> Why Bram built his own language [...] I don't really understand.

What language would have you chosen in 1991 instead of creating vimscript? The vimscript language is a very natural extension[0] of Bill Joy's "ex" language, that was used in vi since 1976. The history of vimscript is not weird, it's just a fairly natural continuation of existing practices. Vimscript9 is a least-friction update for modern times.

[0] https://en.wikipedia.org/wiki/Vim_(text_editor)#Vim_script

Re: The Future of the Vim Project

#353

Earlier quoted context omitted.

> what is it that outweighs all that neovim has to offer? You should ask, and answer, the question in reverse. What does neovim offer me, as a regular vim user? I don't see anything particularly interesting for my usage, so I don't have any reason to change. Also, some features are missing (like gvim-gtk, that I enjoy using to edit LaTeX occasionally). Furthermore, as of today, plain vim has an aura of venerability d…

Neovim's language server integration is a killer feature that got me to switch.

Can you explain the benefit? I'm not familiar with the feature.

Re: The Future of the Vim Project

#354
post #299

Earlier quoted context omitted.

Why would anyone amend the author in an open source project?

From what I can tell the reason is that that’s the way it was always done. As I understand it, back in the days before there were distributed version control systems, Bram was the only one who could commit to the code-base so he would credit the actual author of a submitted patch in the commit message. He continued this practice after the Vim project moved to Mercurial (and Git). Related discussion: https://github.co…

On reflection, it might have been clearer to have started my comment with:

“Taken at face value by most modern users of Git, the commit history does not accurately reflect the contributions to the code-base”.

Re: The Future of the Vim Project

#355

Earlier quoted context omitted.

Create transparencies with the text If you put at least 3 of these on top of each other, my Google recovery code will appear here: 2 £ 3 > ]7 7#A E (each with different characters shown, of course. Ask a mathematician to make sure any 3 will show the full code, and any 2 won’t show enough to recover it) Put them in envelopes, write “open in case John Doe dies” on them, and distribute them among friends. If you distri…

> I think that’s fine if I assume … I won’t die in a disaster that also destroys my house. You might not die, but you might still end up in a pretty bad position: https://shkspr.mobi/blog/2022/06/ive-locked-myself-out-of-my... Incredibly unlikely, of course, but you'll certainly feel like a dick if it does happen.

As someone who _has_ had their house burn down and had to recover their digital life from backups (successfully), this is why I've not made the step to yubikeys.

Re: The Future of the Vim Project

#356

Earlier quoted context omitted.

Uhm if you read my comment it is specifically about how nvim doesn't change the preexisting behavior of vim. And if I were to believe you then compatibility with vim means compatibility with vi

I did read your comment word for word: “Of course this means you'd rely on Neovim maintainers honoring that compatibility in future.” I knew that maintaining compatibility was extremely important to Bram Moolenaar. I also knew that Neovim made a big deal out of removing “cruft” and old stuff they decided no one needed. I preferred Bram’s values.

and I responded to your "exists to change things". Vim also exists to change things, otherwise it wouldn't exist if Vi was enough. but it is compatible and from my experience nvim is compatible with vim.

Having to rely on them for that is a downside, but I guess you are free to fork nvim if they abandon that promise...

Re: The Future of the Vim Project

#357
post #13

My brother passed away very suddenly a few years ago, and I was put in charge of wrapping up and archiving his "digital" life. We were very lucky that we had access to a recovery email for his main gmail account (as well as a couple of passwords that his partner knew) and was able to access and archive virtually all data we could think of (services like Google Takeout were invaluable). I realized that if this had hap…

I've recently been planning for my death, no urgent need, but you never know. I've put a backup of my keepass passwords on a USB as well as a printout of the passwords and the master password in a firebox. I also keep a list of assets and financial accounts in there along with birth certificates and passports. My spouse and I both have a key. I would have used a safe deposit box but those are disappearing.

Please remember that USB storage needs to be recharged every so often, or the data will be lost.

Re: The Future of the Vim Project

#358
post #243

Earlier quoted context omitted.

You're talking about two totally different things. GP is saying Vim users generally have muscle memory of their shortcuts (I might add, to the extent that some of them may not even be conscious which keys they are pressing). GP also mentioned that Vim takes less mental effort (due to muscle memory) and is faster. The faster part is easy to argue even from a theory perspective. Your hands basically never leave the hom…

> How is that relevant? I keep reading and hearing folk claiming that X is faster, as in this thread. It would be nice to read some actual study showing this to be true, but it seems like it mostly ends up being strongly held opinions based on anecdotes. You say it's easy to argue. Sure, it's easy to argue but that doesn't make it correct. I could argue in the other direction and then we end up wasting our time.

> "It would be nice to read some actual study showing this to be true"

https://danluu.com/keyboard-v-mouse/ - concludes that it varies by situation; keyboard wins at tasks where you might expect keyboard to win, mouse wins at tasks where you might expect mouse to win, tools like regex search/replace wins at tasks where you might expect it to win.

Re: The Future of the Vim Project

#359

Why so many people love vim? I have a genuine question. I was trying to delete contents of a file and paste new content. It was nightmare for me to remember the 3 or 4 finger combination shortcuts with small and cap letters involved during the process. I like if the shortcuts using Ctrl or shift or Alt or Command or Windows buttons over 3 finger with caps changing keys. The cognitive load in remembering shortcuts is…

If you install graphical Vim (gvim) on Windows, I think the installer offers to remap Ctrl-c and Ctrl-v to copy and paste. You also get the standard GUI menu bar at the top with Edit -> Select All, Edit -> Copy, Edit -> Paste which you can click on.

Re: The Future of the Vim Project

#360

Earlier quoted context omitted.

Likewise. I’m a heavy CLI user but gVim/MacVim are so entrenched in my workflow that the lack of a stable GUI for Neovim made it pretty much a nonstarter for me.

As some one who only uses vim/neovim in a terminal window - what’s the advantage of having GUI support in vim? Mouse support in my terminal seems fine, even over ssh. Being able to do things like run it inside of a tmux session has always made it seem like the GUI would be a step back?

You can use gVim as a Notepad on steroids. You have the simplicity and familiarity of Notepad combined with the power vim, e.g. search & replace using regular expressions, syntax highlighting, the ability to delete 5 words by typing ESC d 5 w, plugins like fugitive and so on. I can't select text in neovim by pressing Shift and arrow keys. I can't copy text by pressing Ctrl+C.
Post reply on HN