Live data from Hacker News

Vim 9.0

vim.org

241–250 of 272 posts

Re: Vim 9.0

#241

Earlier quoted context omitted.

Nope. Back in the day that would greatly interfere with copy/paste. One way or another, it's so easy to see what line number you're on and/or jump to a specific line.

can't you just yank to +? you might need the vim build with +clipboard if it's not default these days

It's X11 only. So Wayland or remote users can not use it.

Re: Vim 9.0

#242
post #240
post #238

Earlier quoted context omitted.

Yes, because language developed at a time where people didn't know about zero.

Zero still would most likely wooldn't make sense. Zero is nothing, it can't be anything. Even ordinally. 1 is something and it fits very well for the first position... outside of programming :-)

In 1-based indexing, the index of an item is the number of items you've already seen, including the one you're looking at.

In 0-based indexing, the index of an item is the number of items you've already seen, excluding the one you're looking at.

Re: Vim 9.0

#243

What are some of the advantages of Vim’s domain specific scripting language over, say, providing a Python API?

Vim does provide a Python API :)

But most Vim addons seem to be written in Vimscript, and porting them to another language (which?) is a lot of work for little practical gain (for many/most addons).

Re: Vim 9.0

#244

Earlier quoted context omitted.

My understanding is that treesitter doesn't do anything with indentation. I believe the issues described in the linked issues are neovim specific. So it should be possible in theory to use treesitter data to calculate indents, though it seems difficult.

Treesitter does do indentation, but not well, and it is the sole mechanism of indentation for the Helix editor. Therein lies the problem.

Ah cool, I guess I completely missed that in my reading of the docs. Thank you for clarifying!

Re: Vim 9.0

#245
post #201

Earlier quoted context omitted.

Vim has had a long life before being moved to GitHub and it still isn't developed the GitHub way anyway, so those graphs are meaningless. Here are contributor lists I've gathered a few years ago from `:help versionX.txt`: https://gist.github.com/romainl/7b17317cc26a30116e51a3759022... That's 600+ non-Bram contributors up to the fork that the Neovim team made disappear from their project when they removed the relevant…

You mean 'the git way', all GitHub's doing is looking at commit authors (different from commit committers). A checked in file with a list of names is not the way to record that, I don't blame Neovim for removing it since that's basically useless anyway.

> all GitHub's doing is looking at commit authors

That's not accurate. It's also pruning from the resulting list the commit authors for which GitHub is unable to associate a GitHub account with a given contributor; it simply doesn't attempt to represent contributors who are not (known) GitHub users.

(That isn't to say there's any significance here to Vim; the Vim repo does genuinely obscure patch authors by not using the appropriate fields to capture that information—most commits, going by Git metadata, are attributed to Bram using that method. But the statement "all GitHub's doing is looking at commit authors", strictly speaking, is not true.)

Previously: GitHub's "Contributors" graphs are unreliable for working out who really works on a given repo. https://news.ycombinator.com/item?id=31421107>

Re: Vim 9.0

#246
post #3

I'm curious how many users are now using vim versus neovim. I switched a few years ago,and ever since Lua plugin support the Neovim ecosystem is thriving.

I've tried Neovim a few times but kept getting discouraged by things like pane navigation being different and the replacement for netrw seemingly not being able to be configured to have similar keybindings. Last time it was something to do with :term or :vertterm.

Re: Vim 9.0

#247

I'm curious: - How deep a rabbit hole do most people go down when setting up their vim / neovim environment? Apart from setting up a preferred color and language specific tab spacing and highlighting, I don't need more, but I've seen some pretty fancy setups. Out of the different plugins, which would you never operate without?

ALE and CTRLP are the most non-vimmish ones I guess. Most of my remaining plugins are extensions to Vim, like highlighting unique characters when pressing f, or highlighting my latest yank, or more text objects, or autopairs, surround, etc.

Re: Vim 9.0

#248
post #200
post #157

Earlier quoted context omitted.

Depending on your OS, you could use visual line mode and highlight the text you want to copy. Then you can run: ' w !xclip -selection clipboard to copy the text to your clipboard. Macs have another program that works similar to xclip, but I don't remember what it's called.

What's the advantage of this command over "+y ?

If vim doesn't have clipboard support enabled, then this is one way to copy and paste. The vim packages in the Fedora repositories are configured such that vim doesn't have clipboard support, but gvim does.

Re: Vim 9.0

#249

I never understood why use custom scripting and not one from the many already existing implementations.

Vim script has a long history and initially it emerged from vi commands. It is intended to talk to Vim internals, so any other language will always look and feel alien in this regard. I hope Vim script will continue evolving, albeit breaking backward compatibility.

Re: Vim 9.0

#250

Earlier quoted context omitted.

One is not a better parent by controlling their kids for their foreseeable future. One needs to let them join the world and grow on their own, with their own friends.

vim is open source, so everyone who wants can fork the repo and change the code however he pleases.

It’s true that anyone can fork the code. But splitting the user community and plugin ecosystem with forks should be a last resort. This discussion is about how a FOSS community can improve software while avoiding forks that result in incompatible code-bases.
Post reply on HN