[HN Gopher] Neovim 0.8 Released
___________________________________________________________________
Neovim 0.8 Released
Author : akrifari
Score : 254 points
Date : 2022-09-30 16:42 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| modernerd wrote:
| If you use Neovim, can you share why you chose it over VS Code,
| or one of the new terminal-based editors like https://helix-
| editor.com/, or new native GUI editors like https://zed.dev/ ?
|
| It's impressive to see what the Neovim community has built --
| preconfigured setups like https://nvchad.com/ are especially
| wild. But it still feels like a huge amount of work, hoop
| jumping, and _fragility_ just to reach parity with VS
| Code/Helix/Zed, which are pretty great out of the box, and which
| were built to be used as rich development environments instead of
| extensible text editors.
|
| I've spent months tweaking Neovim/Emacs configs in the past and I
| ultimately end up conceding that I'd rather spend that time
| hacking on projects instead of my editor config. I do feel the
| pull of these editors, though. I'd love to understand what those
| who stick with them are doing differently, other than perhaps
| being more susceptible to sunk cost fallacies. :-)
| vlunkr wrote:
| What exactly is fragile about vim/neovim? I'd argue that they
| are incredibly stable, being as old as they are.
|
| For another point I don't see being brought up, I love the
| .vimrc file. You can version control your entire editor config
| in one file. Other editors tend to spread config out across
| different files (one per plugin for example).
|
| I've had to spend time configuring every editor I've used, but
| all that time is tracked and documented in vim. I can have
| everything set up instantly.
| bilalq wrote:
| I kind of take the best of both worlds. VSCode has a lot of
| functionality that Neovim lacks, particularly on rendering
| previews of things like Markdown and Mermaid. Even outside of
| UI stuff, VSCode's extension ecosystem has so much deeper
| integration with things (beyond the level of just text/code
| editing, I mean). The VSCode JS Debug Terminal is literally
| life-changing. No more needing to mess around with debugger
| configs for runtimes. Literally just run the code and it works.
|
| Despite that, I still often feel limited by the vim binding
| plugin for VSCode. It's never a problem though, because Cmd+J
| toggles the terminal visibility, and I escape into Neovim there
| when I need it.
| jerpint wrote:
| I really like working inside a terminal, and I like being able
| to navigate seemlessly between code tabs and terminal tabs as
| though they are one. I can do this easily in vim+tmux, I can't
| do this easily in IDEs where the mouse is considered first-
| class. I do miss certain features of IDEs, but being able to
| toggle between shells, tabs and code is my killer feature.
| peppermint_tea wrote:
| I just switched to this setup now... Before, I was using kate
| (which is very nice) but I switched exactly for the reason
| you've mentioned. terminal and editor in the same place.
| jefftime wrote:
| I actually loved Helix, but moved from it to Neovim for
| performance and customizability reasons. Helix becomes unusable
| with multi thousand line files, but I imagine it's something
| that will eventually be solved as the project matures. The
| customizability of Neovim is incredible, and I'm looking
| forward to trying Helix again when it has a plugin solution
| 3836293648 wrote:
| Helix has segfaulted within minutes every time I've tried it.
| Despite being written in rust. It might be better now, but
| they've already lost me.
|
| I switched away from VSC because I grew frustrated with the
| constant lag and terrible loading times.
|
| The modern native stuff is either MacOS only or a proprietary
| newcomer, leaving me with no trust that I can stick with it
| long term.
|
| And I'm a Nix user, so neovim doesn't randomly break for me,
| all versions are pinned. And if stuff does break when I chose
| to update my pinned versions it's trivial to rollback.
| scelerat wrote:
| Kinda just like the modal editing of vim and the features and
| improvements upon it by neovim.
|
| These days I've been using the LunarVim suite of neovim
| enhancements and I like it quite a bit.
|
| https://www.lunarvim.org/
|
| 95% of my coding workflow takes place in the terminal (along
| with tmux and iTerm2) and neovim fits very nicely there.
| benreesman wrote:
| vi (and in different ways, emacs) were designed for optimal
| editing productivity on low-bandwidth connections and low
| horsepower machines.
|
| This created an imperative around efficiency per keystroke
| that, somewhat shockingly, remains the most thorough and
| successful mainstream attempt to get the most from every
| keystroke.
|
| With modern technology and decades more experience it seems
| inevitable that someone could do better today (though even with
| those benefits not everyone is Bill Joy), but I'm not aware of
| anyone who has successfully attempted to beat vi/emacs for the
| "will learn arbitrarily hard tools to be fast" crowd, which
| necessarily counts the "my RSI is so bad I need my money's
| worth out of every key press" crowd, and several other big
| blocks of badass hackers.
|
| People still use these tools because they still have the
| highest ceilings on the effort/power scalability curve. That
| doesn't make them right for everyone, but it makes them right
| for a lot of people.
| fishywang wrote:
| vim, or at least vi, is something you can pretty much expect to
| be existing on any system you ssh into. If you are comfortable
| with vim, you have the editor part sorted no matter what system
| you are dropped into to debug/whatever.
| OkayPhysicist wrote:
| For a perspective that hasn't been shared all ready, I like
| modal editing because I A) don't like to use the mouse any more
| than I have to and B) have awful memory when it comes to
| complicated chords of keyboard shortcuts. Except for the bare
| basics (switching modes, jumping to the start and end of lines,
| etc), I heavily rely on much easier to remember names of
| commands to interact with my editor. Like toggling line
| numbering: I'm sure there's some ctrl-alt-F4 esque chord to do
| it in VS Code, but that'll be much harder for me to remember
| than :set number.
|
| For similar reasons, I prefer the command line to GUI-based
| applications, that all seem to be built around either a love of
| clicking through a long series of cascading menus, or
| memorizing obtuse shortcuts. TUI applications like Vim
| integrate much more readily with my other command line tools,
| so it creates a much more seamless workflow.
| esclerofilo wrote:
| > but that'll be much harder for me to remember than :set
| number
|
| You could also do Ctrl+P on VSCode (or Ctrl+Shift+A on a
| Jetbrains IDE) and search for "line number". Command based
| interfaces are no longer unique to CLI tools.
| rockwotj wrote:
| I enjoy a terminal workflow, and helix doesn't actually have
| vim key bindings and many years of vim use is hard to switch.
|
| EDIT: I'm also a tmux user and I can't live without a
| replacement for this plugin:
| https://github.com/christoomey/vim-tmux-navigator
| norman784 wrote:
| Check wezterm, it has something similar to tmux splits and
| it's nice.
| alwillis wrote:
| +1. WezTerm is incredibly well done.
| rockwotj wrote:
| Will do! Currently using alacritty and enjoying that
| ar_lan wrote:
| Kitty also has this feature built in!
| celrod wrote:
| I use emacs. I have little desire to customize configs and
| spend hardly any time on it. Checking now, I haven't modified
| it since June, which means I haven't even installed any new
| packages (the equivalent of VSCode extensions) since then
| either.
|
| Maybe I should spend more time on it, but my settings work for
| me and I can't really be bothered/find coding projects much
| more alluring than editing a config.
|
| Why emacs, then? Mostly that I like the keybindings more than
| anything else. Emacs extensions in vs code are a poor imitation
| at best. I'm not really into modal editing either. Maybe I'd
| just have to spend the time to learn that, but I'm quite
| productive with emacs, so I don't see the incentive. I have
| keyboards with thumb clusters, so it's comfortable and quick to
| press key combinations in parallel. Switching between modes and
| executing key presses is inherently serial in comparison. I
| assume with practice I could get very quick at that as well --
| after all, typing is also serial, but can still be fast. I just
| don't see any value proposition to switching.
| yjftsjthsd-h wrote:
| > If you use Neovim, can you share why you chose it over VS
| Code, or one of the new terminal-based editors like
| https://helix-editor.com/, or new native GUI editors like
| https://zed.dev/ ?
|
| VS Code is a proprietary, spyware-riddled, resource-wasting
| worked example of why "modern" software sucks. Also for my
| personal use, everything that's not vim suffers from being not
| vim; it would cost me effort to switch for no clear benefit,
| and I'd still need to retrofit the same control scheme into
| whatever it was because the muscle memory is too strong, at
| which point I might as well just use actual neo/vim.
|
| > which were built to be used as rich development environments
| instead of extensible text editors
|
| > spent months tweaking Neovim/Emacs configs
|
| I think part of the difference might be of usecase; if you want
| an IDE, use an IDE. If you needed to spend that much time
| bending the tool to what you want, maybe it wasn't a good tool
| to use. When I open vim, it's because I want a text editor, and
| it provides a text editor.
| johnfn wrote:
| > VS Code is a proprietary, spyware-riddled, resource-wasting
| worked example of why "modern" software sucks.
|
| Perspectives like these (and others in the thread) remind me
| that there exists a separate cohort of engineers from people
| like myself which have absolutely polar opposite views. I
| respect your opinions, though I couldn't disagree more with
| them! :)
|
| Well, except the bit about VSCode having "spyware". That's
| not true, and it weakens your point. It _does_ have telemetry
| - I suspect that 's what you mean, and you should just call
| it that instead.
| sophacles wrote:
| Ah telemetry - you mean software that sends back
| information about what I'm doing to some 3rd party? Unlike
| spyware which is software that sends back information about
| what I'm doing to some third party.
|
| Totally different, got it.
| johnfn wrote:
| I said this to someone else, but spyware is defined
| (Google) as "a form of malware that hides on your device,
| monitors your activity, and steals sensitive information
| like bank details and passwords." Please furnish any
| example of Microsoft stealing sensitive information like
| bank details and passwords via VSCode.
| sophacles wrote:
| I don't want MS to monitor me. Anything that enables them
| to track me better is sensitive because I don't want to
| be monitored.
| modernerd wrote:
| > and you should just call it that instead.
|
| And then turn it off using the built-in setting:
|
| https://code.visualstudio.com/docs/getstarted/telemetry#_di
| s...
| aeze wrote:
| You could also, if you wish, audit the telemetry events
| and determine if it's worth turning off - or decide that
| it's okay with you that they're using that data to
| improve their free product.
|
| https://code.visualstudio.com/docs/getstarted/telemetry#_
| vie...
|
| https://code.visualstudio.com/docs/getstarted/telemetry#_
| gdp...
| yjftsjthsd-h wrote:
| I could also just decide that it's okay to use a free
| editor that doesn't report on me in the first place. I
| don't need to audit exactly what information vim sends
| off and evaluate whether it's too much, because "none" is
| really easy to decide on.
| MichaelCollins wrote:
| Searching for excuses to let the company's product spy on
| you sounds like a huge waste of time.
| yjftsjthsd-h wrote:
| - https://www.roboleary.net/tools/2022/04/20/vscode-
| telemetry.html - "It looks like you cannot shut
| telemetry off 100%. These settings will opt
| you of most data sharing scenarios; but not all data
| sharing scenarios." - Apparently
| even VSCodium can't kill it all - https://gi
| thub.com/VSCodium/vscodium/blob/master/DOCS.md#disable-
| telemetry
| jrm4 wrote:
| No. Microsoft's general reputation for spying on its users
| renders "spyware" a reasonable shorthand for what it either
| does now, or perhaps is reasonably likely to do at some
| time in the future.
|
| I would fall back to the softer "telemetry" ONLY IF they
| were to provide some sort of genuinely reliable affirmation
| that it's not spying, which I don't think they could do
| today absent legal or other generally obvious incentive.
| johnfn wrote:
| I mean, you can say whatever you want - you only diminish
| your own argument by doing so. It's like the boy who
| cried wolf - if you keep shouting "spyware" with no true
| evidence of spyware, then by the time that "spyware"
| actually _is_ happening, no one is going to care.
|
| > what it either does now
|
| Spyware is defined (Google) as "a form of malware that
| hides on your device, monitors your activity, and steals
| sensitive information like bank details and passwords."
| Please furnish any example of Microsoft stealing
| sensitive information like bank details and passwords via
| VSCode.
|
| > perhaps is reasonably likely to do at some time in the
| future
|
| An imagined hypothetical does not help your argument.
| jsf01 wrote:
| Even the FTC struggles to define spyware. But I think
| you're right that a disagreement on the definition is at
| the heart of all of this. I wouldn't be so overconfident
| in asserting that spyware is defined in your particular
| way here, though. There isn't exactly a consensus! VSCode
| is certainly not to be lumped in with password stealing
| keyloggers, but because they continue collecting
| telemetry data even after you explicitly disable it,
| VSCode does fall under the "collecting data without a
| user's knowledge" category of spyware.
| seti0Cha wrote:
| I have a tangental concern, which is that all things
| microsoft these days seem to be evolving towards an
| advertising platform or a subscription. The way they keep
| adding integrations into their other stuff is
| understandable, and doubtless convenient for many people,
| but I can't help but think that someday after they are
| deeply embedded in the workflows of large swaths of the
| development community a message will appear in your
| editor suggesting an upgrade to the pro version of some
| tool or plugin and the freemium experience will have
| arrived.
| yjftsjthsd-h wrote:
| > Spyware is defined (Google) as "a form of malware that
| hides on your device, monitors your activity, and steals
| sensitive information like bank details and passwords."
| Please furnish any example of Microsoft stealing
| sensitive information like bank details and passwords via
| VSCode.
|
| Well, yes, of course Google would say that. If you ask
| DuckDuckGo to define spyware, it offers these:
|
| > Software that secretly gathers information about a
| person or organization.
|
| > programs that surreptitiously monitor and report the
| actions of a computer user.
|
| Which of course is exactly what VSC does.
| [deleted]
| kweingar wrote:
| Lots of big tech companies (including mine) let their
| devs run VSCode on company machines. If there was a
| concern about spyware, I feel like all of those security
| teams across the industry wouldn't have signed off on
| this, especially with billions of dollars of IP at stake.
| sophacles wrote:
| Like log4j!
| kweingar wrote:
| I think there's a bit of a difference between a bug that
| went undiscovered for years and vetting third-party
| software to see if its telemetry compromises your
| employees or IP.
|
| I mean, sure, if you want to avoid log4j from happening,
| you can write all of your software from the ground up in-
| house with no third party dependencies (or audit every
| line of code for every third-party program you do use),
| but I don't see how that's relevant to a discussion about
| whether VSCode is compromised to a degree that other
| editors aren't.
| sophacles wrote:
| The point was that people thought "Oh surely log4j was
| vetted by the big companies that depend on it - I mean it
| must be OK if AcmeCorp uses it!". (or openssl, or
| sendmail, or ...). That's not too different from "Oh look
| at all these big tech companies using it, they must have
| vetted the telemetry".
|
| Maybe a little extra caution is warranted.
| peppermint_tea wrote:
| on linux, kde/kate is pretty good... I switched back to full
| tmux+vim lately to get even better with vim, but I find that
| kate is the perfect mix between an ide and a terminal based
| editor. makes me think of notepad++ with a few extra goodies
| (files on the left, terminal below etc...)
| d3nj4l wrote:
| If VSCode "sucks", then isn't it weird that the vast majority
| of people seem to love and even prefer using software that
| "sucks", including GP?
| bee_rider wrote:
| Popularity is not a great metric of goodness, unless we
| want to come to terms with the fact that Limp Bizkit
| records are around 3x as good as VSCode (and that's despite
| the fact that they aren't even charging people for VSCode!)
| yjftsjthsd-h wrote:
| I'm not sure how you'd know that; since vim, emacs, and
| other more traditional options don't include telemetry we
| don't know how many people use what editors. In any event,
| Windows remains the most-used (desktop) OS, so I've long
| since acclimated to people living with the suckage.
| cercatrova wrote:
| I use VSCode since switching away from Neo/Vim because things
| just work. I don't have to install a bunch of plugins like I
| used to where I don't know what works and what doesn't work
| with each other. For example, for Rust, I go to VSCode
| extensions page, click install on rust-analyzer, and that's
| it. I don't have to set up an LSP, syntax highlighting, etc
| which are each their own plugin on Vim.
| justinpombrio wrote:
| That's funny, I just switched from VSC to NeoVim because
| things just work. The C++ LSP bindings for Vim were easier
| to set up, faster, and more reliable than my setup in VSC.
| Though I imagine these things vary greatly, since C++ and
| C++ tooling is enormously complex and varies from codebase
| to codebase.
| ii41 wrote:
| I just want to express why I sometimes prefer things that
| don't "just work". I love VSCode. I use (neo)vim just
| because I am used to them (started using them before VSCode
| was around).
|
| Firstly, not "just work" means there will be no features to
| suddenly appear and "help" me. When I start to use a new
| IDE I never know what inserting "{" does: Will a "}" also
| appear? Will it start a new line? Will it cause indentation
| to change? Will it insert a whole snippet? How do I just
| insert a "{"? An IDE usually comes with lots of "helper"
| features like this, and questions like these add up. The
| result is that I never know what happens when I press a key
| and get agitated when the result isn't what I expect. If I
| set up everything myself this doesn't happen. (neo)vim is
| pretty bad in this sense actually. The default
| formatoptions and filetype indent plugins are pretty
| annoying, and the "J" normal mode command has behaviors
| that surprise users and cannot be turned off (you can remap
| it for sure), but by the time I met VSCode I got familiar
| enough with them already... I recall VSCode's default was
| pretty clean. IDEs are absolutely the worst.
|
| Not "just work" also means that I know how to change
| something if it steps into my way, since I set up
| everything myself. If I have to edit a file with special
| formatting rules that I need to follow, I know where to
| change auto formatting rules. If I have to read some
| generated code or code from dependency libraries, I know
| where to turn off warnings from linting. Since rust-
| analyzer is set up by myself, if one day I find that its
| version or config is not compatible with this new project I
| am starting to work on, I know immediately how to change
| it. If my whole setting up effort is "clicking a button",
| it becomes harder for me to find where the change needs to
| be made. Such things are not just "if"s actually, but
| happen pretty often from my experience, often enough to
| make me think it's better to set up everything myself than
| to figure things out each time.
| rmolin88 wrote:
| Neovim is extensibility and versatility. If you want a rich
| development environment, you can put in the work, or use one of
| the many preconfigured environments, and turn neovim into that.
|
| If you want a bare ultra fast, terminal text editor, neovim is
| that out of the box.
|
| If your only after LSP, tree sitter, embedded terminal,
| neovim's got your back.
|
| Basically, neovim embodies the beauty of Linux. Use and pay
| only for what you want.
| _kblcuk_ wrote:
| I use Neovim exclusively for the past 4 years or so. Before
| that I used WebStorm + sometimes Vim for another 6 years or so.
| To this day I'm thankful to my colleague and mentor, who
| introduced me to the basics of Vim (you know, how to quit it
| and all that) saying "it get's pretty handy when you need to
| edit something on the server"; that was probably around 14
| years ago.
|
| WebStorm was great, it was really magical how it just knows how
| this or that code relates to another piece of code, navigating
| around was a bliss. Where is that variable defined? Jump to
| definition, and you're there. You want to know what's that
| function does, even if it's somewhere in third-party libraries?
| No problem, jump to definition. The fuzzy-finder for everything
| (literally. From file names to methods to editor's commands and
| variables) was also amazing.
|
| At some point though I got a bit annoyed with the fact that it
| took 5 seconds to start it up (multiply that by amount of
| different projects you need to open), and it's general resource
| hungry-ness. So I started experimenting with Neovim 0.3 (at the
| time), and pretty quickly managed to get near-webstorm
| experience with gutentags, fzf and amazing vim-fugitive for all
| the git things I did in the command line. And with resent
| native lsp & treesitter, it doesn't
|
| I tried VSCode once, which was a fiasco -- for some reason it
| failed jumping to definition in a basic react project with
| typescript. Oh well.
|
| Helix looks really cool, I'm playing around the idea of using
| it more, though I still will have to keep (Neo)vim around for
| vim-fugitive. Slightly concerned with how much muscle-memory
| re-training will needed though, then again it didn't took me
| too much to get to the same level of ease of use with Doom
| Emacs. Speaking of which, it worked flawlessly (and has even
| better git tool), but still was terribly slow at times, so in
| the end got too annoying to work with.
|
| So in the end it boils down to Neovim being fast, not getting
| in the way, and habit, I guess.
| Blackthorn wrote:
| The reason I still use emacs over helix or zed: elisp.
|
| Not because I particularly like the language. But because I
| like that I can write something in a language that executes and
| accesses pretty much anything the editor can do.
|
| Does helix or zed have the ability to do that? I didn't see it
| on their landing pages. What are the extensibility stories for
| these editors?
| modernerd wrote:
| Zed and Helix are both pretty new.
|
| There's demand for plugin frameworks/scriptability in both
| but neither of them support it yet. I fully understand why
| people who need to script their editor are sticking with
| [neo]vim/Emacs -- there are very few other options at the
| moment.
|
| https://github.com/zed-industries/feedback/issues/388
|
| https://github.com/helix-editor/helix/discussions/3806
| tomjakubowski wrote:
| Don't know about hex/zed but Lua in neovim is just about as
| pleasant to use as Elisp is with Emacs. It's not quite the
| same thing since neovim's still largely written in C, where
| Emacs is largely written in Elisp. But most of the editor's
| features (including text manipulation) are exposed to Lua.
|
| Lua is a nice language too, just lacking the stuff that makes
| the Lisp nerd in me happy.
| lc9er wrote:
| And you can use Fennel to hack Neovim, if you want to stick
| with a lispy language.
| ibotty wrote:
| Because it's vim but better. I don't want an editor that uses,
| maybe, eighty megs and is constantly swapping!
| massysett wrote:
| I was not familiar with Helix or Zed, so I took a look at the
| links.
|
| Both webpages prominently state that the editors are written in
| Rust. This reduces my interest in both projects.
|
| As a user, I do not care what language my editor is implemented
| in. Maybe I want a fast editor, or maybe I want a feature-rich
| editor. The closest I would come to caring about this is if I
| want an extensible editor - can I extend these editors using
| Rust?
|
| Lacking any explanation as to why I should care that the editor
| is written in Rust, the conclusion I draw is that the creators
| of the editor were interested in an exercise in writing an
| editor in Rust - which I'm sure is a wonderful learning
| experience for the creators, but I don't see why that would
| make me interested in using the editor.
| norman784 wrote:
| For me the thing is if is written in rust it has more chances
| to get more contributors, besides all the rust benefits
| (fast, performant as if it were written in C, but without the
| worries of the memory issues).
|
| Also just because I use rust, I could contribute, for C/C++
| editors I will not be able, maybe I'll also give a chance if
| the editor were written in Go, but no other language, all the
| others are slow.
|
| Also rust IMHO has a few apps (including commands) that are
| worth checking:
|
| - Helix - Alacritty - Wezterm - Nushell - Zoxide - Starship
|
| Then are others to replace grep, and other commands that I
| cannot remember from the top of my head.
| benreesman wrote:
| I don't get along very well with the HN Rust Community (and I
| think I'm even less popular with them than they are with me),
| but fair is fair and the Rust folks have been _absolutely
| revolutionizing_ the modern terminal experience.
|
| Put differently, I take the opposite view: seeing that a
| piece of terminal kit is written in Rust gives me a quite
| high Bayesian prior on the quality and usefulness of the
| tool. Something like 70% of the command-line nix packages in
| my home manager are written in Rust.
| dominotw wrote:
| > As a user, I do not care what language my editor is
| implemented in.
|
| Perhaps its a proxy for speed. You don't want your editor
| written in python.
| cercatrova wrote:
| > _This reduces my interest in both projects._
|
| That's funny, it's the opposite for me.
|
| > _As a user, I do not care what language my editor is
| implemented in._
|
| I do care. I don't like using Electron apps, even if I have
| to grudgingly use them a la VSCode. If an app is in Electron
| or some other slow framework like a Python GUI, my interest
| immediately drops to zero. If it's in Rust or some other low
| level language, at least I know it'll be fast.
| modernerd wrote:
| Don't let the "built|written in Rust" taglines put you off
| either project.
|
| Both are fast editors built by passionate teams offering
| compelling out-of-the box experiences. They're worth taking
| five minutes to download and try (or apply for the waitlist
| in the case of Zed).
| [deleted]
| Beltalowda wrote:
| I like "simple" editors: just text, completion when I ask for
| it (instead of popping up all the time), no distracting UI
| chrome, simple syntax highlights, etc. "Simple" is a bit of a
| misleading term, because even "stock Vim" (or Neovim) has a lot
| of IDE-like features. They just don't get in your way by
| default.
|
| I tried VSCode, and after several hours I still hadn't turned
| off all the features that I found undesirable.
|
| For me, personally, that nvchad thing seems horrendous. I don't
| know about Helix; maybe it's better, but I can't be arsed to
| check it out as I don't expect any productivity jump to be
| worth the effort.
| dadoomer wrote:
| I've found the extra complexity of IDEs unecessary and
| detrimental to my productivity. I like to keep it simple:
| neovim with LSP and fzf in a tmux session.
| Faaak wrote:
| I use VSCode, but I installed the vim plugin which makes it
| handle like vim for user inputs. Best of both worlds IMHO.
| malikNF wrote:
| In addition to programming, part of my job involves doing linux
| admin stuff, when I login to a server I expect vim to be there,
| and if not it takes a few seconds to install it.
|
| I usually try something on my local machine and switch to the
| server and do this back and forth and sometimes the other way
| around, I have a test server where I test something before
| trying it on my local machine. Having the same text editor on
| all of these environments mean I don't have to context switch
| much, also I have my own custom config which I have been
| improving over the years and the fact I have multiple vim
| instances running right now and they are all consuming less
| than 120MB memory and the fact it responds really really fast
| is a really nice addition.
|
| When I first started using vim I remember I asked one of my
| friends the following, "what the hell is wrong with people, why
| do they love using this god awful garbage" I remember my friend
| asking me to keep trying for a little while longer. Thank
| heavens I took his advice, I can't really remember when it
| happened but one day it just made sense.
|
| Then I saw a neovim config file, and how good it looked with
| lua scripting, changed my old vim config in to a neovim one,
| and now I use neovim.
|
| (plus I still have trust issues with a certain multi billion
| dollar company)
| qbasic_forever wrote:
| I don't need parity with VS code. If I want LSP and all kinds
| of distractions, binging and bonging, and crap jumping out and
| highlighting at me... I'll use VS code (don't get me wrong,
| sometimes those distractions are useful).
|
| Sometimes I need a terminal text editor. Something to quickly
| edit a config file, or perhaps even write something more
| substantial. Vim and Neovim are perfect and available on pretty
| much any machine which you'll have a terminal open to access.
| [deleted]
| dmix wrote:
| I was a Vim user for a decade+ and recently switched to VSCode
| 100% because the Typescript integration is unmatchable, no
| matter how hard you try in NeoVim (and I tried hard).
|
| If you're a front-end dev there's really nothing better. Also
| the https://www.tabnine.com/ integration feels like magic, it
| predicts the next block you're going to type with scary
| accuracy. I'm excited to see where AI IDE integration goes.
|
| But I still hate how VSCode is like a browser that will grind
| to a halt if you install (or misconfigure) too many extensions.
| jasonpeacock wrote:
| Because when I started using Vim, VSCode and Helix weren't
| around. And now I know Vim (Neovim) very well and it does
| everything I need - I'm productive with it and it's
| lightweight.
|
| I don't want a full IDE/graphical editor. Eclipse is a mess,
| I'd use a JetBrains product first, but now we have VSCode as an
| alternative. Atom was hot for a while but has lost popularity.
|
| Of the (linux) terminal text editors, the choices were mostly:
|
| * Emacs * Vim/Neovim * Nano
|
| And I prefer Vim over Emacs, I really like the modal
| experience.
|
| I don't spend a huge amount of time tweaking things, I use
| Neovim mostly stock with some useful plugins for convenient
| shortcuts. Though I admit that getting the new
| treesitter/language server integrations working was annoying,
| compared to the original regex-based syntax highlighting.
|
| My goal is _not_ to recreate an IDE experience in Neovim, I
| just want an efficient text editor that is syntax-aware.
|
| If I wanted an IDE then I'd use an actual IDE.
| goffi wrote:
| - I have used vim for many years (15 maybe?), and once you have
| passed the initial learning curve (not so terrible, after you
| keep learning cool stuff even after years of use), it's useful
| for everything with the same shortcuts. I would actually spend
| more time learning something else like an new IDE. At the end,
| I have probably saved a lot of time by sticking to (neo)vim
| instead of following the latest trend.
|
| - I like terminals because there is nearly nothing disturbing
| you, and it's usually quick to have something
|
| - there are many little features that looks like nothing but
| are really really useful when you use them. I'm a big fan of
| C-a / C-x to increment / decrement a number, coupled with
| https://github.com/nishigori/increment-activator it's super
| useful (to change a boolean, a date, a number, etc). The "." to
| repeat last command, the "*" to search what is under the cursor
| are other great features. An occasional macro made with "q" may
| save a lot of time when you need to do a repetitive task, for
| refactoring for instance, and you can even repeat them
| according to some patterns with ":g". I'm not sure if those
| features have handy equivalents on other IDEs.
|
| - I didn't spent that much time doing my config, just adding
| little changes here and there when necessary, over the years
| I've got a environment really adapted to my taste.
|
| - I'm currently doing mostly Python, and vanilla (neo)vim is
| normally good enough, but I'm using Coc
| (https://github.com/neoclide/coc.nvim) for a little while, and
| it add a lot of helping stuff easily. Pyright + snippets are
| useful.
|
| - when something cool happens somewhere else, you often have
| somebody adapting it to vim. I can use snippets and emmet which
| are occasionally very useful.
|
| At the end, I don't feel the need to change, it works well, and
| over the time I could add some neat features to improve it
| (snippets, emmet, CoC, tagbar, etc). I'm not sure if changing
| to something like VScodium would worth the time to learn
| something new (and I like working with terminals).
| threatofrain wrote:
| Helix is nice but Zed development speed appears to be a bit
| slow for my liking.
| bee_rider wrote:
| Yeah I don't see why one would try to reproduce the VSCode
| experience inside vim or whatever.
|
| Vim or neovim inside tmux are really nice, though. You can just
| use the normal general-purpose linux ecosystem rather than
| learning an IDE.
| reidrac wrote:
| I have been using vim since the late 90s, although the
| experience back then was much different. I don't think I really
| used plugins until around 2010 or so, and I was more into gvim
| until I moved to tmux + vim combo around 2016. So my nvim setup
| is not too fancy (sometimes I try plugins, if in two weeks I
| don't use them -or I don't even remember how they work-, I
| uninstall them).
|
| Moved to neovim because it felt _faster_ than vim 7.x and it
| was fresh and exciting (couldn 't believe the progress the
| project was making in a short period of time, compared with
| vim). Then I stayed because of the native LSP support and nvim-
| metals (among others).
|
| Things work, to the point that I'm not really _using the
| editor_ but _editing_ (if that makes sense). It is completely
| invisible to me. It is my editor.
| sophacles wrote:
| Similar story here. I often liken it to a musician with their
| instrument, or a master blacksmith with their hammer - at
| some point the tool stops being a separate entity and becomes
| an extension of the person wielding it. I think the ability
| to have this comes from the fact the fundamentals of the tool
| are stable across decades.
| weaksauce wrote:
| you can use neovim inside of vscode. it's pretty alright with
| only a few things that are rocky. I like it. got that modern
| gui affordances with the plugin ecosystem and lsp baked into it
| hard but also the normal/visual mode power.
| modernerd wrote:
| Thanks, I use VSCodeVim at the moment because even though
| it's not using "real vim" under the hood the performance has
| been more consistent for me.
|
| I revisit VSCode Neovim periodically but end up switching
| back after a day or so due to consistent freezing and cursor
| jitter (even with an empty nvim config and very few other VS
| Code extensions). I'll keep trying it out, though.
| agency wrote:
| I use VS Code for my day job because I can't be bothered to
| sink that much time into configuring my editor these days. But
| I recently setup NeoVim to play with Clojure since the most
| popular VS Code Clojure plugin (Calva) interacts poorly with
| vim keybindings. It was surprisingly easy to get setup (used
| the Conjure plugin) - NeoVim has come a long way in the years
| since I had last played with it.
| tiffanyh wrote:
| https://v2.onivim.io
|
| I was always bummed OniVim v2 didn't take off.
|
| It was a native IDE but fully supported VS Code plugin system.
| stoplying1 wrote:
| Helix is just very, very excellent. I've spent less than 5
| minutes total configuring it and I really have virtually not a
| single complaint and there's WIP for the niceties that aren't
| present yet (sidebar/treeview, etc).
|
| I installed it, had some LSPs already on path. I configured it
| to show LSP messages and that was about it. It's _very cool_
| how gosh darn productive I can be, in such a short time due to
| the command palette built in.
|
| Seems like folks are taking note too. There's a few intro
| videos on YouTube that do a good job posted in the last few
| weeks; apparently some big Vim-guy streamer checked it out last
| week. Active Matrix room and constant code improvements. And
| native nix flakes support too ;)
|
| Btw, I find it a bit weird to include VsCode and Helix here
| together. Helix is perfectly usable as a Vim replacement for
| all basic text editing tasks, and a superior zero-config
| alternative in countless other scenarios.
| modernerd wrote:
| I'm looking forward to a treeview too!
|
| https://github.com/helix-editor/helix/pull/2377
|
| And subsequent icon support:
|
| https://github.com/helix-editor/helix/pull/2869
|
| > I find it a bit weird to include VsCode and Helix here
| together.
|
| I work with people who declared config bankruptcy, switched
| from Emacs/Neovim to VS Code, and are perfectly happy and
| (maybe even more?) productive as a result.
|
| VSC is not in the same category as vim but it seems to appeal
| because it's a halfway house between vim/Helix and a heavier
| IDE. John Carmack even said something similar about VSC in
| his Lex Fridman interview:
|
| 01:11:31.060 And I am super happy that that seems to be
| winning
|
| 01:11:33.540 over even a lot of the old Vim and Emacs people
|
| 01:11:36.140 that they're kind of like,
|
| 01:11:37.140 hey, visual studio code's maybe not so bad.
|
| 01:11:40.060 I am, that may be the final peacekeeping
| solution
|
| 01:11:43.260 where everybody is reasonably happy
|
| 01:11:45.620 with something like that.
|
| https://karpathy.ai/lexicap/0309-large.html
| jofer wrote:
| I can't really agree that VS Code or Helix are "great out of
| the box". I haven't tried zed. VS Code feels really awful to me
| (note: this is probably just me) without weeks spent re-
| configuring it. Even then, it's _way_ too heavy for my laptop
| to run reliably. Maybe my brain just works differently, but I
| feel like VSCode fights against me at every turn. Helix is
| nifty, but also feels like it gets in my way more than it
| helps.
|
| I've never understood the advantage of "rich development
| environments". The refactoring tools and other fancy aids seem
| to never work. I wind up using regexes + manual intervention
| anyway. Also, I don't want to use git through a gui. Leave me
| be in the terminal where I have everything I need at my
| fingertips as fast as I can think.
|
| Syntax highlighting, linting, completion, and docs are all
| nice, but I have that in vim. I can run vim in the dev instance
| I'm ssh-ed into (which is 99.99% of how I work, anyway -- my
| work laptop is ancient and they won't replace it). I just can't
| see what those tools add, even for very large codebases.
|
| My configuration for vim began in the 90's. I've never put that
| much work into it at any one time, though it has grown quite
| complex over time. There are a bunch of plugins I use manged in
| the config file. 90% of the functionality I need works without
| those plugins, but even when I need to install them from
| scratch it's easy to go from "scp config file over" to "full
| setup" with one command.
|
| So in summary, I use vim because it's part of a larger set of
| standard unix-y tools that are heavily ingrained into muscle
| memory. The biggest advantage of vim in many ways is that it's
| a relatively rich environment (e.g. linting, syntax
| highlighting, doc hints, etc) that I can ctrl-Z to immediately
| be back in the terminal with. Other than that, it gets out of
| my way, and I don't think about the editor at all, I think
| about what I'm doing (decades of muscle memory helps a lot,
| though -- I'm incapable of not using vim keybindings to edit
| code, I think).
|
| I should move over to neovim, but mostly haven't yet. That's
| more due to a couple of weird plugins than anything else,
| though.
| denvaar wrote:
| Average joe-schmoe Neovim user here. My goal is not to emulate
| VS Code and other similar software. I enjoy Neovim for
| programming mainly because...
|
| - First and foremost, I love the text editing features Vim has
| (eg. the movements, modes, keys etc). It just feels great on my
| hands.
|
| - It's minimal. Well, you are free to make it as minimal or as
| bloated as you would like to ;)
|
| - For me, it sort of gamifies text editing. I don't claim that
| using Vim makes me x-times more efficient at programming than
| someone else, but I do enjoy the thrill of learning a new,
| quicker way to make some changes.
|
| - Vim/Neovim offers me a seemingly endless amount of things to
| learn. Some may see this as a negative thing, but I see it as a
| feature. It's truly like a skill or a hobby. You can learn the
| basics and be perfectly fine, but you can also dive deep into
| more ways to improve. I love this.
|
| - I love how configurable it is, and also that you can actually
| learn about how it works.
|
| - Also if I'm being honest, I feel like a myself and a lot of
| other Neovim users are basically masochists to some extent.
| modernerd wrote:
| Agree that it gamifies text editing - vim motions are fun,
| even though I largely don't miss them in VS Code, or I use a
| vim extension when I do.
|
| > ...myself and a lot of other Neovim users are basically
| masochists to some extent.
|
| It's great of you to say this, and heartwarming to see a
| sense of self-awareness on HN.
|
| It's easy to rationalise our tech choices away (vim = speed,
| efficiency, freedom!). It's harder to admit that we may have
| chosen our tools simply because it's fun to walk a learning
| curve that runs sharply from pain to joy. Of course we could
| pick an easier tool! But then our path runs from apathy to
| apathy! And we'd be making it alongside people who think
| tools are just tools, instead of within a counterculture of
| likeminded people who think that tools are _everything_.
|
| Maybe I should give neovim another shot...
| simonsaysso wrote:
| The sunk cost fallacy is real.
|
| Most important to me when I started tinkering with him was the
| speed/feature tradeoff, and portability. I was working on 7
| machines at one point doing pretty quick edits of config files
| and Python scripts, so launch speed and availability across
| different environments drive me to vim.
|
| Now there are alternatives, but back in 2015 these were all in
| their infancy. And now I _know_ vim and it keep adding more
| features. The incremental cost of adding language server
| support is much less than the cost of learning how to move
| around VSCode, so my (neo)vim config keeps growing slowly but
| surely
| gkfasdfasdf wrote:
| neovim/vim are lightning fast, and since they are usually
| installed on remote servers as well it is nice to have a
| consistent experience editing files whether I am working
| locally or in a remote shell somewhere.
| ar_lan wrote:
| > why you chose it over VS Code
|
| VS Code has always felt clunky to me. It always felt like a
| halfway house between the speed and simplicity of Vim and the
| maximalism offered by JetBrains IDEs. I also just generally
| don't love GUI apps for code because I desire to be right in my
| shell.
|
| NeoVim offers LSP, Tree Sitter, DAP, and easy extensibility to
| reach full parity with any IDE, but with the benefit of it
| being:
|
| * Faster (both in processing speed but also in my workflow). I
| can navigate significantly faster in Vim than I can in any
| other editor. * More familiar, to me.
|
| I can't speak to Helix as I've never heard of it, but in
| general, the Vim community is very strong and long-lasting -
| it's been a top tier editor for the past few decades and will
| likely continue to keep that place (albeit NeoVim is the
| currently favored flavor for me).
|
| Beyond that, the extensibility of Neovim is unmatched in
| VSCode.
|
| I also do most of my development in a VM and VS code remote
| shell is significantly slower for me than just ssh + neovim.
|
| > huge amount of work, hoop jumping, and fragility to reach
| parity
|
| This seems inaccurate. Maybe it's because I use NixOS but my
| editor experience is literally the least fragile piece of
| software I use. I've ran into far more issues in both GoLand
| and VS Code than I have in Neovim. Perhaps because Neovim is
| less of a walled garden?
|
| It took me about a weekend to properly learn Lua and how Neovim
| works, and after that, I was set.
|
| > spent months tweaking
|
| I don't know what process you took, but properly learning the
| tool from the ground up and minimally adding useful plugins as
| you go should not take much time at all. I don't really touch
| my editor config unless I need to install a new LSP server - it
| always just works.
|
| --
|
| At the end of the day, the best tool is the one that enables
| you to be most productive. I find almost anything outside of
| the terminal clunky (the main exception is my browser).
| modernerd wrote:
| Thanks, some helpful insights here. (It sounds like the
| summary is, "set it up and don't fiddle with it too much.")
|
| I agree that the neovim community is great and neovim is of
| course very hackable, although there's always room to
| improve: an API for terminal UI would help a lot when writing
| neovim plugins and make everything feel more consistent, for
| example.
|
| > I don't know what process you took, but properly learning
| the tool from the ground up and minimally adding useful
| plugins as you go should not take much time at all.
|
| I built a neovim config from scratch, used built-in docs,
| community support, and well-known extensions when needed. I
| wrote small Lua plugins when I couldn't find extensions or
| workflows that worked for me. And I had fun doing it!
|
| I got something good in a weekend, something very decent in a
| week or two, but still had a lot of gaps between what I had
| and what I wanted (session save, restore and quick switching;
| a Magit-like staging and forge management UI for GitHub CLI
| -driven PR management; invoking and managing long-running
| terminal processes from the editor; find/replace in large
| numbers of files across big projects with something more
| intuitive than a quickfix list; linting with something
| lighter-weight and easier to configure alongside LSP servers
| than ale; quicklists for LSP issues; a simple test runner
| with quicklist for errors; I can go on...).
|
| After trying out extensions for some of those things but
| finding nothing that fit the bill, I played with Emacs and
| had a pretty similar experience there (weeks of work just to
| reach parity with VSC+a few extensions). I concluded I was
| wasting my time -- it was pretty clear I was after an IDE
| more than a text editor at this point. VS Code seemed a nice
| in-between option. There are things I miss from vim/Emacs
| (speed, keyboard-driven workflow, getting to enjoy and
| celebrate editors with a community of likeminded weirdos),
| which is why I tend to get sucked in by these update
| announcements and discussions. But for the most part VSC is
| fine.
| __s wrote:
| I have a simple .vim setup which I can use across multiple
| machines: https://github.com/serprex/.vim (I know there's
| simpler out there; I haven't spent time pruning my config down)
|
| I prefer sticking to full terminal UI
|
| When I used vscode I was frustrated by vsvim's latency &
| missing features (macros tended to have holes)
|
| I didn't start using vim until I'd been programming for a
| decade already. Before that I mostly used SciTE
|
| You may be more susceptible to over tinkering. In the past few
| years the most I've tinkered with my setup was when I decided
| to try out neovim's lsp feature, where previously I'd been
| using coc.nvim
| jesperlang wrote:
| Why? Here are some reasons in no particular order!
|
| * +20 years of muscle memory
|
| * Total customizability, when you get good at configuring and
| writing small scripts it feels like you can do anything. VSC
| feels like it's all about plugins
|
| * On the fly remaps. E.g writing latex and quickly add insert
| mode remaps for things you are currently writing about ":imap
| CO2 $CO_{2}" for a prettier version of CO2 as you type. Playing
| around with Zig? With ":map ,t :w<CR>:!zig test %<CR>" you can
| type ,t and it saves and tests the current file.
|
| * Write simple scheme files for pattern matching with
| Treesitter to conceal unnecessary clutter in some programming
| languages
|
| * Snippets, other editors have this as well but with Luasnip I
| program every aspect of how it works exactly as I want it
|
| * Even with a bunch of plugins it starts in less than 100ms
| divan wrote:
| I tried to use Helix and really liked it, but had to stick with
| Neovim because of Copilot.
| modernerd wrote:
| I also really like Helix. Looking forward to:
|
| - Reload of files changed on disk: https://github.com/helix-
| editor/helix/pull/2653
|
| - Autosave: https://github.com/helix-editor/helix/pull/3178
|
| - Git/SCM support: https://github.com/helix-
| editor/helix/issues/227
|
| - Extensions (potentially enabling Copilot support):
| https://github.com/helix-editor/helix/pull/2949
| zimpenfish wrote:
| > If you use Neovim, can you share why you chose it over VS
| Code
|
| Just about 30 years of muscle memory for ed, then vi,
| eventually vim, and recently neovim. Also because one flavour
| or another is pretty much guaranteed to be available on any
| server I log into - as a contractor, it's handy to know there's
| a (to me) usable editor wherever I end up.
|
| > I've spent months tweaking Neovim/Emacs configs in the past
|
| I had a brief spell of Emacs madness at uni but then recovered
| and I've had pretty much the same vimrc since picking up vim
| modulo adding things like go-vim and surround in the last few
| years.
| Grimburger wrote:
| > pretty much guaranteed to be available on any server I log
| into
|
| So is nano, the original comment hits the mark, why exactly
| can't you use a proper code editor via ssh? There's very
| little reason these days. Haven't used a terminal editor for
| a decade despite doing tons of work that many would
| instinctively reach for the same job.
|
| VSCode and pretty much every other equivalent has modal
| editing if that's the sticking point here.
| zimpenfish wrote:
| > nano [pretty much guaranteed to be available on any
| server]
|
| Having just checked 5 of the servers I'm currently logged
| into, nano is missing on 3 of them. Although one of those 3
| is cygwin which is weird in the first place.
|
| > why exactly can't you use a proper code editor via ssh?
|
| Well, vim is a proper code editor. If you mean VSCode, it's
| not available everywhere; been at plenty of places where
| installing/using non-approved software on work machines was
| forbidden. Also, and this is a minor point, kinda, but
| using (n)vi(m) remotely rather than VSCode gives me
| one/many windows fewer to manage on my local end -
| everything currently lives in iTerm2 and I only have one
| app to wrangle. Using VSCode would give me another one -
| unless it can do terminal emulation as well these days?
| ar_lan wrote:
| What exactly is a "proper code editor", and why does Neovim
| not fit the bill there?
| ptato wrote:
| Modal editing in VS Code is not good enough. I still use it for
| certain things. Just not the bulk of my programming.
|
| When helix is more ready, I will probably switch to it.
| norman784 wrote:
| I use both, there are certain nuances with helix right now,
| like exploring the project structure, there's a sidebar in
| the works, but is not ready yet, also when you need to create
| new files I find it easier to do it in vscode.
| [deleted]
| sigmonsays wrote:
| can't have a vim discussion without someone bringing up emacs
| jhoechtl wrote:
| Emacs gas sub-par treesitter support and will go by default
| with eglot which is ok but nowhere as polished as the lsp
| experience in Neovim.
| sva_ wrote:
| Finally I can get off the dev branch (which has been extremely
| stable though)
| andrewla wrote:
| I've been a Neovim user since inception -- I love the sane
| default configuration, the pruning away of old and obsolete
| "compatible" mode things, and the async and terminal support were
| killer features. When LSP support landed I was pretty firmly set.
|
| I hate Lua, though, and more and more of the neovim ecosystem is
| moving in that direction. And now that vim has caught up on the
| async and terminal and LSP support I'm finding it hard to justify
| staying on neovim, except for the burden of sane-ifying my
| configuration.
|
| VimL9 looks fantastic though -- VimScript has always been awkward
| but very domain-specific; VimL9 moves away from awkwardness but
| keeps the domain-specificity. Lua is not domain-specific enough,
| and the debugging and documentation are not good enough for me to
| pick it up in a pinch.
|
| I think it's likely that I'll be making the switch back to vim9
| in the near future, although I'll probably give Kakoune a try
| again before committing.
| coinbasetwwa wrote:
| I still haven't recovered from the last couple updates... I'll
| probably be making the switch to VIM very soon.
| hyperpl wrote:
| Hi could you please elaborate?
| ollien wrote:
| Do you mind elaborating?
| kuratkull wrote:
| You make it seem like some obvious things were recently
| broken/changed. I have used NeoVim for a couple of years, I
| haven't noticed any breaking changes. Please elaborate
| psalminen wrote:
| I use vscode and neovim. Both have their benefits.
|
| Neovim is my main driver for reviewing/editing code. I have a few
| plugins and many personal functions/key bindings.
|
| Vscode is great for quick copy/paste text and their plugin
| ecosystem. Ie working with azure has been a dream with vscode.
| pacetherace wrote:
| I feel the proliferation of plugins has made the whole vim/neovim
| echo system too complicated and overwhelming to adapt for a new
| user. 1. Vim itself has a learning curve 2. There are many great
| plugins, but if they don't work for you, then unless you are an
| advanced user, it is impossible to get everything working without
| wasting a day 3. I find it weird that to get a vim plugin to
| work, I might have to install llvm and do a compilation and prey
| that all the dependencies have been satisfied
| renewiltord wrote:
| This is possibly my favourite kickstarted project. I use this
| every day and got far more than my contribution was worth. Quite
| happy.
|
| My latest thing is I use it with C-x C-e in the terminal and
| copilot.vim to get shell autocompletions!
| hd4 wrote:
| They added a msi installer since 0.6 so that's pretty cool
| g_delgado14 wrote:
| Dumb question; what's an msi installer?
| freeCandy wrote:
| The installer for Windows
| https://en.wikipedia.org/wiki/Windows_Installer
| ajoseps wrote:
| I've tried using neovim for C++ dev but keep ending back in
| either vscode with intellisense or YCM on Vim. I don't know if
| I'm just misconfiguring things but I haven't been able to get
| autocomplete working correctly. Any tips?
| ckolkey wrote:
| https://github.com/hrsh7th/nvim-cmp should be the ticket
| simjue wrote:
| I've also tried using vim/neovim etc. several times but had the
| same problem. Recently I've tested lunarvim and autocomplete
| worked out of the box (with Go).
| gillh wrote:
| We recently started providing standardized neovim centric
| dotfiles setup to developers at our startup and this setup has
| improved productivity quite a lot.
|
| Our neovim "distribution" is highly geared towards our tech stack
| (Golang etc.) and provides fzf based command palette.
|
| See: https://github.com/fluxninja/dotfiles
|
| We aren't using neovim's built-in LSP as we found it to be a bit
| immature. Instead we are providing coc.nvim.
| [deleted]
| BaculumMeumEst wrote:
| I really wish neovim could ship usable default colorscheme and
| round out its lsp support with autocompletion. Treesitter isn't
| for me; it's slower to open files and I have no idea how people
| make sense of so many different color groups.
|
| Still sticking with vanilla vim and CoC for the time being,
| they're rock solid.
| alwillis wrote:
| _Treesitter isn't for me; it's slower to open files_
|
| I certainly haven't experienced any slowness with opening files
| with Neovim with Treesitter. It certainly enables much better
| syntax highlighting, among other things [1]. If anything, it's
| _faster_ than the regex-based syntax highlighting that Vim
| traditionally used.
|
| CoC is a 3rd party LSP plugin that works with Vim and Neovim.
|
| [1]: https://neovim.io/doc/treesitter/
| BaculumMeumEst wrote:
| Treesitter is slower to parse a file initially but quicker at
| handling incremental changes. You probably won't notice
| unless you open a huge source file.
| robenkleene wrote:
| Never used Treesitter, but I'd assume all this happens
| async? I.e., does Neovim actually block text editing untill
| the parsing is finished or do you just see unstyled content
| until it finishes?
|
| (I'd just be surprised if anything new worked that way in
| 2022, let alone something built for async like Neovim.)
| BaculumMeumEst wrote:
| It blocks text editing until it finishes.
| yjftsjthsd-h wrote:
| > usable default colorscheme
|
| What's wrong with the default colorscheme?
| BaculumMeumEst wrote:
| https://ibb.co/TR9sWj8
| tmtvl wrote:
| That looks pretty good, I don't know what the default
| colour scheme looks like, but if you are proposing this as
| an improvement I hope it gets in.
| [deleted]
| thetic wrote:
| This is planned for the next release:
| https://github.com/neovim/neovim/issues/14790
| NaN1352 wrote:
| Any neovim based "gtk vim" app on linux?
|
| gVim is so slow for me, can literally see the window text redraw
| from top to bottom, where sublime text or vscode switching tabs
| or scrolling is near instantaneous.
| ckolkey wrote:
| Something like https://neovide.dev/index.html ?
| dyingkneepad wrote:
| Neovim is one of those things that seem maybe cool, but I just
| can't find a reason to switch. Vim works just fine for me, I
| don't know what I would be getting by switching, and I'd probably
| waste some time porting my config and workflow to whatever the
| differences are (I'm a heavy user of :terminal).
| freedomben wrote:
| Yeah it's a tough one. I've switched back and forth relatively
| freely over the years, but now that new VimScript (vim9 script)
| has breaking changes and neovim will not be supporting it, it's
| probably time to pick a pony.
|
| I may end up sticking with og vim but my heart has always been
| with neovim. regular vim would undoubtedly still be stuck in
| the stone age (including with no :terminal) had neovim not
| started some competition. I get the feeling that VimL's
| evolution was done in a way that made it quite difficult or
| impossible for neovim to merge/rebase into. Hopefully that
| wasn't intentional.
| yoyohello13 wrote:
| The creator of Neovim's LSP integration is currently working
| on a VimL9 JIT compiler to make Vim9 plugins work for Neovim
| (early stages). So you still may be able to stay on the
| fence.
| alwillis wrote:
| "Exciting progress on vim9script => Nvim-Lua transpiler":
| https://twitter.com/Neovim/status/1575455161186664451
| alwillis wrote:
| Vim has had :terminal since version 8.1 [1].
|
| [1]: https://gist.github.com/mahemoff/8967b5de067cffc67cec174
| cb3a...
| freedomben wrote:
| Going somewhat off memory here, but my recollection is that
| was like 3 or 4 years after neovim's first release.
| alwillis wrote:
| That's true.
| StevePerkins wrote:
| I think the selling points are supposed to target plugin
| authors, and people who like to use a ton of plugins.
|
| However, I would imagine that well over 90% of Vim users don't
| use a single plugin. At all. They defined some look and feel
| defaults in a ".vimrc" file 10+ years ago, and never thought
| about it again. At least that's my user profile, anyway.
|
| So to me, the NeoVim story is mostly Internet drama, about some
| salty devs who didn't get their patches merged and have been
| publicly jihading ever since. It's not enough to merely _use_
| NeoVim, you have be _angry_ about it.
| asdfqweqe12 wrote:
| Telescope is must have for me.
|
| https://github.com/nvim-telescope/telescope.nvim
| cool_hw wrote:
| fzf.vim works better, in my subjective opinion, but I haven't
| configured telescope a lot.
| ckolkey wrote:
| You can change the back-end for telescope so it uses FZF,
| of FZY or whatever for the filtering. But fzf.vim works a
| bit better out of the box
| codetrotter wrote:
| From the opposite side, I decided a few years ago to use neovim
| in place of vim, and there were no drawbacks to making the
| switch for me.
|
| Then again, most of my time these days I spend in JetBrains
| Clion with Vim emulation, as it is much better suited to the
| kinds of projects that I currently work on than Vim or Neovim
| ever was. So take my opinion on Vim vs Neovim with a grain of
| salt.
| pletnes wrote:
| The big downside is having to install neovim. Good old vim is
| in macos, git bash on windows, any random vm you're thrown
| into... I also use the vim plugin for intellij et al, but I
| use vim on all the raspberry pi's, weird windows boxes with
| some issue, and so forth. It's already everywhere and neovim
| isn't.
| bilekas wrote:
| Personally I switched purely because of lua, I don't really gel
| with the vimscript.
| [deleted]
| ainar-g wrote:
| Back in the day, Neovim has always felt about three times
| snappier than Vim (I think it was Vim 7.2). Also, I don't
| remember if the newer versions of Vim have it, but Neovim has
| native LSP support, which is also very nice.
| maxoid wrote:
| the reasons why i switched to nvim:
|
| - configuring in lua (much easier than vimscript, imho) -
| treesitter - built-in language server protocol - plugins (id
| call them "projects") like telescope
| alwillis wrote:
| Your .vimrc will probably work as-is without much work from
| you.
|
| Plus Vim and Neovim can co-exist on the same machine without an
| issue to try it out [1].
|
| [1]: https://neovim.io/doc/user/nvim.html#nvim-from-vim
| Cupprum wrote:
| I switched to neovim because of LSP (Language server protocol)
| support. I know there are libraries (or whatever cool kids call
| it these days), which brings this functionality to og vim, but
| the lsp integration in neovim just works so nicely out of the
| box.
| styren wrote:
| Hold on, you don't need anything like Ale or CoC to run LSPs
| in neovim?
| agency wrote:
| Nope, NeoVim has native LSP support
| https://neovim.io/doc/lsp/
| sgk284 wrote:
| Vim user for 15+ years here. Switched to neovim last December
| to try out Github's Copilot plugin (which only supported
| neovim), and it was basically a drop-in replacement for vim.
| And I haven't looked back.
|
| I'm also a heavy user of terminal though, and that was the
| _one_ thing I spent extra time on, because there were subtle
| differences that I didn 't like. If you give neovim a shot
| again, try this in your ~/.config/nvim/init.vim (aside: I do
| miss the simpler path of ~/.vimrc): " Neovim's
| default terminal mode bindings aren't great.
| " This makes them behave like vim's. tnoremap <Esc>
| <C-\><C-n><C-w> tnoremap <C-w> <C-\><C-n><C-w>
| "Always enter the terminal in insert mode autocmd
| BufWinEnter,WinEnter,BufEnter term://* startinsert
| autocmd TermOpen,TermEnter * startinsert command!
| -nargs=0 Terminal :vsplit | term
|
| This allows navigating across splits more seamlessly, and I
| like defaulting to insert mode whenever I move into a terminal.
| I also added the :Terminal command because I prefer them in a
| vsplit by default.
| jasonpeacock wrote:
| In additional to all the features that others mention, I chose
| to support the Neovim project. It's a more open alternative
| without a BDFL that is willing to move forward and modernize
| the editor, drop support for ancient platforms, and regularly
| release improvements.
|
| A big deal was splitting the editor engine from the interface
| so that it's embeddable in other editors.
| da4id wrote:
| I tried moving to neovim from vim mainly to try Copilot.
| Jenk wrote:
| Neovim is vim 8 compatible. It _also_ supports LUA script for
| config and plugins, has native LSP support, and runs much more
| efficiently.
|
| You can run your current .vimrc using neovim.
| Normille wrote:
| >Neovim ... supports LUA script for config and plugins
|
| Except it doesn't really. Or at least it's very basic. I'll
| re-post a comment I made on this, when it was discussed a
| while back [0]
|
| https://news.ycombinator.com/item?id=32624308
|
| ----
|
| I've been using Neovim for several years now. Not for any
| real reason, other than "Let's try 'new & shiny'" when it
| first emerged. Last week I thought I'd finally get round to
| converting my existing Neovim init.vim config [which had
| itself been inherited and developed from my earlier Vim
| .vimrc one] to Lua [not a language I'd ever used before. But
| the syntax looked fairly straightforward].
|
| What a waste of time! The easy stuff [enabling/disabling
| various options] was easy. But then it's easy in Vimscript
| too. The difficult stuff [defining autocmds, managing my
| plugins] was either completely ignored in every single
| "convert your init.vim to to init.lua" tutorial I read... or
| required wrapping the existing Vimscript block in
| vim.cmd[[ ... ]]
|
| in Lua because Neovim's Lua support can't yet do a lot of
| this stuff natively. Oh, and this also had the brilliant
| side-effect of removing syntax highlighting from great
| swathes of my config file as everything inside vim.cmd[[ ...
| ]] is rendered as a comment. I spent the best part of a day
| wrestling with converting to init.lua, left it overnight and
| then, in the morning thought Why the fuck am I wasting time
| trying to beat this into shape, when my existing vim.init is
| already set up exactly how I want it?" and I reverted back to
| good ol' crusty ol' unfashionable Vimscript.
|
| YMMV if you're actively developing plugins and want to use a
| more widely utilised language to write them in. But for
| configuring Neovim itself, Lua is more hassle than it's
| worth.
| ckolkey wrote:
| Couple things. Over the last year, the lua API has
| expanded. You can now do almost everything with only lua!
| Autocmds, commands, plugin management - all in lua. Even
| key-mappings can call lua closures directly! And with
| treesitter, the strings in `vim.cmd([[...]])` calls get
| highlighted as vimscript.
|
| Not saying you should give it another go, just that your
| info is out of date ;)
| alwillis wrote:
| The Neovim API is more fully baked now than it was.
|
| I went through the same thing back in the day... now it's a
| breeze and I've never coded in Lua before. Part of the
| problem was different users suggesting different things.
|
| "Build your first Neovim configuration in lua" is a good
| introduction [1].
|
| [1]: https://vonheikemen.github.io/devlog/tools/build-your-
| first-...
| flutetornado wrote:
| I found this very helpful when switching to nvim recently.
| Kudos to the author for having the nvim config on github
| and making videos explaining how he set it all up:
|
| https://github.com/LunarVim/Neovim-from-scratch
|
| https://www.youtube.com/watch?v=ctH-a-1eUME&list=PLhoH5vyxr
| 6...
| alwillis wrote:
| I gotta say, the Neovim guys are killin' it on YouTube
| and Twitch.
|
| They're reaching a new generation of Neovim/Vim users.
| cool_hw wrote:
| Treesitter integration is a bit easier in neovim IMHO (but I
| haven't tried to make it work with vim too much.)
|
| Newer plugin development seems to be much more on the nvim side
| than vim as well. (Although I do feel fzf is superior to
| telescope, at least out of the box.)
|
| I'm happy neovim exists, it rekindled vim development.
|
| Also, someone correct me if I'm wrong, but isn't the bus factor
| 1 on vim?
| Beltalowda wrote:
| > Also, someone correct me if I'm wrong, but isn't the bus
| factor 1 on vim?
|
| There's a bunch of people who are "members" of the vim
| organisation on GitHub. I don't know if they have full admin
| privileges or just commit/issue access. I never really
| understood why this has to be a problem in the first place:
| can always clone the repo and continue working on it if Bram
| disappears.
| cool_hw wrote:
| ------- vim/vim is licensed under the Vim
| License There are no restrictions on using or
| distributing an unmodified copy of the software. Parts of
| the software may also be distributed, but the license text
| must always be included. For modified versions a few
| restrictions apply. The license is GPL compatible, you may
| compile the software with GPL libraries and distribute it.
|
| -------
|
| Source, if anyone wants to dig deeper:
| https://www.gnu.org/licenses/vim-license.txt
|
| Unsure why I'm being downvoted but okay.
| qudat wrote:
| Plugins built with lua, lsp, treesitter for syntax highlighting
| are the big ones.
|
| https://neovimcraft.com -- For neovim specific plugins
| tomjakubowski wrote:
| Yes, treesitter is a sea change. Besides the quick and error-
| tolerant syntax highlighting it provides, plug-ins which use
| it to manipulate syntax are remarkably fast and accurate.
| alwillis wrote:
| Just built it from source on a beta of macOS Ventura...
| everything went smoothly. These guys have done a great job.
| imbnwa wrote:
| Must every neovim release thread be brigaded by naysayers asking
| the same question for the 1000000th time? If you don't like its
| value proposition, don't use it. Simple. Keep using your IDE or
| whatever solution you prefer. This is almost exclusively happens
| in (neo)vim threads, and its so utterly distracting. That there
| is an entire community camped around neovim should answer your
| question about why anyone choses it over {insert non-vim
| solution}
| CapricornNoble wrote:
| That's a LONG list of fixes & features. I'm fairly new to vim
| (using Neovim as an IDE to learn Rust) but I'm very tempted to
| pull and build this release.
| zetaposter wrote:
| A text editor without a well rounded GUI story isn't worth it for
| me. There are all these desperate projects each with their own
| focus, ranging from "simple graphics acceleration" to "tons of
| bells and whistles, animations and ad-hoc UI extensions".
|
| UI should be thought out at PRs and issues, but the same people
| who develop the main core. But they don't have to, because
| they're making a terminal application, which has its use cases.
|
| But I so no reason why I should type my text in a terminal, when
| I can use a proper GUI application.
|
| And I'm not even suggesting VSCode, even Emacs is better in this
| regard, which is what I use.
| xwdv wrote:
| The terminal is superior. You are just not skilled enough or
| advanced enough in thought to imagine what an interface can
| truly be.
| sja wrote:
| Is this a sarcastic remark? If not, this seems like an
| extremely reductive stance. Surely one could imagine another
| skilled person preferring a GUI over the terminal, even if
| it's not an opinion they share :)
| xwdv wrote:
| There is no sarcasm here. Zero.
| SuperCuber wrote:
| Your terminal application is an emulator of a decades old
| technology originally used in physical consoles, with layers
| upon layers of enhancements that add support for colors,
| cursor control, etc. At it's core, it's just a grid of
| characters. The GUI as a platform is quite literally a
| superset of the terminal, for example because the terminal
| emulator app is a GUI itself. Hacking the grid of characters
| to render lines as if it was a GUI is hardly "superior".
|
| I say all that as an avid neovim user myself by the way. On
| mac/linux I use it through the terminal, on Windows I use it
| through the QT application.
| lapinot wrote:
| OTOH it's already probably a couple decades since some more
| fresh terminal emulator projects have popped up that kick a
| bit into the old cruft and provide both lightweight stuff
| and actual drawing routines for specific stuff. From a
| graphics dev pov it's not nonsense to decide for rendering
| on a grid, even for UI, i see it a bit like voxel 3D
| engines.
|
| So i'm really not sure the "layers upon layers" critique is
| well suited for terminals, in comparison with say some
| qt/gtk/electron/<your gui>. Also GP is mentioning emacs,
| which is mostly the same old cruft as a terminal emulator.
| alwillis wrote:
| The new generation of terminals are nothing like what
| you're describing: GPU acceleration, full color support,
| font shaping, support for ligatures, built-in support for
| multiplexing, SSH and more.
|
| WezTerm [1] is probably the best example right now but
| there are others.
|
| These aren't your father's terminals.
|
| [1]: https://wezfurlong.org/wezterm/
| mh7 wrote:
| A real terminal or a fake one drawn ontop of a gui emulating
| deacades old cruft?
|
| Complete madness and inefficiency.
| scombridae wrote:
| By vim user count alone, I would conjecture that the venn
| circle of philosophically opposed devs has more people
| insisting on the absence of a GUI story, than those insisting
| on one.
|
| Of course the vast majority of devs use whatever suits them,
| GUI or not.
|
| And you couldn't have picked an editor with a worse GUI story.
| andrewcl wrote:
| Do you have any refs/links of UI thought out at PRs and issues
| that you think are good examples?
| sophacles wrote:
| You're right. An environment that's all text and generally uses
| fixed width fonts is not at all the proper place to run an
| editor for dealing text that is best understood by displaying
| it with fixed width fonts.
| gregwebs wrote:
| One of the main features of NeoVim over VIM is that NeoVIM can
| be embedded into other programs and new GUIs can be built that
| use libvim. There are now programs you can download that do
| that, for example [1]. Certainly, this is still an experimental
| line of software and I don't use the NeoVIM GUIs and don't
| claim that this has been proven a success yet, but there are
| some encouraging signs.
|
| https://github.com/topics/neovim-guis
| alwillis wrote:
| I've used a few of the Neovim GUIs; they each have a
| different take on UI/UX for a Neovim GUI.
|
| I've been using VimR the longest, which is a Mac-native GUI
| for Neovim: https://github.com/qvacua/vimr
___________________________________________________________________
(page generated 2022-09-30 23:01 UTC)