Live data from Hacker News

The Future of the Vim Project

groups.google.com

331–340 of 376 posts

Re: The Future of the Vim Project

#331
post #136

Earlier quoted context omitted.

If neovim had the same keystrokes to move out of a terminal window as it does to move out of editor windows, I'd switch. But as it is, it's super clunky compared to vim. I know about rebinding to alt, but that doesn't work in all my terminals. So for me, it's that one lousy thing that keeps me from switching. And if someone knows the magic setting to make it mimic vim, please let me know.

What keystrokes does vim use for this? I've never been a big user if terminals inside vim

[deleted]

Re: The Future of the Vim Project

#332
post #183

Earlier quoted context omitted.

With their recent release a few days ago, Neovide has become my daily driver for Neovim on my personal cpu. It were definitely rough edges a few versions ago, but I’m rather pleased where they are now. I find a lot of Rust GUI projects are slow-going but this has had a good pace

I’ll try it again in a few months, because it was completely unusable on macOS last time I tried it in March. At the moment, I have no time for something that may not work when MacVim works pretty much perfectly for me.

I've generally had more success with Goneovim than with Neovide, give that a try if you haven't yet.

Re: The Future of the Vim Project

#333
post #181

Earlier quoted context omitted.

Useful checklist: https://getyourshittogether.org/ Others in this thread have talked about safety deposit boxes and buried crates. I'd add that you can just give some trusted party a normal encrypted USB flash drive, and eliminate the risk of getting absolutely rinsed out in the event of a house burglary by splitting the password amongst an arbitrary number of your other contacts using the Shamir's Secret Sharing alg…

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.

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 distribute enough of them, I think there’s a reasonable chance they’ll recover your data.

As an improvement, distribute them not to your friends, but to their kids (the probability is higher they’ll be sane of mind when you die), and tell your attorney who has one.

I think that’s overkill, though. I’ve done it simpler: I wrote the full recovery codes down a few times and put them in a few places in my house.

I think that’s fine if I assume burglars won’t take them or won’t know what to do with them and I won’t die in a disaster that also destroys my house.

Re: The Future of the Vim Project

#334
post #138

What is it that prevents the rest of the vim community from adopting neovim? From what I can observe, a great deal already have. But for the folks holding out, what is it that outweighs all that neovim has to offer?

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

From what I've read[1], vim9script was pushed and developed almost exclusively by Bram. With him, a lot of knowledge about its internals and vision for its future dies.

[1]: https://github.com/vim/vim/discussions/12736#discussioncomme...

Re: The Future of the Vim Project

#335
post #253

Earlier quoted context omitted.

I wouldn't trust USB flash drives with anything long term. Best archival method would be to print something out (perhaps an encrypted message in a QR code), have it put away somewhere secure, and use that for a key to unlocking everything else.

Bitcoiners have been thinking about this storage problem for a decade now. Secure electronic devices in faraday cages and tamper and water proof bags or engraved steel plates (possibly cut up and distributed) seem to be the way to go for storing small bits of extremely valuable information. Or of course you can use multiple key storage techniques and have a 2 out of 3 or more type setup. It all depends on how valuabl…

Engraved steel plates cut up is actually extremely easy and virtually indestructible.

You can buy a piece of 100x50x3 mm 316 stainless steel (thats 4"x2"x1/8" in freedom units) for around $5.

Engraving it is a simple matter of using a $10 automatic center punch and write the password out in dot punched letters.

If necessary, cut plate in N pieces with a hack saw, distribute among N people.

I always mark bicycles this way, dot punch my last name underneath the bottom bracket shell.

Re: The Future of the Vim Project

#336
post #172

Earlier quoted context omitted.

I think that's fine; albeit a potentially awkward conversation, I personally would rather have known "hey, here's what you can get into, here is what is private" but we never talked about it at all. Especially important to communicate that in your case, on the off chance they want to hire a data recovery firm in some hope of saving wedding photos or something

> Especially important to communicate that in your case, on the off chance they want to hire a data recovery firm in some hope of saving wedding photos or something I share any photos with them they might want, but I hopeful that Apple's security setup prevents any practical data recovery. I know my family too well, if I explicitly said "this is private" they'd be trying to get in the moment I was cold. There's nothi…

Imagine once bronies age enough that they kick the bucket en masse and their families spend tens of thousands on data recovery only to discover "damn, that's a lot of horse porn."

Re: The Future of the Vim Project

#337
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…

Ah, thanks

Re: The Future of the Vim Project

#338

Earlier quoted context omitted.

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

neovim supports OSC 52 out of the box so clipboard over SSH should just wrk in kitty or any terminal that supports OSC 52. kitty of course supports a lot more than OSC 52 but for basic opy/paste of plain text, OSC 52 is sufficient.

Neovim doesn’t support OSC 52 unless I’m missing something. There’s an open issue: https://github.com/neovim/neovim/issues/3344

It’s easy to implement OSC 52 copy with a simple script/plugin, but apparently not paste without adding some code inside of Neovim itself.

Re: The Future of the Vim Project

#339
post #293
post #127

Earlier quoted context omitted.

> How's the vim ecosystem now? Is vimscript still dominant? You can have a full neovim experience with all sorts of modern extensions without using a single line of vimscript. Some people even replace their init (neovim's vimrc) with lua, but I am of the opinion that it is a step too far, as lua isn't particularly adapted to writing configuration files and the result is too verbose to my taste.

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

Re: The Future of the Vim Project

#340
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.

From what I've read[1], vim9script was pushed and developed almost exclusively by Bram. With him, a lot of knowledge about its internals and vision for its future dies. [1]: https://github.com/vim/vim/discussions/12736#discussioncomme...

You're correct it was very much a "Bram project", but that doesn't mean the language needs to die with him: other people can work on it (and already have!) Vim9Script is also "finished", more or less, as "finished" as languages get anyway. The features Yegappan mentions are what we might call "optional features".
Post reply on HN