[HN Gopher] Neovim v0.5
___________________________________________________________________
Neovim v0.5
Author : todsacerdoti
Score : 294 points
Date : 2021-07-02 16:10 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tbabej wrote:
| I've been using neovim since the initial fork. The Neovim 0.5 is
| by far the most impressive milestone yet. I tried it couple of
| months back (before release) and immediately jumped to support
| the developers through the Github Sponsors after trying it out.
|
| https://github.com/sponsors/neovim
| kdheepak wrote:
| Thanks for your work on taskwarrior!
| asymmetric wrote:
| Are there release notes somewhere?
| thrwn_frthr_awy wrote:
| Lua remote plugin host Lua user-config: init.lua
| Treesitter syntax engine LSP client for code
| navigation, refactoring Extended marks (text
| properties, decorations, virtual text)
|
| From https://neovim.io/roadmap/
| cturtle wrote:
| There is a draft on the GitHub wiki here:
| https://github.com/neovim/neovim/wiki/newsletter-%2311-:-the...
| pythux wrote:
| I found this to be pretty comprehensive (not sure if this is
| the final release note, though):
| https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...
| gen220 wrote:
| Is anybody else uncomfortable about the idea that an LSP client
| is now baked into the editor (as opposed to being a plugin)? Are
| there big performance gains to this approach?
|
| While LSP is great, it basically came from nowhere in the last
| couple of years. My concern: what if something definitively
| better comes along in another couple years, and we're "stuck"
| with this baked into the editor?
|
| For context, using ALE, I've been able to gracefully migrate my
| language-specific helpers from pre-LSP to post-LSP universes,
| over the years as LSP helpers have become definitively better and
| faster, one language at a time, all without needing to recompile
| or download a new binary.
|
| I'm very open to the idea that I'm missing something obvious,
| because I have a lot of respect for neovim and neovim
| contributors. I understand that neovim is not trying to replace
| vim but evolve it. This feels like a move away from plugins and
| into monolith territory, which feels like a _big_ step. Curious
| to hear other 's thoughts.
|
| To be clear, I'm not for or against this, I'm mostly curious
| about the reasoning / thinking behind this, if anybody has links
| I'd love to read them.
| nicoburns wrote:
| Presumably it's disablable. So if you want to use something
| else you can just turn it off and then use the plugin of your
| choice.
| blindseer wrote:
| I'll give you my perspective (I'm just an average user):
|
| 1) nvim's built in lsp client is entirely in lua and afaik none
| of it is related to the nvim core. It is not inconceivable to
| just move it to a plugin but pretty much everyone will have to
| depend on it. I think for something as powerful as lsp, it
| might as well be bundled.
|
| 2) the built in lsp client in lua is EXTREMELY customizable and
| lightweight. In fact, a lot of useful features are enhanced or
| extended with plugins. Putting the onus on plugin writers to
| rewrite essentially the same functionality is not ideal.
|
| 3) The people that built the lsp client are extremely
| passionate about it and have contributed to neovim. tjdevries
| has some youtube clips and twitch stream clips where he talks
| about why this is a good idea. One thing that was mentioned
| during the stream today was that luajit and using libuv / LUV
| makes you feel like why not write an LSP client in nvim lua.
|
| I personally think since it is so lightweight and since it is
| all in lua, it's awesome to have. And the next big thing can
| also be added to nvim base in lua without too much "cruft".
| thayne wrote:
| > Putting the onus on plugin writers to rewrite essentially
| the same functionality is not ideal.
|
| This goes back to my biggest complaint with the vim ecosystem
| (and emacs has the same problem): no dependency management.
| Almost every plugin has to be self contained, because if you
| depend on another plugin, then you need to rely on you users
| to manually install that plugin.
| celeritascelery wrote:
| Emacs does not have the same problem. When you install a
| plug-in it will install the dependencies as well.
|
| However one thing I wish emacs packages had was the ability
| to version dependencies. Right now you can get a broken
| plug-in because the upstream package introduced breaking
| changes.
| Asooka wrote:
| Doesn't really bother me. Vim has had tags support for decades,
| so adding another very common source indexing service is fine.
| typon wrote:
| I have been an nvim user for the past few years now. I tried
| the whole modern nvim experience with Telescope, built in LSP
| and other Lua based extensions.. My conclusion is that my
| current setup with Ale, FZF + silver searcher, clangd/pylint
| and Deoplete is way faster, less buggy, albeit harder to setup.
|
| Also I'm just too old to learn the whole Lua API.. That's not
| something I hold against nvim, but it's a reflection on my
| laziness? I just want a good vim based experience and nvim did
| that for me.
|
| Btw, I paid for Onivim2. Was surprised by its snapiness but
| it's pretty useless as a working editor if you want equivalent
| features to nvim
| fernandotakai wrote:
| >Btw, I paid for Onivim2. Was surprised by its snapiness but
| it's pretty useless as a working editor if you want
| equivalent features to nvim
|
| how would you compare to nvim? i tried vsc with a vim plugin
| and it was just... painful.
| typon wrote:
| VS Code is an awful editor in general. I don't understand
| how it's so popular. Maybe it's just me but I don't like
| having 300ms lag between every action I perform on my
| editor. The vim emulation is a joke.
|
| Onivim's vim emulation is great.. Because it's literally
| using libvim. It's also very snappy. But thats where the
| advantages end.
| Tehchops wrote:
| > VS Code is an awful editor in general. I don't
| understand how it's so popular. Maybe it's just me but I
| don't like having 300ms lag between every action I
| perform on my editor.
|
| I'm surprised to hear this take. I've been a Doom Emacs
| user for a while, and while it was a bit more elbow
| grease to get it running on OSX, it was generally worth
| it for the speed/flexibility...
|
| _until_
|
| I ran into a non-trivially large Terraform code base.
| Slowed.to.a.crawl.
|
| On the other hand, even with multiple plugins, VSCode
| was(and continues to be) _very_ snappy. Nearly
| instantaneous search and motion.
| e12e wrote:
| FYI the few times I've half-earnestly tried emacs+evil
| one of the reasons I've gone back to (neo)Vim is that
| emacs feels sluggish.
|
| I'm sure at least one time spacemacs was partly to blame
| (aka ALL THE THINGS activated/installed) - but it's
| definitely a difference in "feel" where (Neo)Vim feels
| closer to vi, and emacs feel closer to vs code/Atom.
| thayne wrote:
| > I don't like having 300ms lag between every action I
| perform on my editor
|
| Well if you are used to IDEs that also had that kind of
| lag...
| gen220 wrote:
| FWIW, your "vim stack" is identical to mine. I also use a
| python lsp implementation, plugged in to ALE.
|
| I'd mirror your comments, and especially emphasize the speed
| aspect. (I think your ordering of comparisons matches the
| ranking of differences).
| nerdponx wrote:
| Having LSP and Tree Sitter in Neovim is less "monolithic" to me
| than having Netrw.
|
| Plus, the rest of the application is becoming increasingly
| modular, not less so.
| qbasic_forever wrote:
| It's not enabled by default, you have to install language
| servers and turn them on one by one.
|
| And given the extensible core of neovim, if a better LSP-like
| system comes along someone will build a plugin to integrate it.
| Before this native LSP support there was (and still is) an
| excellent vim/neovim addon coc.nvim that adds LSP support using
| nodejs as a process manager for example.
|
| LSP is very anti-monolith by design. Each language has its own
| little microservice LSP server that communicates to the editor
| using json-rpc. Everything can be swapped out and replaced
| dynamically--nothing is linked together or a direct dependency.
| prince781 wrote:
| > This feels like a move away from plugins and into monolith
| territory, which feels like a big step.
|
| I don't consider LSP to be a monolith. You still have the
| decentralization of language server development. Rather, LSP is
| just a standardization of what we have come to expect from
| editors interacting with plugins. And because the standard is
| modular in its features, the barrier to entry for new language
| servers and editors remains low.
|
| As a standard, I don't think LSP encourages monopolization the
| way that the web does for browsers.
| kzrdude wrote:
| Well, VSCode has a controlling position in the LSP ecosystem,
| so we literally have microsoft looming over it.
| gen220 wrote:
| To be clear, I was saying that integrating LSP into neovim
| makes neovim more monolith-y than it was prior, not that LSP
| was a monolith! :)
| prince781 wrote:
| Ah, I misread your comment. My apologies.
|
| Yeah, perhaps this does make neovim more a monolith, as
| there are already great plugins like coc.nvim that can be
| used. However, I believe the expectations of a modern text
| editor have been raised sufficiently in the last few years
| that we now expect to have code intelligence baked in, just
| like we came to expect baked-in syntax highlighting decades
| ago over editors that lacked it back then.
| MaxBarraclough wrote:
| For anyone else wondering:
|
| * _LSP_ means _Language Server Protocol_ [0]
|
| * _ALE_ means _Asynchronous Lint Engine_ [1]
|
| [0] https://microsoft.github.io/language-server-protocol/
|
| [1] https://github.com/dense-analysis/ale
| ibraheemdev wrote:
| And, ALE has LSP support.
| gosukiwi wrote:
| I also use ALE, and my main reason not to switch is that I
| also want to run linters, and I don't want to install a
| separate linter plugin when I know ALE works just fine for
| me.
|
| It would be interesting if ALE could integrate with nvim's
| LSP implementation though, although I'm not sure how that
| would work.
| toxik wrote:
| ALE is amazingly useful even for curmudgeonly old timer Vim
| users. My one gripe is that I want the warnings to disappear
| once I begin modifying the buffer, which I have achieved. Can
| post the relevant part of my vimrc if desired.
| Keyframe wrote:
| Count me as interested!
| cyberpunk wrote:
| Yes please :)
| phonebucket wrote:
| I actually started using Neovim builds from master to get
| access to built in LSP before this release. It's faster and
| lighter weight than any other LSP client I've used (I have used
| vim-lsp and languageclient-neovim in the past).
|
| From my understanding, it's also an opt-in feature, so you are
| free to use anything other language client or no language
| client at all.
|
| But I agree with you that Neovim is gradually becoming more
| monolithic (though I believe it's still very snappy and light).
| I'm pretty happy about it, though.
| vogre wrote:
| I would actually LOVE to see VIM with NerdTree, File/text
| searching, lsp and first class git support baked in and
| integrated well without need of tuning something in your .vimrc
| file every weekend.
| city41 wrote:
| And I would hate to see NerdTree baked in. So I'm glad we
| have choices via plugins.
| pawelduda wrote:
| For filesystem navigation there's ranger/nnn
|
| For text/file searching there's fzf + rg + fdfind
|
| All these tools integrate with eachother but are already
| great on their own.
|
| With nerdtree and other alike plugins you lock yourself into
| building IDE out of vim. With these specialized tools you can
| reap their benefits even without launching vim.
| [deleted]
| pault wrote:
| I know it sounds snarky, but at some point of vimrc
| complexity it's worth considering just switching to vscode
| with the vim extension. It can use neovim as a back end and
| you get mountains of features out of the box. I created vim-
| idiomatic key mappings to all the vscode features and
| extensions I commonly use. It's not vim, it uses a shit ton
| of memory, and you can't run it in the terminal, but I love
| it. For context, I was formerly a vim snob for 10 years. I'm
| also mainly a typescript guy so YMMV.
| goerz wrote:
| > at some point of vimrc complexity it's worth considering
| just switching to vscode with the vim extension
|
| Sure, it's worth considering...
|
| > It's not vim, it uses a shit ton of memory, and you can't
| run it in the terminal
|
| You just answered your own question on why it's not
| necessarily a good idea ;-)
| fernandotakai wrote:
| >I know it sounds snarky, but at some point of vimrc
| complexity it's worth considering just switching to vscode
| with the vim extension.
|
| i've been using vim for 10+ years. i tried vsc with a vim
| extensions and it's just not the same. maybe it's just
| because i'm super used to my vim config, but vsc + vim
| plugin feels so awkward and slow.
| JasonSage wrote:
| Another nice aspect of Neovim 0.5 is that you can do the
| entire configuration in Lua, so you can break out your
| config into multiple files and have things more organized
| and compartmentalized.
| ibraheemdev wrote:
| To each their own. I personally love my monolith init.lua
| :)
| epicide wrote:
| I don't see this often talked about, but some of the
| biggest value that (n)vim provides for me is _that_ I 've
| configured it myself. I know what's in my .vimrc because
| I'm the one that put it there. It takes me longer to add
| new features [0], but once it is set up how I want it, I
| understand it more deeply.
|
| My data is purely anecdotal but I've noticed a correlation:
| people who spend the added time to configure their editor
| (be it vim or vscode) tend to be better at using their
| editor. It naturally follows that the time spent
| configuring it leads to a better understanding (and better
| recall) of how it works.
|
| In my mind, the big "omnibus" plugin bundles for (n)vim
| prevent that understanding just as much as a default vscode
| config does [1].
|
| [0]: Either by adding a plugin or, in most cases, by
| incorporating what I want into (n)vim's existing systems.
|
| [1]: And no judgement for that -- not everybody has time or
| patience to deeply learn every tool they use.
| coldtea wrote:
| > _While LSP is great, it basically came from nowhere in the
| last couple of years. My concern: what if something
| definitively better comes along in another couple years, and we
| 're "stuck" with this baked into the editor?_
|
| LSP is not going anywhere. Nor has it been here just for a
| "couple of years". It's here for over 5 years already.
| ibraheemdev wrote:
| For anyone else who couldn't find the changelog, it's in the
| commit message:)
| https://github.com/neovim/neovim/commit/a5ac2f45ff84a688a094...
| jpe90 wrote:
| In my experience, the built in LSP is a mixed bag. Getting
| language servers configured is a breeze, diagnostics and go-to
| definition work just fine. But trying to get autocomplete and
| snippets to work is an exercise in frustration. There's a handful
| of different hobbyist implementations which are all somewhat-
| maintained and somewhat work together but it's buggy and you end
| up needing to do 20x the effort of using VS code to get not quite
| the same ease of use.
|
| I really hope they'll do some official work on lua-based
| solutions for autocomplete and code snippets in the future to
| really round out the LSP support, if that's something that they
| want to highlight as a feature of neovim. I still think VS code
| is the way to go if you want LSP features, but 0.5 is a terrific
| step forward and everyone who worked on it should be very proud.
| davidkunz wrote:
| I have zero problems with nvim-compe [1], it works like a
| breeze.
|
| [1]: https://github.com/hrsh7th/nvim-compe
| natrys wrote:
| I have a question. Once you hit the tab and get a list of
| completion items through either completion-nvim or nvim-
| compe, how do you further narrow down the list? All I can do
| is cycle through items or match by prefix, but I want further
| narrowing by matching substring/regex/flex anywhere in the
| items a la Ivy/Helm from Emacs (or any of the so many
| completion systems available in Emacs).
| jpe90 wrote:
| I didn't have issues with compe until I started using
| snippets, at which point I needed to manually modify the lua
| code that they provide for you (to own and maintain yourself)
| for tab completion. I had to spend a fair amount of time
| getting the right compe - snippet provider setup that would
| populate correctly.
|
| Once I added snippets and modified the completion code, the
| ability to hit "Enter" to select an autocompletion selection
| broke and I couldn't manage to fix it without preventing the
| key from entering a newline in insert mode. I ended up just
| remapping it to a new key. But even then, it's still a little
| quirky- if I type some text and hit tab expecting to add some
| spacing, I'd instead get prompted for autocomplete
| suggestions I wasn't looking for.
|
| I get that all this is fun for some people, but I just want
| sane defaults that work like VS code.
| YuukiRey wrote:
| Last I used it it was often missing completion candidates
| https://github.com/hrsh7th/nvim-compe/issues/248 which was
| extremely frustrating but apparently hard to fix
| qbasic_forever wrote:
| Yeah coc.nvim is a much better experience in my usage. I want
| to love the native LSP, but the hodgepodge of in-progress or
| abandoned completion, suggestion, signature, diagnostic, etc.
| UI is a big pain point right now.
|
| For example I have to install 3 different plugins to get all
| the LSP UI so it means I have 3 different opinions on how
| various parts of its UI should look and it's a real mess--the
| popups for suggestions as I type are totally different looking
| compared to the popups to show function signatures (and each
| has their own bespoke way of being configured).
| mjlbach wrote:
| Hi, neovim core member here.
|
| Which UI plugins do you need? We've done a lot of work
| leading up to 0.5 in improving the built-in handlers, so you
| shouldn't _need_ a UI plugin. I think the main plugins people
| install (in addition to lspconfig):
|
| * nvim-compe (autocompletion)
|
| * vim-vsnip (snippets)
|
| * lsp_signature.nvim (automatically pop up signature window,
| note signature_help is built-into core, just manually
| triggered)
|
| Some people use lspsaga.nvim, but borders are already merged
| into the core handlers (and our floating windows now provide
| better markdown styling than lspsaga), so the main utility of
| lspsaga is in the different way of interacting with code
| actions, which I personally do not prefer.
|
| Anyways, please open an issue or PR if you have concrete
| suggestions (or start a discussion on our discourse)! I'm
| personally very invested in improving the UX around the
| built-in language server client, and it has really improved
| leading up to the 0.5 release.
| qbasic_forever wrote:
| I tried nvim-compe, but it explicitly doesn't support
| signatures (see https://github.com/hrsh7th/nvim-compe#does-
| not-work-function... ). So I installed the recommended
| lsp_signature.nvim and it's a bit of a mess. The UI for
| lsp_signature has enormous borders and doesn't match at all
| with the rest of compe.
|
| Perhaps there are ways to tweak lsp_signature UI... but at
| this point, I chucked it all and went back to coc.nvim
| which does it all (suggestions, signatures, etc.) all with
| the same UI.
|
| Make it like that--make it work with all UI out of the box
| and not make me dig through tons of plugins. That's my
| honest suggestion. Sorry I'm not joining a discord, etc. to
| give this feedback.
| mjlbach wrote:
| I understand the frustration (making neovim more cohesive
| is definitely a goal). It sounds like coc provides the UI
| you are used to, so there's no harm in sticking with
| that!
|
| Many of our users explicitly don't want automatically
| called functions that would slow down the editor
| (autocommands that map signature requests to the language
| server, for example), so by nature neovim's core
| implementation is extremely conservative.
|
| One thing I would like to do, is make the automatic pop-
| ups for signature easier to implement with our current
| handler, which means a plugin like signature-x could use
| our upcoming lsp.config option to configure it's borders
| (https://github.com/neovim/neovim/pull/14681), and match
| the rest of the UI.
|
| I also have another project I was working on before the
| 0.5 stabilization phase
| (https://github.com/mjlbach/neovim-ui). The goal with
| this is to have composable/overridable UI elements built
| into core (which we would use for our internal lsp
| functions), that can be used (or overridden) by UI
| plugins.
|
| In summary, I think the likelihood of autocompletion (and
| generally auto-anything) being built-into core is very
| small, but providing the APIs in neovim core to make
| snippets - autocompletion - automated UI elements easier
| for plugin authors is a high priority.
| jpe90 wrote:
| This has been my experience as well. Coc.nvim was far
| smoother sailing.
| ibraheemdev wrote:
| Hm, mine worked out of the box with `nvim-lspconfig` and
| `completion-nvim`. What 3 different plugins are you referring
| to?
| luke2m wrote:
| Could someone sell me on why I should switch to this from regular
| Vim?
| daliusd wrote:
| One friend tried to switch from neovim to vim and found that
| vim is slower even if everything works. Otherwise no reason to
| switch.
| vlunkr wrote:
| Originally the big selling points (IMO) were that it supported
| async plugins and an embedded terminal. Vim added both of those
| in version 8. For whatever reason this issue bugs me enough to
| keep me from switching
| https://github.com/neovim/neovim/issues/1496. I tend to open
| things like :!tig and neovim can't do it.
| gorjusborg wrote:
| To me, there are two big things:
|
| 1. Development model (vim=Bram, neovim=communitiy of people) 2.
| Movement to a more accessible language for writing plugins
| cturtle wrote:
| I've been using the nightly builds for a while now, and the
| language server support works very well, but for me the most
| exciting part of Neovim is Lua. Lua isn't the headlining
| feature of v0.5, but the API has still grown a lot since the
| last release.
|
| As an example of why I love Lua support, I wrote a small file
| finding plugin for myself because I wasn't satified with the
| many alternatives (not a huge fan of fuzzy-matching). It took
| only a couple days to have a working plugin, and it has been
| fun to extend it with new features over the last month. The Lua
| API is relatively straightforward, and it really lowers the bar
| for writing plugins and small helper functions to add to your
| config.
|
| Switching from Vim is not necessary, but Lua support alone was
| enough to convince me to give it a try, and is the main reason
| I have stayed with Neovim.
| ratorx wrote:
| Integrated LSP is quite nice (and the ecosystem around it is
| just getting started), but it's not the thing I'm most excited
| about.
|
| My favourite new thing is actually tree-sitter. Currently it's
| being hyped for better syntax highlighting (which is nice), but
| I'm most excited about defining text objects on language
| constructs. I really don't like trying to shoehorn words,
| sentences and paragraphs to deal with parameters, scopes,
| functions etc. Having language-aware text objects for these is
| really neat.
|
| I don't think it's anything that would be impossible to get
| working in Vim, but being built-in is pretty nice.
| gooseyard wrote:
| I did it a while back to see if I would notice anything
| different. I moved to vim a few years ago on a whim after using
| emacs for decades, so I am far from a vim power user, but with
| the modest configuration I use, I couldn't tell any difference,
| so I figured I would keep using it until I ran into a situation
| where neovim failed in some way that vim didn't. So far (maybe
| 6 months?) I haven't run into any issues, and I don't think
| I've added any plugins to my setup that would only work with
| neovim. This is all to say, it's probably a fairly easy
| experiment to switch with a fairly low risk of issues if you
| switch back.
|
| I'm probably a bad neovim reviewer though since I'm not really
| keen to try the LSP stuff. I wind up working in a lot of
| different languages and inevitably I feel like getting
| accustomed to completion working well in language A only to
| have it fail with B is more annoying than having no completion
| at all. I'm curious whether I'll wind up using anything which
| is only possible in neovim.
| pasabagi wrote:
| Well, a lot of people have come up with good reasons, but for
| me, it really comes down to the old repairman's adage: there
| are two kinds of people, those that piss in lifts, and those
| that do not.
|
| Now, pretty much any programmer can read a lua program, and it
| takes about an hour to learn, whereas I think the most
| flattering honest word anybody has ever used to describe
| vimcsript as is 'pathological'.
|
| For the second kind of person, vimscript is like some
| combination between russian roulette and vogon poetry, bomb
| defusal and surreal nightmare. For the first kind of people - I
| don't know, there are probably some upsides, but honestly, who
| does that? Do you? That's what you have to ask yourself.
|
| And more, if you're not that kind of person today, do you want
| to become that person?
| humility wrote:
| lots of stuff. but mainly:
|
| * ease of getting started. nvim is just vim, you can bring over
| your vim config and it'll just work.
|
| * integrated lsp. you could have vscode like auto completion
| natively
|
| * tree-sitter. google it to believe it
|
| and much, much more
| thiht wrote:
| > tree-sitter. google it to believe it
|
| After Googling I have no idea what it is, it's a parser but
| for what? Syntax highlighting? That doesn't seem so
| impressive
| e12e wrote:
| https://tree-sitter.github.io/tree-sitter/
|
| Yes, but it enables many tools to cooperate on
| highlighting/"understanding" synntax.
| njharman wrote:
| My vim config includes bunch of customization for bunch of
| plugins written in vimscript. Will that just work?
| kellyjprice wrote:
| Probably. I have not had any problems switching between the
| two. It's meant to be a drop in replacement, but I'm not
| sure how perfect that is.
| jamal-kumar wrote:
| There's a few really cool things. The built in LSP is pretty
| clean compared to clunky nodejs or python plugins which I've
| found to clog down on huge codebases. The syntax engine has
| been improved by a tree-sitter algo, so it's way more robust
| with the syntax hilighting. And while I haven't messed with
| this yet you can do the whole config file in Lua now, which
| sounds pretty powerful.
|
| The improved tree-sitter code parsing also allows for stuff
| like this which you won't find fully implementable in mainline
| Vim yet:
|
| https://github.com/nvim-telescope/telescope.nvim
| xvilka wrote:
| Let's hope it will be updated in distributions quickly.
| ibraheemdev wrote:
| It's already on the arch and brew repos.
| rosetremiere wrote:
| I'm using neovim with Coc (often does not work as I want it to)
| and ALE and friends, and it's getting sort of frustrating. It's
| lots of fiddling with the vimrc, each year a new better extension
| that I can never make work, etc. What I'd like is some editor
| that integrates LSP, treesitter, FZF and friends so I don't have
| to configure everything, while still having the modal+command
| model of vim. Recently there was an editor that seemed to fit the
| bill (I think called Hex), but it seems those "keyboard oriented"
| editors are more usually "american keyboard oriented", in that
| the bindings don't make sense for non qwerty keyboards, and
| remapping everything is frustrating. Essentially, I think I want
| an full-featured IDE with vim's extensibility and modal approach.
|
| What's the solution?
| pkilgore wrote:
| I've been really hopefull it's onivim. I suspect you'll have
| the same issue with default bindings unfortunately.
| qbasic_forever wrote:
| VS code + the popular vim keybinding/mode extension for its
| editor.
|
| I love neovim and have been using 0.5 for 1/2 a year now,
| loaded up with all the bleeding edge LSP, treesitter, etc.
| stuff and I have come to the exact same conclusion. The
| ecosystem is just a bit too immature and fragile right now with
| tons of still-evolving things. The quality of each LSP varies
| wildly and it's a huge wild west right now figuring out the
| 'right' way to move configurations to lua, use a package
| manager for plugins, etc. You're left with a weird frankenstein
| state of half your tools and plugins in the new lua world, half
| still in the old world.. and a net loss of features and
| functionality as stuff is abandoned or changed in the process
| of moving. It's exhausting to keep up.
| hkmaxpro wrote:
| LunarVim: A Neovim config made with sane defaults
| https://github.com/ChristianChiarulli/LunarVim
|
| LunarVim will be like Spacemacs/Doom Emacs/SpaceVim, but for
| neovim. A distribution of useful neovim packages with sane
| defaults.
|
| This project is still at its early stage and many things change
| rapidly. You currently cannot easily keep your custom changes
| in sync with LunarVim, but support for this feature is on the
| way.
|
| In a few months this project should be stable enough for
| typical users.
| xvilka wrote:
| A reminder for everyone who wants to sponsor NeoVim's development
| - you can use GitHub Sponsors[1] now.
|
| [1] https://github.com/sponsors/neovim
| xwdv wrote:
| The best developers and engineers I've known all used Neovim.
| Coincidence?
| UI_at_80x24 wrote:
| You don't know enough developers or engineers. Much like; "If
| you find that you are always the smartest person in the room,
| you are in the wrong room."
|
| Healthy communities are diverse not homogeneous. You get
| tunnel-vision if everybody always do things the same way. I use
| vim on all my servers. I tried neovim awhile ago, but found
| that muscle memory kept typing vim instead of (nvim/neovim
| whichever the program executable name is), so I made an alias
| and tried that for awhile.
|
| I want to use/learn emacs too but never seem to have the time.
| xwdv wrote:
| I know _plenty_ of developers and engineers.
|
| But the _best_ engineers can only be about a handful,
| everyone cannot be the best. That 's not what the best means.
|
| It just so happens that of those best, which by the time you
| get to my age might only be about 3 or 4, they all seem to
| use neovim.
| rektide wrote:
| > The best developers and engineers I've known all used Neovim.
| Coincidence?
|
| Generally I rather advise we not do this!! This is a baiting
| question & one built around superficial narrow-dimensional
| assessments of "best". But sure, Friday, I've got summer hours:
| why not write a little homage to what I think is compelling &
| makes vim such a life-long joy to ongoingly immerse myself
| into, let's talk some about why I think vim makes some users
| feel unmatchedly free in a way they would never put down:
|
| Vim's origins as the most user-hostile text-editor known to man
| (ed) is an interesting origin story. Ed excelled at automation,
| at writing little scripts to modify programs, in a non-
| interactive fashion.
|
| This excellence as an automated text editing system stems, in
| my view, from Ed/Vim's notion of Text Objects, ed/vim's way of
| telling the editor about where you want to go/what you want to
| select in a file. The editor as a bunch of buffers (opened
| files), named registers (which is basically a 1-dimensional
| (many points) rather than 0-dimensional (point) clipboards),
| text-objects that can select spots in buffers ("lines 4-7",
| "the first two characters of this line"), and commands that can
| be run on text-objects is an incredibly powerful set of general
| purpose abstractions for doing any variety of text processing
| task, and there's a nice break down of responsibilities for
| what does what in this system.
|
| The shake out is cool. Macros in this system are nothing but a
| stream of commands dropped into a register, with the ability to
| replay that stream: it basically didn't require adding anything
| to the existing system to get macros in vim, because vim was
| already text-driven enough by it's nature.
|
| Text-objects[1] deserve some special mention as a standout
| component of this system. They are an incredible leap, giving
| us huge expressivity when we want to cite or reference some
| part of the screen.
|
| I've always called vim "spellcasting on the fly", as in the
| ability to combine a bunch of ad-hoc text-objects & commands ,
| but the irony is that it's origin, ed, while yes sometimes used
| for interactive editing, was quickly primarily used for
| automation, for rote processing. It's about building a
| sophisticated model of being able to reference a spot in a
| document, possibly as the document changes around you over
| time, & doing certain things. The rote-based/automated use of
| ed is so core to vim's magic: the power of text-objects to cite
| specific things on the page, in a endless variety of ways, and
| then to issue modifications & updates to these powerful text-
| object's you've named is a wonderful combination of powers, for
| both rote/automated processing, and on-the-fly/interactive
| processing.
|
| Vim is far & away the most interesting model of text-editing
| there is. There are countless editors out there, with wonderful
| features, and great integration, but by george you just cannot
| beat (rather, we have not beat) the power of having a
| sophisticated powerful expressive model for what text is, and
| how to get to parts in the text, that vim brings. If you want a
| way to edit text that let's your brain be free to express how
| to move through & talk about text, that has powerful scripting
| to let you build & extend your palette of commands, (neo)vim is
| unmatched.
|
| Epistemic status: 0.2, unresearched, probably a lot of
| disambiguation/clarifying needed, some liberties taken with the
| timeline of when exactly what happened.
|
| [1] https://blog.carbonfive.com/vim-text-objects-the-
| definitive-...
| edgyquant wrote:
| The best engineers I know use a range of editors. A text editor
| has nothing to do with your engineering ability.
| elteto wrote:
| Yes.
| kdheepak wrote:
| I'm excited for this release! Built in nvim-lsp, treesitter
| support, better support for accessing vim internals from lua are
| all awesome additions. I've been using the nightly releases for a
| while and it has been great! I'm looking forward to seeing the
| larger community now have access to the stable release!
|
| For people that are interested in knowing more, neovim is having
| a release stream on teej's twitch channel: twitch.tv/teej_dv.
| rektide wrote:
| I've seen a number of announcements but this is the first 'I'm
| excited!' post I've seen that includes any information about
| what is being added.
|
| Strike that, not entirely true: there was one good post 37 days
| ago, "Neovim is overpowering", that I liked a lot[1].
|
| [1] https://crispgm.com/page/neovim-is-overpowering.html
| https://news.ycombinator.com/item?id=27291302
| fermentation wrote:
| What do folks these days use with vim-lsp to get an IDE-like
| experience? I'm wondering if it would be better than a coc/ccls
| setup.
| mauricedenassau wrote:
| I think the fact that it's built-in should not be overlooked.
| lc9er wrote:
| Apart from some node issues early on, CoC has worked well for
| me. At some point I'll try the native lsp, but it seems like
| a lot of setup, just to get back to where I already am.
| qbasic_forever wrote:
| I went back to coc from nvim's native lsp. I think the nvim
| lsp world needs another year to stabilize and mature. The
| default lsp configs are pretty rudimentary and make big
| assumptions like every project root is a git repo. You can't
| easily just have a project specific LSP configuration file
| like you can with coc. And installing each LSP is a real
| chore with various competing plugins instead of the easy
| built-in coc install commands.
| rektide wrote:
| Bundling in a bunch of plugins[1] feels semi-cheating for
| shipping a new release, but I'm ok with it. I do get a bit of a
| monolithization vibe, and it kind of scares me to think that
| neovim might get stuck with some ever-ossifying codebases it
| shouldn't have pulled in, but overall I think the gains of
| building a more rich, integrated, baseline editing environment
| probably justifies the damage of consolidation/picking one.
|
| Weird comparison to draw, but like systemd comes to mind. I love
| systemd so much. It's many different utilities all have a pretty
| consistent way to be operated & they're all optional &
| independent, so it's really more of a mono-repo. My warning
| hazards have never gone off on systemd: the init system is
| radically better, building a suite of tools using the same design
| system makes it so much of a joy; there's consistent powerful
| strategies I can deploy when working with any of the systemd
| monorepo daemons.
|
| By compare neovim intuitively feels a little more integrative to
| me, more monolithic rather than being so strongly mono-repo'ish.
| Neovim scripts will emerge hooking into, extending, embracing
| these new integrated plugins, the community will continue to
| interweave themselves with these features. Trying to change
| things latter will be harder than it would be with systemd,
| there's more of a Big Ball Of Mud[2] fear here for me. My concern
| is probably about ~0.2 on the unit scale, and my ok'ness is
| probably ~0.6, some in between neutrality, so I'm not trying to
| say this is bad oh no. But I think there's some value to the
| comparison.
|
| Anyhow. Language Server Protocol is the shit. It's the primary
| channel for how we turn text-editors into Integrated Development
| Environments. Taking nvmim-lsp & integrating it is a huge step
| for this project.
|
| There's also some new hooks for Lua to work with, which promises
| ever better scripting: that seems like the one core enhancement
| to Neovim proper in 0.5.0.
|
| [1] https://crispgm.com/page/neovim-is-overpowering.html
| https://news.ycombinator.com/item?id=27291302
|
| [2] http://www.laputan.org/mud/
| imbnwa wrote:
| This isn't that big of a deal. vim is installed by default on
| all mainstream unix systems if not installable on any system of
| your choice. Neovim _should_ be a more comprehensive vim.
|
| vim is bash. nvim is zsh if not fish.
|
| Or maybe vim is RHEL, and nvim is Fedora
| _benj wrote:
| For those out there trying to "learn" vim, give neovim 0.5 a try!
|
| I've been using neovim HEAD (0.5 pre-release) for a while and it
| has been awesome. It all started with this config [0] and from
| there and haven't tried (as before) to join a vim cult but
| instead to use it as a tool that works for me (i.e. use mouse
| scroll to browse around, use arrows on insert mode, and other vim
| sins)
|
| Little by little I've been looking at how I could do something a
| little better and pretty much every time vim has an awesome way
| for me to do something! Yanked some text then deleted something
| but I want to paste the yanked text, not the deleted one? "0p is
| the answer. Need to replace all ___ but not modify the prefixed
| numbers? I can use visual regex to easily work that out! I'm
| doing something over and over? I can make that into a macro!
| There's a macro that I always use on certain file types? I can
| make an autocmd to load some string to some macro when I open
| certain file.
|
| It'a awesome feeling that time I've actually learning about
| registers, macros, regex, windows, buffers, and everything else
| in a modern and snappy tool!
|
| [0] https://github.com/mjlbach/defaults.nvim
| maddyboo wrote:
| Wow, I've been a vim user for like 8+ years and didn't know
| about 0p even though I run into that problem all the time. I
| had even re-bound yank/paste to use a different register.
| Thanks for the pointer!
|
| This is what I love about vim, there's always something new to
| learn.
| linsomniac wrote:
| LunarVim has a "show buffers registers" plugin enabled so
| when you type " it brings up a window showing the contents of
| various buffers, so you can eyeball it rather than
| remembering.
| leephillips wrote:
| I guess you mean registers. You can see a list of them in
| default Vim using the command :reg.
| maddyboo wrote:
| Oh, just realized I misread the original comment. I ignored
| the ", so I thought they were saying you could just use 0p
| (on my phone, otherwise would've tested it in vim).
|
| I use registers often but I admit I haven't memorized the
| meaning of the auto-populated ones like 0.
| wolverine876 wrote:
| To clarify for people unfamiliar, all of that is common to Vim
| and Neovim except maybe visual regex - what is that?
| _benj wrote:
| Tbh, that's how I call it but it's just having incremental
| search enabled. That will highlight search/replace matches
| and the using s/<thing to search for>/<thing to replace it
| with>
|
| That allows me to see what my regex matches. So I can start
| typing ^d*\\. Hello and that would match any start of line
| digit followed by a dot and the word hello.
|
| I still have a lot to learn there but just that has been
| incredibly useful for me.
|
| Hope that makes sense
| wolverine876 wrote:
| Yes, thanks. That's not what I thought you meant, but it
| suggests a great idea: Something that gives visual feedback
| as you construct regexes. I'm not sure that incremental
| search isn't sufficient, however.
| sagarm wrote:
| That's exactly what NeoVIM supports: you get a live
| preview of searches and replaces. The behavior can be
| enabled with ":set inccommand=split" (preview in a
| separate window) or ":set inccommand=nosplit" (inline
| preview).
| rkuester wrote:
| Release party in progress at https://www.twitch.tv/teej_dv .
| mempko wrote:
| First thing I see is a prime video ad. Amazon is helping fund
| neovim.
| jdauriemma wrote:
| Are you sure it's not just the fact that Twitch is owned by
| Amazon?
| mempko wrote:
| I guess I don't use Twitch. Can they turn off the
| monetization? Did they turn it on?
| animal_spirits wrote:
| Why would they turn it off? They should make money for
| the work they've done.
| clircle wrote:
| NeoVim is very tempting to me. I've been tweaking my Emacs config
| for 5 years, and I'm very happy with it, but only on my Ubuntu
| computers. On Windows, Emacs runs like garbage (slow, no double-
| buffering). I might have to switch to NeoVim, at least on
| Windows.
| hemanta212 wrote:
| curious to know what you think about WSL2? I've been using
| emacs and ubuntu with pretty great sucess
| ajross wrote:
| I just run X11 emacs with the Cygwin X server, it works pretty
| well. I don't actually edit anything in the windows filesystem
| proper, though.
| modernerd wrote:
| The Emacs experience on Windows could be faster, but having
| switched from Neovim to Emacs on macOS I do not want to go back
| to Neovim now (and I was running the Neovim 0.5/dev branch with
| LSP and treesitter integration for some time). Your time might
| be better spent on improving Emacs performance on Windows if
| you can. I haven't used Emacs on Windows for a little while,
| but I wonder if running it via WSL2 with the new Linux GUI
| integration is better than the native Windows experience?
|
| I spent months trying to mould Neovim into an IDE-style
| environment I could love (people seem split about whether
| Neovim should be an IDE or not, but it feels like it's evolving
| in that direction).
|
| I tried Doom Emacs because of the buzz around it, fell in love
| straight away, and built my own Emacs config from scratch to
| get a better understanding of Emacs (I like Doom, but I found
| it hard as a new Emacs user to grok the separation between
| Emacs/Doom/external packages; the appeal of Emacs for me is to
| shape the tool to your needs and to understand what the
| packages you're using do and how to tweak and customise
| things).
|
| Neovim is improving but it still falls short of Emacs by far in
| my opinion. Some things to be aware of from my experience of
| both environments:
|
| Neovim UI is inconsistent. With Emacs I can have every package
| use Ivy for item filtering and selection, for example, where as
| Neovim plugins often end up inventing their own UI because
| there's no real UI standard in the Neovim space. Even Neovim
| packages that build good UIs (telescope) feel buggy and laggy
| to me compared to Emacs equivalents. (I had a persistent issue
| with telescope where trying to close the popover would take
| multiple attempts or not work at all).
|
| Package quality is _so_ much better for Emacs. I tried a bunch
| of different Vim/Neovim git plugins and none of them are close
| to magit. When I ask Neovim users what they recommend for git
| integration, they suggest plugins that don't hold a candle to
| magit (fugitive), external CLI tools that aren't integrated
| with Neovim (lazygit), or say something like, "just use git on
| the CLI via tmux or iTerm tabs! Vim isn't supposed to be an IDE
| on its own - you compose Linux tools in isolation into an IDE".
| That's fine if you embrace that mindset, but I find it
| unsatisfying now that I've used magit for some time. It's a
| similar story for pretty much every IDE problem space
| (projectile and Cider are so much better than their Vim
| equivalents, for example).
|
| Documentation quality is generally much better with Emacs,
| particularly when writing plugins. (Lua APIs are documented for
| Neovim but not to the extent that Elisp functions are.)
|
| Emacs Lisp is also so much nicer to work with than Vimscript
| and Lua. The ability to run expressions in the environment
| without reloading whole files or restarting is a superpower,
| especially when making plugins.
|
| I don't mean to crash the Neovim 0.5 launch party here - by all
| means try it! Just be prepared to trade some of your Windows
| speed-related frustrations for general UX/UI/polish pain points
| instead. :-)
| ibraheemdev wrote:
| If anyone is interested in migrating their config to lua, or
| doing some basic scripting, there's an excellent and pretty
| comprehensive guide here: https://github.com/nanotee/nvim-lua-
| guide
| mr_o47 wrote:
| Once you learn vim you'll never settle on regular text editor
|
| The amount of things you can with just few keys is just
| phenomenal.
|
| It does have a learning but once that's achieved you'll be very
| much productive and get things done very quickly
| ibraheemdev wrote:
| One little-talked about advantage of Lua support is that you can
| now write your vim config/scripts in one of the various Lua
| transpilers like moonscript [0], or maybe even typescript [1]!
|
| [0]: https://github.com/leafo/moonscript
|
| [1]: https://github.com/TypeScriptToLua/TypeScriptToLua
|
| [2]: https://github.com/hengestone/lua-languages
| celeritascelery wrote:
| I am curious if there are any major packages written in lua for
| neovim? I wonder if ecosystem fragmentation will become an
| issue (vimscript vs Lua).
| ibraheemdev wrote:
| There are replacements for most/many popular packages (that I
| use at least). Many people do prefer lua packages over
| vimscript ones.
| mauricedenassau wrote:
| Been waiting for this release for a long time. Kudos to the team,
| very excited. Especially built-in LSP.
| davidkunz wrote:
| I love Neovim. I switched from VSCode and never looked back, it's
| just so much more efficient to just do everything with your
| keyboard. In case someone is interested how to do the things
| you're used to from VSCode, I created some videos:
| https://youtube.com/playlist?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
| efficax wrote:
| Funny, I switched from neovim to VSCode + the vim plugin. Sure,
| it doesn't have everything I would do with vim supported, but
| it's enough and overall it's a better experience
| Jenk wrote:
| I've started using the vscode neovim plugin. It runs a
| headless neovim in the background so you get literally
| everything that both editors provide in one. It's not 100%
| flawless but it is damn good.
|
| I used to flip between the two anyway - if I needed a better
| intellisense for, say, a large typescript project, then
| vscode won, everything else was nvim. Now I have the
| intellisense of vscode ontop of neovim.
| ibraheemdev wrote:
| For anyone wondering:
| https://github.com/asvetliakov/vscode-neovim
| thayne wrote:
| I tried switching to VSCode with the vim plugin. but I got
| frustrated with vim keys that didn't quite work right on
| VSCode. And iirc configuring custom vim-style bindings was
| quite a pain. And then there were the neovim/vim plugins that
| I used that didn't have good equivalents in VSCode,
| especially that worked well with the vim plugin.
|
| Also VSCode is much, much more resource hungry.
| CalChris wrote:
| You were probably using the more popular vscodevim with its
| 2.7M installs. Try vscode-neovim with its merely 93K
| installs.
|
| vscode-neovim is designed for and _requires_ neovim 0.5. I
| hate, hate, hated vscodevim but vscode-neovim is very good,
| very usable; I stopped using VSC altogether until vscode-
| neovim got real. It 's not perfect, it still needs work on
| command mode, but it's quite usable. I even got rid of my
| other vims (MacVim, VimR, ...).
| systems wrote:
| I am not sure how this is possible
|
| Editors like Vim, Emacs or VSCode are all about the plugins
|
| I use emacs for org mode And VSCode for everything else,
| because simply most proramming languages have their main
| plugins on VSCode
|
| The only way you can move from VSCode to neovim is, if you dont
| care about the plugins
|
| Why would you VSCode if not for the plugins
| junon wrote:
| Neovim has plugins...
| systems wrote:
| I am not sure I fully grasp this yet
|
| but comments above are suggesting that because of LSP
| (Language server protocols) plugins can be portable now,
| from one editor to another
|
| i thought each editor needed its own plugin, and VS Code
| always seem to have the main plugin, didnt really come
| across plugins that run across multiple editor, but then i
| was not really checking this, next time i will check it
| davidkunz wrote:
| Regarding programming languages, the answer is the language
| server protocol (LSP), an editor-agnostic way to use IDE-like
| features, originally developed for VSCode. Works for both
| Neovim and VSCode (and many others). Somewhat ironic that one
| of VSCode's best inventions is the one which made me switch
| away from it.
| qudat wrote:
| I just switched from 0.4 to 0.5 specifically for LSP and
| treesitter support. There is zero difference between it and
| vscode for me now. Neovim 0.5 is a game changer and closes
| the gap between it and vscode.
| shiryel wrote:
| Well, mostly of the language specific plugins are language
| server protocols (LSP), you only need a client to make they
| work on any editor, I used to use CoC on vim to have that
| power, but now with the new version of NeoVim the client is
| build-in, so...
| CameronNemo wrote:
| _now with the new version of NeoVim the client is built-in_
|
| Can you link me to how to configure that? I have been using
| LanguageClient-neovim, which is a Rust plugin.
| davidkunz wrote:
| I talked about the configuration in my videos (linked
| above).
|
| The best place to start is here:
| https://github.com/neovim/nvim-lspconfig
|
| I use it in combination with nvim-compe:
| https://github.com/hrsh7th/nvim-compe
| flatiron wrote:
| I don't use any plugins with vs code. Am I the baddie? At
| least for JavaScript node crap it works perfect out of the
| box.
| mraza007 wrote:
| Thank you for making these !!!
| davidkunz wrote:
| Glad you like them!
| alexmcc81 wrote:
| Neovim is great. I've moved from a very large custom vim setup to
| a slightly modified LunarVim [1] config (requires Neovim 0.5+),
| which takes full advantage of tree-sitter and LSP. Loving it so
| far.
|
| [1] https://github.com/ChristianChiarulli/LunarVim
| linsomniac wrote:
| I'm interested in what modifications you have made. I've been
| trying LunarVim a bit for the last week and am on the fence
| about going back to SpaceVim or just bare neovim. Not sure,
| still evaluating...
| mmgutz wrote:
| I want to like LunarVim but the everything-lua is a bit
| overboard. Compare this
|
| ` vim.api.nvim_set_keymap('n', '<S-TAB>', ':bprevious<CR>',
| {noremap = true, silent = true})`
|
| to
|
| `nnoremap <silent> <S-TAB> :bprevious<CR>`
|
| Why convert every single line of vimscript to a noisier lua
| statement?
|
| The Packer manager seems a step back from vim-plug. Your
| configuration file is no longer the source of truth. Packer
| uses a global site directory for plugin as opposed to a local
| directory like vim-plug. Guess what? Neovim also uses that
| directory. It's like the old days of plugins of installing
| everything globally. I had to do this after making a
| configuration change: :PackerSync, exit neovim, delete cache
| file, restart neovim, :PackerCompile. Believe me, forgetting
| a step has been an endless source of frustration.
| adkadskhj wrote:
| I really hope for one day to have Kakoune-like selection-first
| and multi-cursor functionality in Neovim. After moving to Kakoune
| i just can't go back to Vim, but Neovim's advancements make me
| jealous.
|
| Congrats on 0.5, another release that looks great!
| soupshield wrote:
| My heart is with vim but I switched to emacs as I love orgmode
| too much for note taking. I tried a few vim orgmode plugins but
| they seemed quite flakey even though I only really use orgmode
| for outlining. Excuse my ignorance but could all this LSP/Lua
| stuff allow neovim to take over from emacs?
| _benj wrote:
| I'd say cautiously maybe. Using lua to me seems like it could
| open doors for neovim that before we're either not possible or
| very complicated to do with vimscript.
|
| Neovim doesn't have such incredible and almost ridiculous power
| to change itself like emacs does with elisp since vim is still
| not written in lua, lua is just used to access its api, but
| that api is quite extensive. So, maybe? Hopefully?
| nerdponx wrote:
| And if you really want Lisp in Neovim, you can use the
| Aniseed framework to write your plugins and scripts in
| Fennel.
| ssklash wrote:
| What is the value proposition for moving from vanilla vim to
| neovim? I see all the features on the neovim repo, but almost all
| of them seem aimed at developers rather than users. I've
| considered switching, but I'd have to move to a .nvimrc or
| something, update my install scripts and Ansible, etc., and I'm
| not sure what I'd gain from it other than "extensibility". If
| there are concrete benefits for normal usage, I'd be willing, but
| I'm not sure what those would be. Am I missing things?
| nerdponx wrote:
| I initially switched because it allowed me to simplify my
| configuration. This was even before Lua integration was a
| thing; it had better defaults, and the client/server
| architecture appealed to me. I also liked the idea of a re-
| factored, more-modular, possibly faster core application.
|
| Now what's starting to happen is that the plugin ecosystems are
| diverging. Subjectively, it seems like plugin developers are
| significantly more productive working in languages that are not
| Vimscript. Accordingly, Neovim seems to be accumulating more
| sophisticated IDE-like plugins, and this appeals to me on a
| personal level.
|
| Now that the remote plugin and Lua APIs (including Tree Sitter
| and LSP!) are somewhat stable, I expect this productivity and
| divergence to accelerate. I feel like Neovim will be
| approaching Emacs "power parity" in the next few years, and
| that's a very exciting prospect to me.
| _benj wrote:
| For me it was the lua config file.
|
| Now tweaking vim to the behavior I want is no longer learning
| an obscure language but figuring out what is the behavior I
| want and coding that using lua and the vim api. With the lua
| language server vim's api is very discoverable!
| ibraheemdev wrote:
| Lua is much nicer for scripting, yes, but support is not
| there _yet_. There are a couple missing APIs, and just some
| overall verbosity that is still being cleaned up and worked
| on last I checked.
| drbojingle wrote:
| with the .5 release, I would say the value prop is tree-sitter.
| Config can still be in vimscript. Very little would actually
| change there vs .vimrc.
| CalChris wrote:
| It's already in the homebrew distribution: brew
| update; brew upgrade ... ==> Upgrading neovim
| 0.4.4_2 -> 0.5.0 ...
| highpost wrote:
| There is a middle ground for VS Code users:
|
| https://github.com/asvetliakov/vscode-neovim
|
| This extension integrates neovim into the VS Code environment by
| mapping keystrokes from VS Code to the neovim binary. This
| approach (which requires 0.5) is much simpler and more robust
| than attempting to emulate all of VIM, as the VSCodeVIM extension
| does.
| qbasic_forever wrote:
| I've always scratched my head at this plugin. Is the idea that
| you have both a VS code configuration for all the stuff around
| the editor (themes, UI stuff, all kinds of fancy VS code
| features like its file tree, git tree, testing, etc.), and a
| neovim configuration for the editor component itself? How do
| language servers and such work--are all the slick one click VS
| code installed extensions ignored and you're back to twiddling
| and tweaking and googling neovim config to get LSP working?
| highpost wrote:
| I think you have it right: neovim for your fingers and VS
| Code for the larger programming environment with all its
| features. I don't know how LSP is integrated, but it seems to
| work.
|
| BTW, I ran into too many corner cases where VSCodeVIM's
| emulation broke down.
| CalChris wrote:
| vscode-neovim really depends on nvim 0.5 I was using a neovim
| 0.5 nightly before this was released. It's not perfect but
| it's a LOT better than VSCodeVim.
___________________________________________________________________
(page generated 2021-07-02 23:00 UTC)