[HN Gopher] Vim 9.0
___________________________________________________________________
Vim 9.0
Author : craftuser
Score : 129 points
Date : 2022-06-30 18:42 UTC (4 hours ago)
(HTM) web link (www.vim.org)
(TXT) w3m dump (www.vim.org)
| Yuioup wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=31907883
| givemeethekeys wrote:
| 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?
| cercatrova wrote:
| Out of everything, if I want to use (neo)vim as a serious code
| editing environment, it has got to be LSP support. To that end,
| I use coc.vim although of course there are many other LSP
| plugins.
| rbongers wrote:
| Definitely ALE. Being able to use LSPs is the only reason I
| haven't switched.
| kirillbobyrev wrote:
| I've spent so much time on configuring my (Neo)vim over the
| years I wouldn't even be able to estimate it (here it is if
| you're curious: https://github.com/kirillbobyrev/dotfiles/tree/
| main/.config/...).
|
| The most important ones lately seem to be the LSP integrations
| (basically IDE features like autocompletion, go-to-definition
| etc) and auto-completion managers. But honestly it's been
| breaking all the time over the last year or so that I code more
| often in VSCode and maybe it's about time I stop trying to make
| an ever-improving IDE out of Neovim :(
|
| Neovim project's direction seems to be aligned with making it
| easier to have IDE-like experience with LSP integration but
| it's been painful in Neovim. In Vim, it's typically even worse
| and even harder to set it up.
|
| Overall, I've been using Vim for about 8 years and went from a
| really simple set-up of "this is just a text editor" down the
| IDE rabbit hole. I also went for Vim -> Neovim -> Vim -> Neovim
| and eventual split of the two configs in the end and. I'm
| thinking about making it much simpler again :D
| Diederich wrote:
| I've been using vi/vim on a near daily basis for 34 years now
| and this is the only thing I put in ~/.vimrc:
| set tabstop=4 set expandtab set shiftwidth=4 " or 2
| or whatever set shiftround syntax on
|
| EDIT:
|
| Just for some fun archeology, I google searched on the 3rd
| line, 'set shiftwidth=4 " or 2 or whatever' because I very
| dimly recall copying most of my standard set (minus the syntax
| on bit) from someone else a long long time ago. This was the
| only hit I found:
|
| https://www.perlmonks.org/index.qs1968.pl/perlmonks.org?disp...
| threatofrain wrote:
| No line numbers? @_@
| bayindirh wrote:
| It is already present on the lower right by default. Why
| lose a column?
| cassepipe wrote:
| Then I can easily go to the line I want to go. :34 takes
| me to line 34
| imron wrote:
| It makes it easy to jump to other lines on your screen,
| e.g. maybe you want to split out half the code from a
| loop to another function. You can't use di{ to delete
| everything in the {} because you only want half of it,
| but if you can see that the loop contents end on line 98
| you can go d98G
| bluenose69 wrote:
| I like line numbers because when I'm editing code in a
| remote meeting, I or someone else can refer to lines by
| number. The current line is not the only one that
| matters. I use relative line numbers because I like doing
| e.g. 9k or whatever. Others on a remote call often refer
| to other parts of the code with "9 up" or "9 down" (since
| "9k" and "9j" sound too alike in a noisy call).
| bayindirh wrote:
| You can selectively turn them on as a meeting aid, no?
| Diederich wrote:
| Yup that's what I do as needed, which for me is pretty
| rare.
| necheffa wrote:
| I mean, I have a 32" 4k monitor for a reason.
| avgcorrection wrote:
| Reason being outdated indexing UX?
| bayindirh wrote:
| I mean, every column counts, even in a 32" 4K display.
| Also, not all of us have the space to fit these screens
| everywhere we work.
| Diederich wrote:
| 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.
| theposey wrote:
| can't you just yank to +? you might need the vim build
| with +clipboard if it's not default these days
| deadbunny wrote:
| I have vim use the clipboard by default, with that said I
| still use the mouse to copy stuff now and then.
| AlecSchueler wrote:
| :set nu!
|
| Just toggle them off when you copy/paste, then on again.
| Takes a fraction of a second.
| billti wrote:
| Similar, but you can do most of those in one line! I also
| turn on line numbers and map "jk" to Escape in insert mode:
| set expandtab shiftwidth=4 softtabstop=4 tabstop=4
| syntax on set number inoremap jk <Esc>
| ben174 wrote:
| I tried that 'jk' thing way back, and I seem to recall it
| introducing some lag. Like a few milliseconds so it could
| process and see if you were hitting the followup key. Just
| enough to be annoying.
| addcninblue wrote:
| The lag thing is due to this:
|
| If you type `j` in insert mode, it waits to see if
| there's a possible `k` following. That's the lag.
|
| There's a setting for how long it waits.
| jcranmer wrote:
| TIL about set shiftround... that would definitely help with >
| commands...
| imron wrote:
| Almost identical to mine, except I set ai and nu, and wasn't
| setting shiftround (because I didn't know about it until
| today!)
| pbohun wrote:
| Doesn't expandtab mess with creating/editing makefiles?
| Diederich wrote:
| It surely can. If I have to casually mess with a Makefile,
| I'll just remember to use control-v TAB as needed, or vi
| yank/put another line with a proper tab and edit. In the
| very rare case I'm doing more serious work, I'll
| temporarily turn it off.
| mr_toad wrote:
| It's been a while but I seem to remember being able to
| configure different tab behaviour specifically for make
| files.
| Bromeo wrote:
| Having gone from a stock vim to a highly modified vim and back
| again, here are some plugins that I find really boost my
| productivity:
|
| - neoterm, for opening a REPL in a split buffer and quickly
| sending chunks of lines to the REPL
| (https://github.com/kassio/neoterm)
|
| - fzf for faster buffer and file navigation
| (https://github.com/junegunn/fzf.vim)
|
| - vim fugitive for good git integration
| (https://github.com/tpope/vim-fugitive)
|
| - some other tpope plugins (surround, unimpared, commentary,
| vinegar)
| jl6 wrote:
| I put some time into learning vanilla vim to a fairly basic
| level, about 20 years ago. It's been sufficient ever since.
| Occasionally I look up rarely used commands, but as far as I'm
| concerned my configuring days are over.
| VTimofeenko wrote:
| I've gone down that rabbit hole quite a few times and each time
| for a much longer period than I am willing to admit. I use
| neovim for hobby development and as a general text editor.
|
| The plugin that I find myself using all the time is vim-
| surround with a couple of minor language-specific tweaks.
| [deleted]
| kzrdude wrote:
| I'd always use airline and show a buffer line with it.
| dbrueck wrote:
| No idea if I'm typical or an outlier, but I have a couple of
| syntax highlighting plugins, NLKNguyen/papercolor-theme, a vim
| rc file with my favorite keybindings (e.g. faster navigation
| among splits), and a python file with some helpers for opening
| terminals in vim and... that's it.
|
| Every once in awhile I think I might do a fancier setup but
| then I lose interest. Ditto for checking out neovim. I'm sure
| I'd get some gains, but I guess I've sort of settled into a
| decent sweet spot that I haven't left for almost a decade, haha
| (been using vim for ~25 years total).
| aidos wrote:
| It's definitely a deep rabbit hole. There's a lot to figure out
| - even as an old vim user moving to a more modern neovim setup
| about a year ago.
|
| One of the issues I found was that every plugin seemed to
| reference other plugins and you need to figure out how to make
| them play nicely together yourself. Most of the best info is
| just buried in GitHub issues and neovim was such a moving
| target that everything needed more digging into to get working
| correctly.
|
| For me now essentials include; Telescope, Trouble, Cmp and a
| good LSP setup.
| trufas wrote:
| The fzf plugin is really nice for navigating through files and
| for code search, but not really necessary.
|
| The editing plugins I use most heavily are probably vim-
| surround and vim-commentary. My development would definitely
| slow down without them.
| hulitu wrote:
| I don't set anything. I use vim as vi.
| nobleach wrote:
| For me, I'll say "never ending-ly" deep. I've been hacking on
| Vim for the last 20ish years. First plain old Vim, and in the
| last 3 years, NeoVim. Even this morning I started by switching
| out VSnips (snippet manager) for Luasnip. I am always looking
| at things that could make my dev life more streamlined. I don't
| really care so much about having a bunch of bling plugins
| (although I do have a nice status bar, and a file tree). I'm
| more looking more at the things that I do on a day to day
| basis. Are there existing plugins that fit those patterns? If
| there are, I try them out. Sometimes I have to write the
| functionality myself. (Want to console log the variable under
| my cursor, with a label? Done.)
|
| Since this editor (and Emacs) are SO extensible, it's hard to
| find two long-time users with similar configs.
| JulianWasTaken wrote:
| It depends what kind of person you are, how much energy you
| want to invest, how much patience you have for stuff that isn't
| the code you're writing, how much you enjoy editing itself,
| etc.
|
| I have a quite extensive setup
| (https://github.com/Julian/dotfiles/tree/main/.config/nvim)
| which I built up over 10+ years, indeed sometimes including
| sitting there for an hour or two and just investigating plugins
| or writing some function to make editing easier. I enjoy it,
| and it means I can do lots of things in my setup that involved
| time investment.
|
| Others obviously just want to get on with their work.
|
| To me though part of the reason I _use_ vim /neovim is because
| anytime something annoys me about editing I can automate it, or
| find a plugin which has done so already.
| [deleted]
| mikl wrote:
| Shame that Bram is doubling down with vim9script. This will give
| vimscript a Python 3 moment, splitting an already small community
| into even smaller pieces.
|
| I wish he'd have embraced Lua like Neovim. It has already been
| proven to work great (half my plugins are Lua these days, and it
| performs great), but alas, it was not to be.
| capableweb wrote:
| As Vim9 comes alive, and Neovim community focuses on Lua plugins
| instead, it seems this release is finally the update that will
| put a hard branch on the two communities. Up until now, most
| plugins (except Lua-only ones of course) have worked in both
| editors, but it doesn't seem like Vim9 will be supported in
| Neovim, so I guess what people go with now, will decide what you
| might stick with in the future (unless you're eager to switch
| development environments).
| tomtomtom777 wrote:
| Although I am currently tip-toeing on NeoVim, I still feel this
| is a horrible break-up.
|
| Yes, Open Source simply allows you to branch whenever you're
| unhappy with the original but this comes at a cost for the
| community. The cost of having two diverging programs to deal
| with.
|
| In this case, the motivation was simply insufficient. Some
| people wanted vimscript+lua instead of vimscript. They felt the
| code was too difficult. They wanted to develop on their own.
|
| Not bad reasons in itself, but does it weigh against the
| tremendous cost for the community of the split? Isn't a split
| only justified in situation like OpenOffice/LibreOffice when
| there is no other choice? Couldn't they not convince Bram
| Moolenaar of proposed changes, and if not, doesn't this have a
| good reason.
|
| I hate NeoVim for the reason they've split, even though I
| understand it might become even better than Vim in the long
| run. You need better reasons to fork and divide an ecosystem.
| kzrdude wrote:
| Neovim has already been very productive by giving Vim some
| good competition and in so doing having better features come
| out in Vim.
|
| To me it doesn't make sense to 'hate' neovim for wanting to
| develop features that they tried to have in Vim but couldn't
| due to the main developer stalling it.
| bobbylarrybobby wrote:
| I think Neovim had a whole bunch of other reasons to split.
| I'm pretty sure that Neovim's server mode, which allows it to
| be used with other editor frontends, is simply not present in
| vim. For me this is the whole reason to use Neovim. But I
| think it also natively supports tree sitter and/or LSPs,
| which really improve the coding experience.
|
| Anyway iirc Neovim wanted these features integrated into Vim
| itself and only started a separate project when it became
| clear that that wasn't going to happen. My understanding was
| that at the time Bram was hostile to lots of the changes that
| people wanted integrated. You can read some of the discussion
| [here](https://news.ycombinator.com/item?id=14245705) and
| [here](https://news.ycombinator.com/item?id=7287668)
| deadbunny wrote:
| And when Bram did finally add async support rather than
| take the neovim work and us that he did it in a
| specifically non compatible way. I don't know the ins and
| outs but as an observer that does come across as a little
| petty.
| teilo wrote:
| Vim was stagnant until Neovim became a threat. And it was
| never about Lua. It was about the need for async. Bram
| ignored the community, and so the community responded, and
| made something better.
| otikik wrote:
| It could be also argued that if Vim wanted to keep the
| community together they could have just deprecated vimscript
| and adopted Lua.
|
| Of course I am stretching things a little, I know.
|
| I personally think Neovim's reasons for a fork are valid.
| They wanted some parts, not others, and they were willing to
| pull the work. So a fork is made. That is all ok. If my
| memory serves both projects have interchanged patches and
| improvements in both directions, so everyone has benefitted
| in some ways. The community (communities) will live on.
| akerl_ wrote:
| Nobody needs to justify forking a project to other people.
| Tyr42 wrote:
| I mean all Bram had to do was accept the async patches
| instead of ignoring them.
|
| Then neovim wouldn't have got off the ground.
|
| Once they started building, they wanted to "cut the cruft"
| and just went from there
| capableweb wrote:
| > In this case, the motivation was simply insufficient. Some
| people wanted vimscript+lua instead of vimscript. They felt
| the code was too difficult. They wanted to develop on their
| own.
|
| > Couldn't they not convince Bram Moolenaar of proposed
| changes
|
| I think (but someone correct me if I'm wrong) it started out
| with one of the persons who started Neovim, tried to get in a
| patch adding async support in Vim, but Moolenaar didn't want
| to merge it, for one or another reason.
|
| That cascaded to a bunch of other reasons over time, like
| adding Lua support and trying to rely less on Vimscript.
|
| But that's how I remember it being started at least, but I
| could remember it wrong.
| rickstanley wrote:
| Is there something equivalent for LunarVim[0] or NvChad[1], in
| Vim ecosystem? I want to try something different. I learn a lot
| hacking around these opinionated setups.
|
| [0]: https://lunarvim.org/
|
| [1]: https://nvchad.github.io/
| bern4444 wrote:
| Yes, there is spacevim: https://spacevim.org
| cercatrova wrote:
| For emacs with vim keybindings, there is also Spacemacs
| https://www.spacemacs.org/
| threatofrain wrote:
| Does anyone have a good from-scratch setup guide for Neovim?
| NERD_ALERT wrote:
| https://github.com/LunarVim/Neovim-from-scratch
| azemetre wrote:
| What do you want to do? My best advice would be to search up
| some dot files from people you may follow on GitHub. There are
| all kinds of configs, but typically just fork someone's you
| like then make minor tweaks. Here's mine, I also linked the
| three people I copied from in my read me:
|
| https://github.com/azemetre/dotfiles
| undoware wrote:
| I loved vi for decades, but I don't miss it. Neovim is my current
| go-to but even this feels stodgy these days. Helix Editor is
| probably my future -- it manages to have just the right features,
| but with saner defaults and syntax -- but it will take a while
| for me to work up the nerve to let go of the investment in muscle
| memory.
| BaculumMeumEst wrote:
| I don't think going all in on treesitter is very practical,
| considering basic python indentation has not been functional
| for over a year. I think Helix is a little bit too much of
| niche layered on niche, and Kakoune is much better all around
| in my experience.
|
| https://github.com/nvim-treesitter/nvim-treesitter/issues/80...
| cassepipe wrote:
| I am currently looking forward Helix too. I like the Kakoune
| philosophy (Object - Action rather than the contrary) better
| and I like the out of the box experience they are aiming at.
|
| I never really enjoyed having to configure vim. What I like
| about vim is the idea of modal editing which and the fact it
| runs and interacts in/with the shell. Still waiting a bit more
| before making the jump.
| the_duke wrote:
| 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.
| cge wrote:
| Neovim occasionally has really basic functionality regressions
| compared to vim: I switched back to preferring vim after
| realizing that neovim silently deletes all ACLs on a file
| (https://github.com/neovim/neovim/issues/1200).
|
| However, I use Emacs and VS Code for more involved editing, and
| mostly use vim as a light remote editor via SSH, so my
| priorities may be very different.
| bcrescimanno wrote:
| This comment thread on the previous conversation has a lot of
| good replies:
|
| https://news.ycombinator.com/item?id=31908731
|
| A few highlights:
|
| * "If it ain't broke, don't fix it"
|
| * People don't like Lua (or just simply prefer VimScript)
|
| * Divergence over time means that they are not still
| compatible.
| alex_smart wrote:
| > People don't like Lua (or just simply prefer VimScript)
|
| :shock:
| Beltalowda wrote:
| I prefer VimScript over Lua. VimScript is really not that
| bad of a language and I think its deficiencies have been
| greatly exaggerated, and Vim9Script fixed most of the
| oddities that were in there (e.g. '1' == 1 and such,
| JS/PHP-style).
|
| Lua, on the other hand, won't give me an error if I mistype
| a variable name, and the ecosystem doesn't really have good
| static analysis tools to catch these kind of silly errors.
| There's some other things I don't like either, like how
| "arrays" are really just hashmaps, as well as some other
| things. The whole versioning story wrt. compatibility is
| also annoying (it's basically a Python 2/3 story with
| _every single Lua version_ ).
|
| It's not Lua is _horrible_ , but the fawning over it from
| some Neovim people is something I always found curious,
| like it's a fantastic brilliant language. Meh, I found it
| quite average overall, at best. And if I look at some Lua
| vimrcs or plugins then it's all a lot more verbose and
| awkward than VimScript.
|
| Not that VimScript is _perfect_ by any means, but overall I
| find it 's quite a decent DSL for an editor.
| krylon wrote:
| > People don't like Lua
|
| Who doesn't like Lua? That is right up there next to
| disliking kittens and puppies...
| azangru wrote:
| Arrays start at 1?
| Macha wrote:
| > * People don't like Lua (or just simply prefer VimScript)
|
| Lua is not my favourite language, but I'd sure take it over
| vimscript.
| gkfasdfasdf wrote:
| I switched over to neovim a few years ago and haven't looked
| back. The embedded language server is awesome.
| agotterer wrote:
| I switched to NeoVim and then back to Vim a few years ago. I
| ran into some bug that prevented my setup from working
| correctly that forced me back. Vim has been working fine for me
| and I haven't found the motivation or a reason to try and
| switch again.
| aidos wrote:
| It was only in the last year or so that neovim really hit its
| stride. Features like treesitter provide the basis for some
| really interesting functionally.
| nobleach wrote:
| I stuck with Vim for a long time. I had friends that made the
| jump and honestly, around version 0.4.3, it still didn't seem
| to offer anything I cared about. So I stuck with my decade old
| .vimrc. I had started to get into CoC stuff, and NeoVim was
| just starting to release their native LSP integration. On a
| whim, I decided to give it a shot. I ended up sticking with it.
| Now there'd have to be a heck of a good reason for me to go
| back. I never enjoyed VimL. Any of the personal plugins I've
| written, I've had to struggle through writing. While Lua isn't
| the most amazing language either, I do like it far more. I feel
| like NeoVim's ecosystem is pushing the boundaries far more than
| Vim but, isn't that kinda what Vim wanted? They want to remain
| the conservative slow-moving text-editor. There's nothing wrong
| with that at all!
| hossbeast wrote:
| The headline should point at the actual release announcement on
| vim.org
|
| https://www.vim.org/vim90.php
| dang wrote:
| Ok, changed from
| https://groups.google.com/g/vim_announce/c/f_-N3hYxK20. Thanks!
___________________________________________________________________
(page generated 2022-06-30 23:00 UTC)