[HN Gopher] Neovim 0.5 is overpowering
___________________________________________________________________
Neovim 0.5 is overpowering
Author : imbnwa
Score : 539 points
Date : 2021-05-26 14:56 UTC (8 hours ago)
(HTM) web link (crispgm.com)
(TXT) w3m dump (crispgm.com)
| agumonkey wrote:
| Kudos for the project, impressive trajectory.
|
| -- m-x sent-from-my-emacs
| skohan wrote:
| With LSP support now coming "out of the box" with neovim and
| SublimeText 4 I'm hopeful that it can escape the microsoft
| ecosystem and truly become an open standard. I tried implementing
| an LSP several months ago _without_ using VSCode as a test bench,
| and the tooling and documentation weren 't there - but with more
| default implementations out there, hopefully it can change
| harryvederci wrote:
| Big fan of Neovim 0.5! It's not released yet, but I'm already
| using it as my Clojure "IDE" at work, and all my nvim configs are
| written in Fennel, a lispy language that compiles to Lua. I guess
| it's time for me to start donating to Olical, Technomancy, and
| the Neovim crew, they do some amazing work!
|
| If you want to learn (Neo)Vim and don't mind a dose of
| hyperactive video learning, I recommend watching ThePrimeagen his
| youtube videos. I've been using Vim for years, but still learned
| new things over there:
| https://www.youtube.com/c/ThePrimeagen/videos?view=0&sort=da
|
| Oh, also: I kinda instigated this thing, sorry TJ:
| https://clips.twitch.tv/PrettyAgreeableMagePanicVis-4IhDSOhr...
| tjdevries wrote:
| unacceptable ;)
| ho_schi wrote:
| I've migrated from Neovim 0.4.x to upcoming Neovim 0.5.x last
| week, together with neovim-plug. Then I installed nvim-lsp and
| nvim-comp, as LSP-Server I used CLANGD (sadly there is no nothing
| similiar from GCC available) for C and C++. And it is awesome :)
|
| I'm was actuall missing short and clear guide. It's actually
| easy. What I've struggled with are the ERROR and WARNING markers,
| they use default colors which doesn't match well the used theme
| (peachbuff).
|
| Change it if required: hi
| LspDiagnosticsVirtualTextError ctermfg=Red ctermbg=White hi
| LspDiagnosticsVirtualTextWarning ctermfg=DarkYellow ctermbg=White
|
| I recommend that all your projects setup use a specific C or C++
| Version. Why? Because GCC 11 uses by default C++17 but CLANG 11
| uses C++14 by default. e.g. with Meson:
| project('project_name', 'cpp', version : '0.99', default_options
| : ['cpp_std=c++17'])
| duped wrote:
| > Give Neovim 0.5 a try, you will find that it is not difficult
| to make it as powerful as VSCode
|
| Does Neovim support webviews in extensions? Can it?
|
| There are a lot of useful visualization tools that VS Code allows
| that require them. It's one of the most powerful features of the
| editor, imo.
| agambrahma wrote:
| OTOH, Neovim can work in a remote SSH session, fully featured
| within a terminal.
|
| (Yes, I know people don't do a lot of SSH-ing and coding these
| days)
| brianvli wrote:
| +1 to this. Having nvim as my daily driver allowed me to NOT
| upgrade my 4 year old macbook with the next top-of-the-line
| macbook, saving me an arm and a leg. Instead I just got a
| gaming PC with way higher specs for less than half the price
| and I just ssh into it now.
|
| It's also neat to be able to code from an iPad by SSH'ing
| with Termius :)
| gen220 wrote:
| It also allows you to go the _other_ direction, and
| purchase a $200, nearly ten year old thinkpad, since it
| meets all your requirements for being productive.
| duped wrote:
| You can do this in vscode too.
| qwerty456127 wrote:
| > Language Server Protocol is created by Microsoft, RedHat and
| Codenvy, which provides language features (e.g. completion,
| navigation, formatting, and so on) through JSON-based RPC
| protocol...
|
| I'm missing out on this. Is it on par (at least potentially - by
| means of what it enables you to implement) with JetBrains IDEs
| and ReSharper already?
| PestoDiRucola wrote:
| I don't want to be flamed or start a debate about the values of
| one or the other, but why should someone in 2021 go through the
| hassle of setting up (neo)vim or any other terminal or barebones
| editor (looking at you emacs) when there's perfect solutions out
| there that work out of the box with a lot of features that neovim
| has. For example VSCode uses LSP "natively" and even has an
| excellent vi emulator you can install as an extension.
| b3morales wrote:
| Personally I find that for every feature that works out of the
| box there's two others that don't do what I want the way I want
| it. So I like my tools to be hackable. This does take time, and
| I admit I'm not always on the right side of the time savings
| chart[0]. ;) But I also generally find it satisfying -- tastes
| will differ on this point.
|
| [0]:https://xkcd.com/1205/
| avaldes wrote:
| Using a modern IDE after tunning and mastering vim command and
| modes for years is a real struggle.
| fmakunbound wrote:
| > VSCode uses LSP "natively"
|
| What do you mean by this? Is it some kind of same address space
| thing rather than LSP servers over sockets?
| da39a3ee wrote:
| I thought they meant as opposed to, say, emacs where the LSP
| client has to be installed as a 3rd-party package (eglot or
| lsp-mode). As you say, the server is in a different process
| by definition of LSP. I don't know vim but from skimming the
| article it sounded like, until neovim 0.5, for vim one also
| had to install the LSP client as a plugin. In VSCode in
| contrast, the LSP client is native in the sense that it is
| built into VSCode. That makes a big difference from Emacs at
| least, because the LSP clients (eglot at least) are still
| under heavy development.
| celeritascelery wrote:
| Means you don't need a plugin. Which is apparently a big deal
| to some people. Maybe the don't know how to install
| plugins...
| wcarss wrote:
| sometimes you do work right in a terminal.
|
| I use Sublime for almost everything, but sometimes I edit code
| I have on some servers where I don't want to manage a whole git
| repo and do pushes/pulls. I have vim and a .vimrc on those -- I
| could imagine replacing them with neovim if it had something
| shiny enough.
|
| I also sometimes end up just popping open a file locally, e.g.
| a config file or a one-off script, and I don't want another
| sublime window for it. I think I may even have less bound to
| open up vim, for syntax-highlighting reasons.
|
| I'm not saying _other people_ need to do what I do, just
| explaining that some folks like me like good terminal editors,
| even if we 've moved a lot of daily driving into other
| applications.
| rfcat wrote:
| Vim does not spy on you and does not lag when pressing buttons.
| Why use inferior Microsoft products?
| da39a3ee wrote:
| You appear to be 5-10 years out of date. Typescript, VSCode,
| Lean, are all "microsoft products", and if you think they are
| inferior you'd have to explain that view to a lot of well-
| informed people. Even LSP -- the basis of sanity in modern
| text editing -- originates and is stewarded by Microsoft.
|
| Edit: Microsoft also funds some of the work on the Haskell
| compiler as I understand it. On the other hand I
| unfortunately now have to use crap like Outlook and Office
| 365 at work, so it's not like I don't understand the
| dismissive "inferior microsoft products" but we really can't
| say that any longer when talking about development
| environment tooling (which is what TFA is about) and
| programming languages.
| bugzz wrote:
| Before I learned to use vim (neovim), I used VSCode. I tried to
| use the vi emulator extension in VSCode, but found it difficult
| to use due to hotkey conflicts, like trying to do something in
| vim but it's already a VSCode hotkey that does something else.
| The "hassle" of setting up Neovim really isn't that bad, and
| I'm very happy that I've been able to set up a customized
| experience that's contained in a single dotfile.
| kstrauser wrote:
| Without going deeply into it, I think that characterizing Emacs
| as a "barebones editor" is deeply flawed.
|
| I switched from Emacs to VSCode because I liked the feel of the
| more modern UI, but it certainly wasn't because Emacs was less
| good as an IDE. I can't think of anything I do in VSCode that I
| didn't have configured in Emacs.
| kzrdude wrote:
| VSCode has pros and cons, it has a nice web compatible view for
| multimedia. VSCode doesn't even support printing, which is
| weird. It's a memory hog and slow to start.
| bntyhntr wrote:
| 1) That sweet sweet feeling of feeling different. I've come to
| accept that part of the reason I use linux and vim is I derive
| some satisfaction from being "hipster". But not enough to say,
| use gentoo :)
|
| 2) Simplicity. Even with all my vim plugins, I never have
| issues with "IDE hogging all my ram" or "intellij crashes when
| loading a working set including this commit" (it worked for
| me...).
|
| 3) Ease of access. When remoting into my boxes, I can just tmux
| attach and continue editing where I left off, even on a shitty
| connection (using mosh). Very useful on train/conference wifi.
|
| In the spirit of your first clause, these are personal reasons
| that work for me. I have not listed the cons, of which there
| are many, and don't expect my reasons to apply universally.
| lvass wrote:
| I agree and that's why I use Emacs. It's perfect out of the box
| for me. I may not even use external packages if eglot gets
| merged in.
| coliveira wrote:
| Treesitter is not Neovim specific, any programable editor can
| access treesitter to do this, including vim. But it is nice to
| see it being tried on vi clones.
| aneutron wrote:
| It's fast. Mind-blowingly fast. I used it since beta (heck, even
| alpha) on a 2014 Pentium laptop, and I built many, many
| engineering school projects on it.
|
| VS Code used to take up the 1.8GB left from my measly 4GB.
| faho wrote:
| Does anyone know of a nice git interface for Neovim? I would love
| to get off of emacs, but it's hard to beat Magit.
|
| At the very least something that lets me view the repo status and
| stage selections would be good.
| frayesto wrote:
| vim-fugitive is my goto
| [deleted]
| pflock wrote:
| Haven't used Magit w/ emacs but have been using a library
| inspired by in for the last year or so:
| https://github.com/jreybert/vimagit
|
| not sure how it compares feature wise but I've found it
| extremely helpful.
| varbhat wrote:
| I would recommend you to try lazygit[0] but it's independent
| terminal tool not tied to neovim
|
| For Neovim Git Plugins ,see [1]
|
| [0]:https://github.com/jesseduffield/lazygit
|
| [1]:https://github.com/rockerBOO/awesome-neovim#git
| nine_k wrote:
| Why quit emacs when evil-mode exists?
|
| Fast startup times are solved by never quitting emacs :)
| Really, emacsclient starts nearly instantly, and all the heavy
| stuff like language servers and emacs proper just run in server
| mode.
|
| (Disclaimer: I know enough vi and often use it.)
| typon wrote:
| I've tried switching to emacs 3 times over the past few years
| and every single time I come back to nvim. It's just too slow
| for me.
| faho wrote:
| I _use_ emacs with evil-mode, and I don 't have a problem
| with startup time (and that's without emacsclient, which I
| always found too annoying to deal with).
|
| My issue is I don't really like emacs' mode of operating, and
| even with evil-mode it still seeps through.
|
| I also don't like lisp.
| Finnucane wrote:
| I tried starting with emacs. Then I tried Spacemacs and Doom
| Emacs, and began to realize that if the way to make emacs
| manageable was to treat it like vim, I might was well just do
| that. So now I use neovim.
| sva_ wrote:
| You may also use vs code with neovim integration[0].
|
| [0] https://github.com/asvetliakov/vscode-neovim
| inshadows wrote:
| I'm using tpope/vim-fugitive and airblade/vim-gitgutter (with
| standard Vim). Works good. The first one are commands, the
| second one marks changes on the left.
| anaganisk wrote:
| I have an honest question, the real advantage of Vi is its
| installed everywhere, and just works over ssh. What is the
| benefit of a terminal IDE like neovim or vim with tens of
| something plugins? Vscode or other powerful IDEs do the work much
| better.
| curriculum wrote:
| It's a good question. I'm very critical of my tools and I'm a
| 10+ year vim user, so I've thought a lot about this.
|
| vim's "killer feature" is its text editing language and
| modality. But plenty of other editors and IDEs offer vim
| emulation to varying degrees of success. So this can't be _the_
| reason to use (neo)vim-the-binary as my editor over, e.g.,
| VSCode.
|
| So for me the real advantage of vim is in its flexibility. I
| can make vim into whatever I want depending on the context.
| Because of this, I'm able to use the same vim in many different
| contexts, instead of having different tools for different
| tasks. Ironically, this is kind of like the emacs culture of
| doing everything inside of emacs.
|
| For example, vim is my code editor, of course. But I also have
| a keybinding to pop up my wiki and immediately start editing a
| note in vim. I have another keybinding I use when I'm writing a
| long piece of text in a textbox (like now) -- the binding drops
| me into vim, I write my text, and when I exit the contents of
| the buffer are immediately copied to the clipboard for pasting
| into the textbox. In each of these contexts, I have access to
| the same familiar environment with all of my configuration,
| keybindings, etc.
|
| I could probably wrangle VSCode into doing each of these
| things, but it would be clunky. Vim owes much of its
| flexibility to its lightweight terminal interface. I wouldn't
| want to open VSCode every time I want to write a quick note,
| for instance.
| majkinetor wrote:
| You can do that literary everywhere and with any editor, and
| even without editor. I created this when I was using vim:
| https://github.com/majkinetor/vim-omnipresence and this to be
| used with any OS control:
| https://github.com/majkinetor/isense-x (here used for AHK
| intelisense but that is just 1 usecase)
|
| The real benefit of vim vs any editor is modality and there
| is AFAIK nothing similar in any editor even with emulators.
| Editing/moving over text is just way faster with vim then any
| other editor (not just slightly faster, light years faster).
| I use vscode now because vim requires A LOT of setup and even
| when automated its pain in the ass. VScode and its plugin
| sync on the other hand makes it very fast to install anywhere
| with your config and keys so it compensate for slower editing
| to me since I need to have my editor EVERYWHERE (literary
| hundreds of computers).
| dmitriid wrote:
| > Editing/moving over text is just way faster with vim then
| any other editor (not just slightly faster, light years
| faster).
|
| Text? Yes. Code? No. Since editing moving code is a subset
| of refactoring, and Vim has no knowledge about code.
| majkinetor wrote:
| Well, this update is all about that so I guess... solved
| ?
| dmitriid wrote:
| It's on its way there, true :)
| curriculum wrote:
| Sure, you can make a hotkey to launch any editor, but not
| every editor is as "pathologically configurable" as vim.
| The combination of vim being terminal-based, highly-
| configurable, and lightweight makes it _nice_ to use in a
| variety of contexts.
| majkinetor wrote:
| Its not lightweight.
| gorjusborg wrote:
| It is, compared to pretty much any currently in-use
| editor.
| dmitriid wrote:
| > y. I can make vim into whatever I want depending on the
| context. Because of this, I'm able to use the same vim in
| many different contexts, instead of having different tools
| for different tasks.
|
| Better to have specialised tools for whatever they are good
| at than a tool that's isn't good at any, and you have to
| spend time cmolding it to be a pale imitation of specialised
| tools.
|
| > I wouldn't want to open VSCode every time I want to write a
| quick note, for instance.
|
| Why would you open VSCode? You open a note-taking app.
| yjftsjthsd-h wrote:
| > vim's "killer feature" is its text editing language and
| modality. But plenty of other editors and IDEs offer vim
| emulation to varying degrees of success. So this can't be the
| reason to use (neo)vim-the-binary as my editor over, e.g.,
| VSCode.
|
| "varying degrees of success" is rather short of "sufficiently
| to not cause problems"; in my experience they're only good
| enough to get into the uncanny valley of "will this work"
| hesitation before every keystroke outside the most common.
| gorjusborg wrote:
| From my experience, plugins add 'nice to haves', while the main
| benefit of vim is the core (modal editing, fast navigation,
| etc.).
|
| If I get on a linux machine other than my workstation, I'll
| generally not install any plugins and still be able to get the
| job done without getting frustrated.
| burke wrote:
| The people who actually use neovim disagree with the first and
| last sentences in your comment.
| sophacles wrote:
| Shhh, we're playing a game of "pretend pure opinion is a fact
| and hope no one notices".
| Macha wrote:
| Honestly, I don't have any system I can access where "vi" is
| not actually vim any more.
| konart wrote:
| > Vscode or other powerful IDEs do the work much better.
|
| Better how?
|
| As much as I respect VSC and IDEA authors - they are often 'too
| much' and too heavy. IDEA (and its children like Goland) in
| particular.
| gosukiwi wrote:
| VSCode is also way too bloated for me.
| Jiejeing wrote:
| Neovim also "just works" over SSH, and vim fragmentation has
| always been a thing anyway (e.g. debian shipping vim-tiny by
| default which is technically vim but also very lacking).
|
| Also using IDEs vs text editors with plugins is a matter of
| preference (and flamewar) and I disagree with your last
| statement.
| becquerel wrote:
| For me, vim is appealing because of the composable keyboard
| commands that let you navigate through text in a very powerful
| way. When you get good with it, it's way quicker than using a
| mouse. It also makes you feel cool, which is most important of
| all.
| shmageggy wrote:
| All modern IDEs have vim bindings.
| kzrdude wrote:
| My experience is that many of them are shoddy experiences.
| Some might be really good though.
| troyvit wrote:
| Exactly. They all emulate up to a point, and that point
| seems different with every emulator. Then slipping out of
| vi mode to do something specific to that
| editor/environment ruins the flow.
| 18al wrote:
| Although the emulations are getting really good. For
| instance this [0] VSCode plugin isn't even an emulation.
| It embed neovim into VSC, even loads your init.vim file.
| Snappy too.
|
| [0] https://github.com/asvetliakov/vscode-neovim
| dmitriid wrote:
| Better still, all modern IDEs have tools that actually work
| with _code_ , not text.
|
| And navigating _code_ is significantly fatser in an IDE
| than in Vim. This includes things like juping to
| definitions and implementations, finding call sites, fuzzy
| search on _symbols_ (not text) and dozens and dozens of
| other things.
| nobleach wrote:
| All modern editors (except Atom) do a substandard job of
| actually BEING Vim. And frankly, I don't believe being Vim
| should be a goal of other editors.
|
| As someone who has to use IntelliJ when doing Kotlin/Java,
| I miss all the wonderful things that my Vim can do. Sure
| IntelliJ even lets me load my init.vim for maximum
| compatibility... and it's simply not that great.
|
| Lastly, almost all modern editors suck down a ton of
| memory... whether it's Electron or JVM based. Sublime is an
| exception here.
| PestoDiRucola wrote:
| You can install a vi emulator that does all of that in most
| modern text editors or IDEs, VSCode included.
| RMPR wrote:
| "all of that" is a bit of an overstatement ime.
| samatman wrote:
| The advantage is that vi is a language.
|
| You can speak that language in Vscode... kiiiiind of, just like
| you can speak evil to emacs. But these are dialects, vim is the
| real deal.
|
| Neovim with a ton of plugins offers a lot of what an IDE brings
| to the table, and lets your fingers speak fluent vim at the
| same time.
|
| So when you're randomly shelled in to some stock install that's
| got vi (realistically this is mostly vim but it doesn't have to
| be) you can keep speaking your native language for whatever
| text editing you might happen to do.
| ngamboa wrote:
| With text editors, it's nice to have the UI be entirely made up
| of text. Makes it easier to think about how one would edit
| their text editor.
|
| Ah and vim is text editor, not really an ide.
| Accacin wrote:
| Work much better for you perhaps. I'm not sure why installing
| plugins invalidates Vim, when everyone I know that uses VSCode
| also installs many plugins.
|
| The difference for me, is that I only have what I want.
|
| My requirements for an editor are:
|
| 1) Fast <- Most important 2) Autocomplete 3) Fuzzy finding 4)
| Prettier/eslint or equivalent
|
| If I need to jump on a server, I do not suddenly forget how to
| use Vim without my .vimrc.
| harryvederci wrote:
| I first became interested in Vim for the modular editing, but
| you can emulate that in other things.
|
| What I stayed for, is how much closer to the "metal" it makes
| me feel. I started programming in IntelliJ, but using that I
| always wondered what was going on in the background. If I click
| on the green "play" icon, what happens? That magic is gone when
| using something like Vim without plugins. Configuring it to do
| everything you ever need yourself, however, can be quite a
| pain. So I gradually added plugins, to delegate the nitty
| gritty config work to plugin creators, making sure I understand
| what those plugins are actually doing, in order to not get back
| to a "I have no clue what my editor does" situation.
|
| > Vscode or other powerful IDEs do the work much better.
|
| The thing about Neovim is that this quote is becoming less true
| by the minute. Also, nvim can do some things that I don't think
| are possible in other editors. Have you tried embedding
| IntelliJ in your browser? :)
| aliceryhl wrote:
| I have to disagree with "powerful IDEs do the work much
| better". It's just not true. Neovim with a few plugins (less
| than 10 is certainly enough) can definitely compete with IDEs.
| djoldman wrote:
| I'm very excited for 0.5.
|
| For those in the know, when is it reasonably expected to be
| released?
|
| I can't be alone in only wanting to port my init file to lua
| ONCE.
| haolez wrote:
| Nowadays, I'm more tempted to use something more mouse focused
| for my geek itches. Like Acme, for example. Neovim looks cool,
| but I've long realized that I spend a lot more time reading than
| writing code. The automations and flexibility of the multi modal
| mode do not matter much for my use case.
| xwdv wrote:
| Ironic, because vim and neovim are specifically designed for
| programmers that spend more time reading than writing code. You
| can get to damn near any line in a massive project with just a
| couple key strokes.
| haolez wrote:
| I understand that and I'm a heavy emacs user, but I feel that
| just browsing with the mouse and clicking symbols as if they
| were links to navigate leaves me with less cognitive overhead
| overall.
| curriculum wrote:
| I'm most excited for the treesitter integration and its potential
| to amplify Vim's "killer feature": text editing as a language.
|
| Vim's editing language feels most powerful when I'm using its
| text objects: "ciw" means "change in word", "cis" means "change
| in sentence", and so on. But Vim's built-in text objects are not
| always a perfect match for the code you're editing. Suppose you
| want to change the first argument of a function, for example;
| there's no built-in "first-argument" text object. But Treesitter
| integration makes it easy to create text objects that understand
| the AST. Without much effort, users will be able to make mappings
| like `cia1` to "change in argument 1", and these mappings will
| work across all languages with Treesitter support.
| [deleted]
| Kaze404 wrote:
| Are there really no plugins for that? In Doom Emacs "cia"
| deletes an argument normally, which I assume is done by an evil
| mode plugin, so I thought there was one for Vim as well.
| curriculum wrote:
| There are, but they usually rely on regex or other brittle
| approaches, making it difficult to write well. And currently
| you'll need to use different plugins for different languages
| (e.g., jedi for python).
|
| Treesitter builds the AST, making it easier to create robust
| text objects. And it provides a unified interface for a bunch
| of different languages, meaning that I don't need to have 10
| different plugins, one for each language, just to get access
| to text objects.
| e-v wrote:
| The plugin you are referring to is evil-args
| (https://github.com/wcsmith/evil-args), which is included in
| Doom Emacs by default.
| sophacles wrote:
| Various plugins can do it on a per language basis, but tree
| sitter is a nice abstraction that allows such commands to be
| done with a simple mapping - then tree sitter (with a per-
| language plugin) will parse to the same ASTish thing, so any
| language that has function arguments will have the same
| commands working the same way.
|
| I'm actually kind of excited about tree-sitter - it's not a
| neovim feature, it's an independent project that can be used
| a lot of places. I think the effect will be similar to how
| LSP changed the landscape from "every editor does some parts
| of handling language X well, but the parts each editor does
| are different from each other" to "all the editors get this
| feature when the language server does", just for syntax
| highlighting and syntax aware edition.
| markus_zhang wrote:
| Damn this looks cool. I always want this kind of flexibility.
| I'm using both Jetbrain products and VS right now, and one pain
| point is that it's difficult to define new short-key
| combinations and assign a key to it.
| alpaca128 wrote:
| This is one of the biggest strengths of Vim imho. Defining
| new keybindings is so intuitive and flexible you wonder why
| it's usually done differently.
|
| With Vim you basically just tell it to map any sequence of
| inputs to any other sequence of inputs. If you know how to do
| something in Vim you can define a keybinding for it. And
| because Vim is 100% controllable via the keyboard you can
| bind anything to a shortcut.
| ponyous wrote:
| I can never remember what all those different maps do:
| ':map', ':map!', ':nmap', ':vmap', ':imap', ':cmap',
| ':smap', ':xmap', ':omap', ':lmap', etc. do. There are
| bunch of questions on StackOverflow about different mapping
| options so I wouldn't say it's intuitive at all.
| alpaca128 wrote:
| The differences that actually matter are self
| explanatory: map is for all modes, imap for insert mode,
| nmap for normal mode and vmap for visual mode (& tmap for
| terminal mode in NeoVim). The rest can be safely ignored
| as far as I can tell.
|
| Little confession: I have no idea what e.g. the
| difference between "nmap" and "nnoremap" is. But after
| years of randomly mixing them in hundreds of bindings
| without a noticeable difference it doesn't seem to
| matter. Just use map, nmap, imap and vmap, avoid
| duplicates and everything will be fine imho.
| ptato wrote:
| I find that I never want "map" functionality, so I do the
| opposite, always use "noremap".
| Omni5cience wrote:
| You're right, for most simple use cases it doesn't
| matter. But I once spent an hour on a weird bug that
| turned out to just be some plugin applying a map that I
| didn't know about and that I didn't know about map
| expansion. So I might be biased, but I think a loose
| understanding is helpful.
|
| The default behavior is to recursively expand and apply
| your mappings and "noremap" disables this recursion. For
| example if you do something like :map j k
| :map q j :noremap w j
|
| q is expanded to k, but w is expanded to j
| alpaca128 wrote:
| Thanks for this example, now I get it. It never really
| clicked for me when I read explanations on SO etc.
| apocolyps6 wrote:
| nnoremap is "non-recursive remap" since I think its
| possible to chain nmaps (`nmap A B, nmap B C` will map A
| to C)
| frederikvs wrote:
| I just have vim-angry installed. It gives me "cia" and friends,
| though without the count you mention.
|
| Sounds like treesitter will have more flexibility, but for now
| the vim-angry plugin does what I need it to :-)
| staticshock wrote:
| Seconded. vim-angry is an excellent plugin that exposes args
| as text objects.
|
| In an expression such as (foo, ba|r, baz), where | is the
| cursor, it does the following:
|
| via - (foo, |bar|, baz)
|
| vaa - (foo|, bar|, baz)
|
| vaA - (foo, |bar, |baz)
| SavantIdiot wrote:
| Aren't these features are subject to external configuration to
| behave properly? For example, C/C++ and #defines. The user has
| to configure yet _another_ file for this to work properly. If
| the build system /tree is so complicated that I can't figure
| out what the final #defs are (like building MBED programs with
| literally a thousand #defs), I end up shutting off this feature
| entirely. This kills me with VSCode & Sublime, but Eclipse
| derivatives are usually more tightly coupled. What about
| neovim?
| je42 wrote:
| treesitter was the reason why i installed the git version of
| neovim ;) it is very good. so happy with with it;)
| azinman2 wrote:
| Do you find your brain can actually work that way? My issue
| with all of these relative jump points, repeat this N times,
| etc of VIM is by the time I've calculated in my mind what the
| command should be I'd have already done it with just standard
| navigation/mark/yank/repeat. But perhaps you have galaxy brain
| ;)
| [deleted]
| konart wrote:
| plugins like https://github.com/phaazon/hop.nvim help a lot
| in cases where it may be hard to tell how to jump to point X
| ZeroGravitas wrote:
| I don't use relative jumps or N times repeats, but I do love
| moving by or dealing with semantic units of things at a time,
| whether that is a character, w/Word, quoted string, bracket
| contents, line, paragraph, function, xml tag content etc. and
| treesitter expands and standardises that across languages,
| which is nice.
| CarelessExpert wrote:
| Keep in mind, even if you don't use motions, text objects,
| and counts during interactive editing (my own repertoire is
| pretty limited for the exact reason you mention here), they
| can be enormously powerful when used with macros.
| tgb wrote:
| I never use the counts (repeat N times) except for the very
| simple 55G to go to line 55. It's not useful. But the rest of
| vim is. I think of it like a chess board. A queen has more
| moves available than a king. Does that make it harder to move
| to a certain square with the queen than with the king? Not
| really, they're both pretty straight forward, if you're not
| trying to achieve the minimal edit distance to do so. You
| make big edits when it's obvious and just do smaller edits
| when it's not. The only commands I have to plan out are
| search-and-replaces.
| diegocg wrote:
| The way vim works is actually the opposite of what your brain
| wants, this is one of the reasons why learning vim tricks is
| hard.
|
| The vim model is "action-object" (eg dw, delete word). A more
| natural, friendly and interactive model is the opposite,
| "object-action": first you select the text, your editor
| highlights the text, then you apply actions to the selection,
| one by one, and see what happens after each one. Because the
| text is highlighted beforehand and you see the effect of each
| action in real time, building chains of commands is much
| easier and friendly for novices. If you make a mistake, you
| see its effects and correct it immediately. In vim you have
| to build the command chain beforehand and calculate in your
| head what will happen. If you memorize the commands its fine,
| but if you don't, it's painful.
|
| This "object-action" model is used by kakoune
| (https://kakoune.org/why-kakoune/why-kakoune.html), along
| with native multicursor support I have found it to be a great
| alternative after years of not being able to memorize vim
| commands. Documentation is scarcer at this point, though.
| oconnor663 wrote:
| I found that over the years, my Vim habits have naturally
| moved in an "object-action" sort of direction using visual
| mode. I think a lot of other Vim users end up doing the
| same.
|
| When I tried Kakoune for a few days, I found it difficult
| to adapt to the differences, but that's probably to be
| expected no matter what. One thing I particularly missed
| was g-v ("restore previous visual mode selection"), which I
| use constantly in Vim. There's a good chance it's doable,
| though, and I just didn't figure it out.
| meepmorp wrote:
| Are you making a general claim that the brain prefers
| object-action syntax vs action-object, or just in text
| editor commands?
| chipotle_coyote wrote:
| You've oddly crystallized why Kakoune has so far failed to
| grab me!
|
| The description you gave of the actions one takes in
| editing makes sense: in most non-modal editors, you select
| the text you want to take actions on, then choose the
| action to take. But, I can do that in literally every
| modeless editor! That's the way essentially all of them
| work.
|
| But when people write of "Vim as a text editing language"
| as many comments here do, the action -> object model --
| again, at least for me -- fits the pattern. We say "I'm
| going to the store," not "store I'm going to," unless Yoda
| we are. And, most programming languages that aren't purely
| object-oriented tend to follow a rough pattern of
| "action(parameter)". So in editors like Sublime Text (or
| VSCode or BBEdit or...) I tend to do editing in an entirely
| visual way, Vim approaches editing in a more language-based
| way, and when you describe edits in language, "[verb] the
| [noun]" is pretty natural.
| greydius wrote:
| > "[verb] the [noun]" is pretty natural
|
| For an English speaker. There are many human languages
| that put the verb at the end of clauses. Japanese is one
| example.
| 0x98 wrote:
| Lots of Asian languages have the nouns before verbs.
| cnasc wrote:
| "Go to the store" is the action and "I'm" is the object,
| so your example supports the Kakoune case not the Vim
| case
|
| (These are also English-specific justifications)
| bombela wrote:
| I tend to pick and measure a piece of wood before turning
| my saw and cutting.
|
| I say that I am cutting the wood. But I select it first
| before marking it and cutting it.
|
| I noticed that I use the visual mode of vim a lot. With
| easy motion to highlight words or other object boundaries
| to quickly jump to.
|
| I tried kakoune and liked it. But after 15y of (neo)vim
| it's hard to change. That plus how good You completeMe is
| for vim.
| bashinator wrote:
| I have an almost entirely non-visual imagination and
| internal narrative. Vi and then vim were pretty easy to
| adopt, and it's still easy for me to learn new editor-as-
| a-language functionality. I started using it in the 90s
| and only figured out the visual stuff in the past few
| years (for block editing).
| addicted wrote:
| Well, the reality is that WYSIWYG editing of all sorts is
| object oriented. You first select the object and then the
| action.
|
| So it's not clear whether being more comfortable with
| selecting an object and then performing an action on it
| is innately easier for humans, or just what we've been
| conditioned to from using word processors, spreadsheets,
| or even GUI based file explorers.
|
| But if you look at command line usage, it's the opposite.
| Every command first requires you to stare the command,
| and then the object to act on.
|
| I first type cd and then the folder I want to change
| directory to, compared to selecting the folder and then
| hitting enter/CMD+O/double clicking ont he GUI.
|
| But people who have used both the GUI and CMD line rarely
| ever find the order of operation to be a concern for
| them, so I suspect the object-verb verb-object difference
| in vim is just a matter of convenience.
| bla3 wrote:
| If your brain prefers that order, you can emulate it in vim
| by doing v-movement-action, for example viwd to first
| select an inner word and then delete it.
| b0rsuk wrote:
| I tend to do that whenever I'm unsure what my action will
| actually affect. Pressing one more key is a price I can
| pay.
| benhurmarcel wrote:
| So Kakoune is like RPN (Reverse Polish Notation), and Vim
| is like Polish Notation then?
|
| For sure any user of RPN would agree that it makes more
| sense to type the operation after the object. Not sure how
| that translates to modal text editing though.
| pera wrote:
| > The way vim works is actually the opposite of what your
| brain wants, this is one of the reasons why learning vim
| tricks is hard.
|
| Do you mean that you think "word change" instead of "change
| word"? To me this sounds like you have been programming in
| Java-like languages for too long :)
| omaranto wrote:
| Vim uses both models, it uses the object-action model in
| visual mode.
| mcepl wrote:
| Whenever you say words "natural", or "friendly" you
| actually mean "what I am used to". As the saying goes
| "Basically, the only 'intuitive' interface is the nipple.
| After that, it's all learned." (Usenet discussion about
| Apple Macintosh).
|
| So, no, I spent couple of years struggling with non-modal
| editors, where I had that feeling all the time "I have no
| idea how to do it effectively in this $EDITOR, while I know
| five keypresses which would do it for me in vim." Finally,
| I have liberated myself and switched back to vim.
| b0rsuk wrote:
| Before I finished reading your first sentence, I knew you
| are a Kakoune evangelist.
|
| object-action _may_ be a more natural order in some
| languages. I use a language which permits both. So I think
| you 're overstating how much of a deal it is. That said,
| Kakoune has controversial design choices in a couple of
| areas: * no explicit select mode means not
| only you're selecting text all the time as you move your
| cursor (which can be annoying). More importantly, it means
| there are very few keys left on the keyboard for user
| defined commands. This comes up all the time on the forums
| whenever someone asks for a new function or an unused
| leader key. "Fewer modes" is not a virtue in itself,
| because modes have other benefits like taking the weight
| off keyboard. * Shell as a scripting language.
| Really. It's completely awful for maintainability. *
| I continue to argue that multi-cursors are a poor man's
| search&replace. It doesn't show off-screen matches by
| default, so you don't know if you're matching anything off-
| screen or not.
|
| There are Kakoune features I like very much, for example
| improved integration with commandline utilities. You can
| more easily use them to process the text inside editor.
| SkyMarshal wrote:
| For many commands you'll only have to make that calculation
| once, and will remember it going forward. Only commands that
| are extremely rarely used you may forget and have to
| reconstruct with the calculation again later.
| dkersten wrote:
| I got relatively good at vim N times counting some years back
| (but forgotten it now as I don't use vim as much these days).
| It was a practice thing. I made a point to never repeat a
| command more than twice and after a while it became second
| nature. I even got really good at guessing how many lines
| away things were (but nowadays I just use relative line
| numbers).
|
| I never became fully fluent, but I also didn't try too hard
| over the "don't repeat commands" thing. And I got lazy after
| about a year (but also used other editors a lot more, due to
| team members using them and such) and over time lost the
| ability. Some day perhaps I'll make a point to learn again,
| but for now I mostly use VSCode without vim mode...
| malwrar wrote:
| Like vim in general it's not natural, but with practice you
| slowly start to pick up muscle memory around it. I try to
| shoot for easy-to-eyeball tricks, a good one is jumping to
| the place you want to edit with f + the first char. If
| there's duplicates in between, you can use ; to go to the
| next occurrence of the char on that line. There's plenty of
| other tricks like that that, in aggregate, makes it feel like
| you're talking to your text editor vs leaving home row to
| click stuff.
| discardable_dan wrote:
| I believe integrating visual mode into your usage flow can
| help with this a lot.
| knuthsat wrote:
| Yeah, just recently I had to edit text like this
| 'name1', 'name2', 'name3',
|
| to: 'name1': Enum.Name1, 'name2':
| Enum.Name2, 'name3': Enum.Name3,
|
| by the time I figured out a sequence of keyboard commands I'm
| pretty sure I could have multicursored it pretty easily, go
| to name1, create 2 cursors, select word & copy, start typing
| : Enum., paste selected word, select word, capitalize, type ,
|
| In vim it was something like qdyi'f,i: Enum.<Esc>pbvlUq and
| then repeat macro.
|
| I found it very slow to even recall.
|
| For some reason the multicursor solution feels faster to me
| most times.
| br3akaway wrote:
| Text like that should work well with block selection/block
| insert mode.
| [deleted]
| mFixman wrote:
| This looks like the sort of thing you would intuitively
| solve with visual selection and a regex.
|
| ``` Vjj:s/\v'(.*)',/'\1': Enum.\u\1,/
|
| ```
|
| This is all just muscle memory. It seems impossible until
| you get used to it, and then it's the most natural thing in
| the world.
| ARandomerDude wrote:
| Yes! When I first came from Sublime 2 I thought Vim was
| irritatingly difficult but hoped it would be worth it.
| Now I wouldn't program without it.
| layer8 wrote:
| I would have used visual block mode to duplicate the 123
| column and insert the remaining content for all three lines
| simultaneously. If the situation is a bit more complex, I
| sometimes use regex replace applied to a line range.
| vukgr wrote:
| I'm surprised everyone's forgetting vim already has a
| proto-multicursor mode. Go into Visual Block mode (Ctrl-V)
| select all the lines then it's just A<delete ,>:
| Enum.Name0,
|
| After that you can just select it again in visual mode and
| g Ctrl-A to get the right numbers.
|
| If anything the g Ctrl-A part makes Vim way better than
| most multicursor editors.
| cassepipe wrote:
| So the second time, you're entering Visual Block mode or
| plain Visual mode? What does the g Ctrl+A do?
| vukgr wrote:
| g Ctrl-A increments all the numbers, but every instance
| gets incremented by one than the previous. First line
| would be Enum1, second Enum2, third Enum3. It's a really
| neat feature imo.
|
| Though I did make a mistake, if you selected everything
| it'd catch the name numbers too, so you'd have to go into
| visual block mode and only select the enum parts, then do
| g Ctrl-A.
|
| That said the numbers probably weren't supposed to be
| taken seriously now that I think about it.
| lelanthran wrote:
| Column editing in vim: https://youtu.be/dYDu9Hrg7yM?t=639
|
| I saw a colleague doing the same thing (turn column of
| #defines into structs in an array) with multiple cursors in
| an IDE, took him much longer.
|
| I paused to take a drag from my smoke while doing that.
| mpalmer wrote:
| For me it's been a matter of practice, and forcing myself
| to use macros for things even when I was too slow with them
| to justify it in the moment. It pays off eventually and you
| can get a nice facility with it.
|
| I also like using :g/^/norm
| $normal_commands
|
| to apply anonymous macros across all lines. It works with
| visual selections too: :'<,'>g/^/norm
| $normal_commands
|
| And naturally you can replace the ^ with any regex to
| selectively apply the macro to only lines that match!
| chousuke wrote:
| I think I would've used something like :s/'\\(.*\\)',/'\1':
| Enum.\1,/g and then ctrl-v to block-select all the first
| characters and U to uppercase them.
|
| Vi's not always about finding the most efficient way to do
| something, but having a composable language to do tricks
| like these comfortably builds up into your own dialect over
| time.
| heatmiser wrote:
| I'm often fallback on the sed match-replace strategy for
| things like this.
| addicted wrote:
| Or, you could have hit qt, recorded your commands for the
| first change, and then replicated it for every other line
| with a simple @t, instead of redoing all the changes each
| time.
|
| You don't have to learn command. You simply need to know
| how to edit with VIM.
|
| And multi cursors only work for tabular data. The macro
| recordings can work for the entire document where you call
| a macro on a word/regex you searched for, for example.
| continuational wrote:
| Nope, you can do find > select all to get multiple
| selections and edit those simultaneously.
| ThatGeoGuy wrote:
| This can be done in (neo)vim too, and with a bit better
| precision and less typing.
|
| :g/<regex>/<command>
|
| is the general form for [g]rabbing lines that match a
| regex and applying a command over them. You can also
| chain the command:
|
| :g/<regex1>/g/<regex2>/<command>
|
| I'll admit this isn't exactly something you intuit as
| easily as a drop-down menu, but (neo)vim does have tools
| for all these things out of the box.
| michaelmior wrote:
| > multi cursors only work for tabular data
|
| There are several plugins which allow for more complex
| use of multiple cursors.
|
| * https://github.com/mg979/vim-visual-multi
|
| * https://github.com/terryma/vim-multiple-cursors
| Scarbutt wrote:
| Multiple cursors is for quick small editing tasks where
| you don't bother with a macro.
| knuthsat wrote:
| I did record it with qd...q and repeated it with @d @@
| isaacremuant wrote:
| Visual select and normal@t (assuming you saved it in t)
| is a good way to do it once for every line.
| devnonymous wrote:
| I always find it strange that people recommend a
| different letter for the register when recommending
| macros. Why not just use `qq` and `@q` (with the added
| advantage that clearing the register is `qqq`) ?
| curriculum wrote:
| No galaxy brain here ;)
|
| I generally don't use counts. If I want to go down a few
| lines, I don't count the number of lines and use 4j or
| whatever, I instead use / to search for the exact place I
| want to move to. This feels more natural and preserves the
| jump-list, so I can ctrl-o back to where I was.
|
| Same if I want to delete a few words. I don't count how many
| I want to delete and do 4daw, instead I do daw and press .
| until I've deleted everything I want gone.
|
| And I make heavy use of text objects when available. If I
| want to move to the next function, I use the keybinding for
| that instead of searching or counting lines.
| anon946 wrote:
| I just use a fixed count, like 5j5j5j or whatever to get me
| close, then jjj or whatever.
| bombela wrote:
| Try the plugin easy motion. It changed my life.
| vulcan01 wrote:
| Instead of counting, you can use :set relativenumber
| (vim/neovim builtin) to quickly see how far away lines are.
|
| (see https://jeffkreeftmeijer.com/vim-number/)
| curriculum wrote:
| In my opinion the real downside of using <count>j and
| <count>k to move isn't the counting part, it's the fact
| that <count>k isn't a jump. That means it doesn't go into
| the jump list.
| tjdevries wrote:
| You can do something like this:
|
| ``` " Does: " For wrapped lines, does gj/gk " For large
| jumps, adds a spot on the jump list function!
| tj#jump_direction(letter) let jump_count = v:count
| if jump_count == 0 call execute(printf('normal!
| g%s', a:letter)) return endif if
| jump_count > 5 call execute("normal! m'")
| endif call execute(printf('normal! %d%s',
| jump_count, a:letter))
|
| endfunction ```
|
| and map j and k to this
| nobleach wrote:
| I tried to get into that for awhile. I tend to look at
| the line number where I want to jump, and do <number>gg
| instead. It has the benefit of allowing me to look at a
| file and get an idea of what's on lines 400 through 425
| (for example).
| dundarious wrote:
| For me, learning about . was what made learning many of
| (neo)vim's motions and text objects worthwhile. I use .
| constantly.
| mFixman wrote:
| You could ask the same question to anyone who touch types.
|
| Muscle memory is a marvellous thing.
| alpaca128 wrote:
| I'm excited about it because Vim's usual syntax highlighting is
| rather fragile. As far as I understand it Vim does the
| highlighting in the same thread, and to ensure good performance
| it enforces a time limit for the file parsing. In larger files
| this frequently leads to weirdly flickering highlighting when
| scrolling.
|
| Going from that to actual syntax parsing is a dream come true.
| bisby wrote:
| That explains a lot. I often have a syntax highlighting quirk
| where it thinks that a fold has an open quotation mark in it.
| And will highlight everything below the fold as if it's a
| part of a string. I unfold, and clears it all up. but it's
| annoying in the moment.
|
| I look forward to all of this
| alpaca128 wrote:
| You can often fix it with `:syntax sync fromstart`, but
| Vim's syntax highlighting just keeps being a bit weird.
| kbenson wrote:
| I added 'autocmd BufEnter * syntax sync minlines=4000' to
| my .vimrc to make it buffer more of large files
| initially, so it gets less confused when you reopen a
| file and it resumes at a prior location deep inside and
| has no syntax highlighting.
|
| I guess fromstart would work as well, but is probably
| best manually run like you do so a very large file
| doesn't bring the system to a halt.
| nucleardog wrote:
| I usually just keep space bound along the lines of:
| :noremap <silent> <Space> :silent noh <Bar>echo<cr>:syn
| sync fromstart<cr>
|
| This recalculates syntax highlighting as well as removes
| highlighting on search results/etc.
|
| Basically, whenever stuff "looks weird", just mash space
| in normal mode and it fixes it. The fact that I have this
| bound to something like space should tell you how often I
| end up using it. :)
| ampdepolymerase wrote:
| I just wish Vim had proper S-expression structural editing
| support. Many editors have vim support but very few have
| smartparens/paredit with good integration. If Vim can extend
| its language to include some basic structural editing, then
| writing any type of tag based code e.g. JSX would become much
| more pleasant. For example in VS Code's Flutter plugin there is
| support for "delete surrounding widget" and "wrap child widget
| in new widget". They just need better keybinding integration.
| emidln wrote:
| vim-sexp is very very good and IMO better than
| smartparens/paredit. I'm not a fan of the paredit-style
| keybindings by default, but the way it integrates into vim's
| model is IMO perfect.
| ampdepolymerase wrote:
| But it is not supported in other editors (VS Code, Intellij
| etc.), it is not like vim-surround or easymotion where
| almost every major third-party vim implementation supports
| it.
| SpaceNugget wrote:
| Vim uses text objects for that kind of thing, t being the tag
| text object. `dat` deletes the JSX tag enclosing the cursor,
| `cit` deletes the contents of the tag and leaves you in
| insert mode, etc. Matchit (included in neovim) can also be
| configured to have % match tags as well as the default
| brackets/parens. LSP text objects are also available for more
| language specific structural editing.
| jarbus wrote:
| What treesitter module does this fall under? I'm having a hard
| time finding this in the documentation. Or do users have to add
| this functionality themselves? Are there reference
| implementations for what you are describing?
| b3morales wrote:
| Right, Treesitter just gives the client program a syntax
| tree; it will be up to Neovim to map that to editing
| commands. (And the fidelity will depend on the quality of the
| specific language's Treesitter parser.)
| mjlbach wrote:
| Have you tried https://github.com/nvim-treesitter/nvim-
| treesitter-textobjec...?
| curriculum wrote:
| Not yet! I just moved to 0.5 this weekend. But thanks for the
| link!
| p2hari wrote:
| From this knowledgeable crowd I would like to know how does this
| compare with spaceVim. For somebody coming new into vim, what
| would be the right one.
| salmo wrote:
| I started using neovim when it had async and vim would hang. I
| think vim maybe caught up here, but I found I lost nothing in the
| move and the snappiness hooked me. I just haven't switched back.
|
| The items here are really exciting.
|
| VSCode is fine. I use IntelliJ sometimes for larger shared
| projects. Both I setup with their vim plugins for keybindings
| because I think in 'vi', but it's not 1:1. I usually can't do
| things like '!!sh' I have habits for.
|
| I have a smattering of plugins that cover most of my language
| needs, but it would nice to have that more on-par with an IDE or
| whatever weird space VSCode sits in between an IDE and a text-
| editor.
| varbhat wrote:
| Neovim 0.5 is awesome. It has native LSP support, Lua
| configuration support that it feels like true revolution over
| past versions.
|
| But, getting into optimal setup in neovim/vim involves lot of
| configuration. Here is mine if you want to refer:
|
| https://github.com/varbhat/dotfiles/tree/main/dot_config/nvi...
| mjlbach wrote:
| I don't agree that it requires a lot of configuration. Here is
| the "starter" configuration (~280 lines) that I made for
| helping debug user issues with the built-in language server
| client:
|
| https://github.com/mjlbach/defaults.nvim
| comma_at wrote:
| You think 280loc as a starter is not much?
| mjlbach wrote:
| Sure, although this is fairly "batteries included". Very
| rough numbers:
|
| - 34 lines to set up plugin manager/install plugins
|
| - 43 for keybinds
|
| - 35 for documentation
|
| - 50 for autocompletion
|
| - 20 for customizing one language server for plugin
| development (sumneko)
|
| It adds up for sure, and neovim/vim/emacs are not ever
| likely going to be as plug & play as vscode/intellij, but I
| would argue the target user for vim/neovim/emacs is someone
| who wants more customization, which is almost always going
| to mean the configuration is more verbose.
|
| If you have concrete suggestions on cutting down this
| config in particular, you can file an issue/PR. The main
| reason I created this, was because we (core neovim team)
| get a lot of "I just want something that works" type
| feedback (which to many includes autocompletion and default
| keybinds, which are almost 1/3 of the config)
| threatofrain wrote:
| VSC has tons of customizations available, perhaps even
| beating Vim in the number of exposed configurations. The
| problem with Vim configurations is that a lot of them
| feel obvious, and the ergonomics of dealing with configs
| is painful and frequently calls you to reference outside
| material.
| mjlbach wrote:
| I'm not sure I'd say that it beats vim/neovim, but I
| agree with your point about ergonomics. I would say the
| vim manual is a fantastic resource, I've never felt the
| need to reference outside material.
|
| Neovim has already integrated many of the "obvious
| defaults" (see :help nvim-defaults), but if you're a user
| and feel that something is missed you should file an
| issue.
|
| I personally don't mind that the defaults may not be what
| I'd like, as once they are set, I spend very little time
| modifying my system configuration. I realize this can be
| a barrier to new users though.
| dorian-graph wrote:
| > But, getting into optimal setup in neovim/vim involves lot of
| configuration.
|
| I haven't found this to be true. I've basically copied the
| configs from READMEs and have everything working.
| throwaway894345 wrote:
| I'm with the parent. I have to copy and paste all of these
| different little snippets (in the arcane viml language,
| although now maybe I can configure with kia?) and annotate
| what they do, and sometimes they compose poorly and other
| times they don't work at all. Many plugins are only available
| via some of the package managers do you have to use several
| package managers with their own conventions.
|
| Honestly the thing I like best about vim are the keybindings,
| and while many other editors try to reproduce them, they
| rarely get it right. The only one I've found that comes close
| enough is vs code and it doesn't search properly (case
| insensitive) and it uses a sane regex language instead of
| whatever regex language vim uses.
|
| I specifically dislike the vim philosophy that defaults
| should be insane and the user should have to configure things
| to their liking with all of the expertise that entails. VS
| code does a much better job in this regard (though it has its
| own quirks).
| lacksconfidence wrote:
| I think the vim philosophy is slightly different. The vim
| philosophy is if it worked yesterday, it works today. This
| means, for the most part but not exclusively, not making
| breaking changes. This means, by proxy, that the defaults
| were set a long time ago and are unlikely to change. It's a
| difference in who they consider the most important users,
| the ones already using it or the new users that might use
| it in the future.
| throwaway894345 wrote:
| I think those of us who have been vim users for a while
| can still appreciate intuitive design. :) Moreover, this
| could be entirely backwards compatible--you could have a
| single boolean "sane-defaults" flag which defaults to
| false (for our dear legacy users) but which new users can
| override.
| necrotic_comp wrote:
| Exactly. This lets configurations accrete over time and
| ultimately get to a place where you don't have to think
| about your changes and they "just work" for you.
|
| I think emacs is more likely to have breaking changes,
| but I haven't used it a terrible amount, so I can't
| really say.
| ibraheemdev wrote:
| It is awesome, but I have been running into bugs with it.
| Memory out of bounds errors, freezing when my project is
| misconfigured, it doesn't feel stable yet. Is that just me?
| mjlbach wrote:
| Have you filed your issues on our issue tracker
| (neovim/neovim, not neovim/nvim-lspconfig)? If not, please
| do! I haven't run into these issue myself, but if you can
| provide a minimal repro happy to take a look.
| revscat wrote:
| I think it may just be you. I've been using nightly builds
| for months now, and haven't seen what you describe even once.
| sigzero wrote:
| What's a good x-platform GUI for it?
| varbhat wrote:
| 1) Terminal
|
| 2) Neovide :
|
| https://github.com/Kethku/neovide
|
| 3) Neovim-Qt :
|
| https://github.com/equalsraf/neovim-qt
| pdimitar wrote:
| Neovide looks amazing, thanks for linking it!
| yakubin wrote:
| Your comment triggers my OCD in 2-3 different ways:
|
| 1. First you start numbering with 1.
|
| 2. Then you start numbering with 0.
|
| 3. You provide links for all but the first element in the
| list, which, combined with my first 2 points, results in a
| juxtaposition of "2" and "0", suggesting to my subconscious
| that I missed something.
|
| Well done.
| varbhat wrote:
| Corrected Now.
| Normille wrote:
| VimR [0] is a nice OSX GUI for Neovim.
|
| FireNvim [1] is a browser plugin which embeds a Neovim
| editor window in HTML textareas
|
| [0] https://github.com/qvacua/vimr
|
| [1] https://github.com/glacambre/firenvim
| todd8 wrote:
| Thanks for making your configuration available, I want to try
| out Neovim because it's an exciting project and having
| carefully constructed configurations available as a starting
| point will make it easier. Your configuration doesn't look too
| long to me, my own Emacs configurations are much, much longer
| and not at all stable--every so often I declare Emacs
| bankruptcy and start over.
|
| Now, some off-topic musings:
|
| I switched to Emacs from vi in the 80's, and I put up with it
| for the many powerful packages it has. Lisp as a configuration
| language has served Emacs well for decades, but I've always
| been aware that it narrows the number of contributors to those
| that are comfortable with Lisp. Progress towards modernizing
| the Emacs extension language has been slow...and it will still
| be a Lisp like language (Scheme).
|
| I'm rooting for Neovim and I'd like to see a project like this
| for Emacs that would modernize it's UI, UX and underlying
| extension language. This will likely never happen while I'm
| still programming. Imagine the difficulty of recreating just
| the org-mode package!
| rajin444 wrote:
| I tried out the native LSP support few months ago and the docs
| + features for it seemed poor. I went back to coc.vim
| ibraheemdev wrote:
| The features are all there, and I found the documentation was
| pretty good. There were cases where I had to dig through help
| pages and github issues to configure things a certain way.
| mjlbach wrote:
| Have you checked it out recently? I overhauled the
| documentation twice since January. Most recently, I
| dramatically simplified the documentation based on user
| feedback, expanded the wiki pages, and created an "advanced"
| readme for power users.
| rajin444 wrote:
| I haven't! It was actually late last year I checked it out
| so I'll have to give it another shot.
| YorickPeterse wrote:
| The documentation is there, but it's a bit lacking/confusing
| here and there. It's also mostly foundational work, and you
| still need to cobble things together (either manually or
| using a plugin).
|
| With that said, you can build things quite nicely with it.
| For example, I have a custom linter setup, custom
| loclist/quickfix list formatting and populating from LSP
| data, and a bunch of other things; all using the foundational
| work coming in NeoVim 0.5.
|
| If anybody is curious, you can find my NeoVim configuration
| here: https://gitlab.com/yorickpeterse/dotfiles/-/tree/master
| /dotf...
|
| p.s. In case anybody wonders "why Lua?", for me this mostly
| comes down to this: I hate Lua, but I hate Vimscript even
| more.
| skohan wrote:
| I had the same experience maybe 6 months ago, hopefully
| having a "blessed" implementation will help/has helped this
| situation.
|
| I actually was surprised to see the state of the LSP docs in
| general. Maybe I was missing it, but all the docs I could
| find only had C# examples of the various objects. I was
| surprised I couldn't find an exhaustive list of the JSON
| documents and JSON-RPC endpoints which make up the standard.
| becquerel wrote:
| As a novice to vim, I found neovim really nice. You can download
| it and it Just Works, pretty much, with windowed version and
| sensible defaults. If you're interested in vim but found it hard
| to get into, I recommend it.
| jvanderbot wrote:
| The positive transformation of Microsoft is most apparent when
| they are pulling forward old dreadnoughts of Linux/Unix like
| [Neo]Vim.
|
| Here, LSP and VSCode set the bar pretty high. I'm glad to see a
| healthy ecosystem thriving when Windows, WSL, Linux, and various
| tools start mixing and sharing.
| dangom wrote:
| Does neovim, or vim for that matter, offer any out of the box
| support for remote work like Emacs has with tramp-mode?
|
| Asking because maybe it's time to try NeoVim out, but it'd be a
| limitation for my work if I had to go through extra hops for
| editing remote files and running remote jupyter kernels.
|
| I suppose it does, so I'd be grateful if vimmers out there would
| share their favorite solutions.
| e12e wrote:
| > Does neovim, or vim for that matter, offer any out of the box
| support for remote work like Emacs has with tramp-mode?
|
| Not really like tramp mode (doesn't magically (s)ftp files
| around), but there's headless and tcp connect support, like:
|
| https://github.com/Kethku/neovide#remote-tcp-support
|
| https://neovim.io/doc/user/remote.html
|
| However - this looks closer? "Seamlessly editing remote files
| in (Neo)Vim with Netrw and scp"
| https://gist.github.com/RRethy/ad8a9a3b1112a48226ec3336fa981...
| Scarbutt wrote:
| Open Vim or Emacs on the remote server. A strength about those
| two is they work from the terminal.
| dangom wrote:
| I like to mix and match local and remote files in the same
| Emacs frame. I know they work remotely, but that'd require me
| to configure them in the remote - and sometimes that's a pain
| because Emacs versions differ, or because the keybindings I
| press in the terminal sometimes coincide with Emacs commands.
| skrtskrt wrote:
| I switched from vim to neovim because I thought I needed to to
| use coc.nvim - turns out I didn't need to, coc.nvim works in vim
| 8+
|
| As a neovim user who is just having neovim load my vimrc -
| nothing neovim specific -, I don't see a huge difference. Are
| there features I am missing out on?
|
| I do like the idea of having everything in my vimrc so I could
| still use it with vim on a server if needed.
| typon wrote:
| In general, nvim has better defaults than vim. You can simulate
| an out of the box nvim experience by adding a few lines to your
| .vimrc.
|
| Besides that, I think the only big difference I've noticed is
| the nvim exclusive plugins.
| kzrdude wrote:
| nvim should find a way to commit to "good defaults" in a way
| that updates those defaults in the future, when nvim
| develops. So that it's not stuck in the hole that Vim is in,
| only a bit further along.
| simias wrote:
| I found that nvim had generally better performance. That was my
| main draw originally, despite not using many plugins I often
| found Vim chugging on large files with things like syntax
| highlighting. FZF is also significantly snappier on nvim in my
| experience, or at least it was when I made the switch.
| pl-94 wrote:
| I am an nvim user. I still have everything on my vimrc but I
| installed nvim on all of my servers. Some plugins do not work
| on vim8+ (telescope.vim e.g.)
| kevinoid wrote:
| I still use both, with a shared vimrc. The biggest advantage of
| neovim for me is support for the clipboard in Wayland.[1] There
| are workarounds for vim (vim-fakeclip[2] is the best I found)
| but they have many limitations which can be frustrating.
|
| [1]: https://github.com/vim/vim/issues/5157
|
| [2]: https://github.com/kana/vim-fakeclip
| pta2002 wrote:
| One thing I immediately noticed is how much better neovim's
| built in terminal is when compared to vim! Vim's seems very
| barebones, afaik doesn't even support 24 bit color. Neovim
| meanwhile uses libvte IIRC which means it's a full on terminal
| emulator. I can run nvim inside nvim inside nvim and everything
| still works just fine!
| gorjusborg wrote:
| I reluctantly tried neovim at first. I didn't like it as much
| as vim at the time, mostly due to plugin compatibility and some
| bugs (this was a while ago).
|
| I permanently moved to neovim because of the forward looking
| vision and community around it.
| ybbond wrote:
| when you do
|
| ```:s%/search term/replacement ```
|
| it will load preview window showing the replacements you'd
| implement. neat feature I always like
| adamors wrote:
| I've been using Neovim for years and never knew this. Really
| cool, thanks!
|
| It's set by `set inccommand=nosplit`
| themadsens wrote:
| Vertical wildmenu (as opposed to horizontal in the statusline)
| is the most recent nvim goodie. Also clipboard integration via
| providers is nice for remote work (:helpgrep lemonade).
|
| Made the switch originally because of swifter highlighting,
| less display issues and the builtin terminal.
|
| My setup also still basically works with vim too
| luxurytent wrote:
| I've been on neovim nightly for about 6 months now, coding in it
| full time. Can't recommend it enough!
|
| Use all the plugins highlighted here except telescope, which I've
| been holding off on from fears of slowness, but maybe I'll take
| the plunge this weekend and test it on some of the larger repos I
| work in :)
| martin1975 wrote:
| I just came to see how many search hits for "emacs" I will see in
| the comments, excluding mine, it's 65 :).
| pratio wrote:
| I've been using Neovim for a while now and it's amazing. I love
| the effort and thought that has gone into the project. The plugin
| manager is such a treat to use. Anyone who used to use vim or
| found it lacking or difficult to setup, I urge to give Neovim a
| try. Thanks to everyone involved in the project.
| yewenjie wrote:
| AFAIK Neovim 0.5 uses tree-sitter. Is there any effort to
| integrate tree-sitter with Emacs in an easy way?
| ywei3410 wrote:
| Sort of.
|
| The integration needs to be done per-language, though helper
| packages like emacs-tree-sitter [1] exist. Afaik, C# mode
| currently uses it [2] though I'm not sure whether any other
| languages use it yet.
|
| [1] https://github.com/ubolonton/emacs-tree-sitter [2]
| https://github.com/emacs-csharp/csharp-mode/blob/master/csha...
| fmakunbound wrote:
| Emacs already has Semantic
| https://www.gnu.org/software/emacs/manual/html_mono/semantic...
| which seems similar in functionality. It's been around for ages
| but more recently it has become part of Emacs proper.
| cjohansson wrote:
| Semantic is used less and less I would say, there is not
| enough people involved in keeping it and it's grammars
| updated, it also suffers lack of asychronicity. Tree-sitter
| and LSP has the advantage of re-using code for multiple
| editors
| b3morales wrote:
| Semantic is pretty cool. The advantage that Treesitter has
| (shared with LSP servers) is that it's client-agnostic. So
| while no one besides fellow Emacs users are going to hack on
| the Semantic parser for a given language, Treesitter can
| potentially draw help from users of any editor, or even
| people doing other things like building analysis tools.
| jgb1984 wrote:
| I'm a long time (20+ years) vim user, and neovim doesn't fit my
| use case. I've tried it, most recently today, to have a look at
| LSP and treesitter. Treesitter added different syntax colors, but
| the result wasn't necessarily better than vanilla vim. More like
| an overly decorated christmas tree. LSP and other "make it into
| an IDE" I usually turn off after a few minutes, it's more of a
| hindrance than a help. I mainly code in python and don't care for
| intellisense.
|
| Other than that, there's 3 real showstoppers for me:
|
| - the obsession with Lua (I personally don't like Lua much, and
| even to configure treesitter I have to inject little snippets of
| lua code into my .vimrc). You've got people even trying to
| rewrite their entire .vimrc in lua, which results in an
| enormously verbose mess if you ask me. Lua is also what drives
| the vim and neovim communities further apart.
|
| - they removed gvim (which is what I use in most cases). There is
| no comparable third party GUI like gvim available. They're all
| either abandoned, unstable or simply very different with lots of
| bling and gimmicks.
|
| - neovim feels less stable than vim. It just crashed on me a few
| minutes ago when I was trying to configure treesitter. I copy
| pasted the necessary snippet in my .vimrc and neovim crashes
| until I take it out. In the 20 years I use vim, I don't think
| I've ever had it crash on me. Neovim seems more of a "move fast &
| break things" development model, but I write code for a living so
| I prefer the rock solid stability of vim.
|
| So I'll stay firmly in the vim camp. I appreciate neovim for what
| it did (kickstart the vim development, which was stagnating at a
| certain point) but I wished they had re-merged soon after that
| initial goal was met. Now the communities have split and are
| drifting ever farther apart. Soon with vimscript9 plugins on one
| side and lua plugins on the other, the spaghetti will be even
| harder to untangle.
| e12e wrote:
| > they removed gvim (which is what I use in most cases). There
| is no comparable third party GUI like gvim available. They're
| all either abandoned, unstable or simply very different with
| lots of bling and gimmicks.
|
| I'm not sure I understand what you're missing from neovim-qt?
|
| https://github.com/equalsraf/neovim-qt
|
| I suppose maybe we have diffuse cases - but I'm fairly certain
| I'm running qt neovim, and not nvim in a terminal - and I'm not
| aware of any issues?
| nobleach wrote:
| Yeah, I've used Vim since the mid-nineties too. At first it was
| my "edit a config file in my RedHat 5.2" tool. Later, the more
| and more actual software dev I did, it became a daily driver. I
| am pretty sold on the "Vim way".
|
| I have a workflow. It's hard for me to adopt new things into my
| worflow because my workflow works so well. I finally made the
| switch to NeoVim just over a year ago because I wanted to see
| what the fuss was about. I have to say, it's now firmly
| entrenched in my workflow. It's to the point where I'd be
| annoyed if I had to go back.
|
| The one sticky point about your post that I wanted to
| highlight:
|
| >I personally don't like Lua much
|
| I can say that almost anything is better than VimScript... I
| hate every moment I have to mess around with it. The hardest
| part is, I don't use it for anything else so every time I dive
| in, I have to remember how it works. At least Lua is a
| multipurpose language and documentation/help are plentiful.
|
| But, I get that the whole intellisense, popup windows, bling...
| those things are not for everyone. If they don't enhance your
| workflow, then you're never going to desire them.
| tjdevries wrote:
| I'll ignore the other parts I disagree with in this post, since
| it's cool to have different views but I just wanted to post
| that it may someday be possible to run vim9script plugins in
| neovim :)
|
| I'm working on a project that might allow at least 90% or
| higher compat here: https://github.com/tjdevries/vim9jit
|
| Of course, vim9script isn't complete yet, so the spec isn't all
| the way done, but it may someday be possible to run them in
| neovim.
|
| Additionally, if someone actually just wanted to port all the C
| code to run or has some other way to make vim9script run,
| neovim is not opposed to making that happen.
| drbojingle wrote:
| I agree with you when it comes to basic config. Vimscript is
| better for setting options, basic mappings and events. Anything
| more complex then that is a pita in vimscript.
| ViViDboarder wrote:
| Just a note on stability, you reference Neovim crashing when
| setting up Treesitter. That means you're using an unstable
| version of Neovim as Treesitter and Lua configuration are in
| the unreleased version 0.5.
|
| I've been using only stable Vim and Neovim and have not had
| either of them crash on me that I can remember.
| felixr wrote:
| > Treesitter added different syntax colors, but the result
| wasn't necessarily better than vanilla vim. More like an overly
| decorated christmas tree.
|
| The problem here is that people use treesitter to add more
| colours to distinguish more types of tokens. For me this is too
| much and the colours lose their meaning. I recently switched to
| a colour scheme that only changes the colours for strings,
| numbers and comments. Treesitter allowed be to add very
| targeted minimal highlighting. For example, I know highlight
| the first line of a function definition. This makes it very
| easy to see function scopes.
|
| We don't really need more highlighting, but meaningful
| highlighting. With treesitter you can do both.
| lefrenchy wrote:
| I see a lot of hate on Lua here. Anecdotal but I never wrote any
| plugins in vimscript. Since moving to Lua a week ago i've already
| written one, and will continue to where I find a use case.
|
| Vimscript sucks, using Lua will make it easier for people to
| contribute I think.
| tjdevries wrote:
| That's great to hear :) As you write more plugins, make sure to
| submit ideas to Neovim core about how to make Lua even easier
| and/or more integrated!
| SPBS wrote:
| I use nvim in the terminal and gvim/macvim on the desktop. I
| don't like how the nvim community seems to be throwing themselves
| wholeheartedly into lua and lua-only plugins (vimscript plugins
| are better because they work with both vim and neovim). Switching
| to init.lua also means losing all compatibility with vim, and I
| cannot fathom why people would want to do that considering that
| there is nothing that init.vim cannot already do.
|
| I also don't like how there looks to be an upcoming split in the
| plugin community when Vimscript 9 releases and the neovim
| community will ignore it while plugin authors in the vim camp
| (e.g tpope) may start moving their plugins over to it.
|
| That said, the built-in LSP for nvim is very good thing and I
| plan to migrate away from the node-dependent coc.nvim once nvim
| 0.5 releases.
| simias wrote:
| Vimscript is terrible though. I switched from Emacs to Vim (and
| later, neovim) last year and the shock of going from elisp to
| vimscript was intense.
|
| I even contributed some small patches to a couple of vim
| plugins which meant writing and debugging vimscript, I hated
| every second of it.
|
| I'm not a huge fan of Lua either mind you, but I'll take it any
| day of the week over vimscript.
| jrop wrote:
| I've always wanted to write Vim plugins, and as soon as 0.5
| hits stable, I'm looking forward to trying! I won't touch
| VimScript with a 10-foot pole, and I write code for a living.
| It's not worth my time, and it does not commute to other
| things that I'd rather be spending my time coding.
| overgard wrote:
| How many people realistically are willing to write vimscript
| plugins, vs how many people realistically are willing to write
| Lua? I know personally, after wresting with vimscript for a
| couple of days I'd never touch it again, but Lua is nice.
| sigzero wrote:
| New vimscript plugins are created constantly. So that isn't a
| good argument metric.
| overgard wrote:
| In a vacuum where there was no need for legacy vim support
| (lets say vim integrated lua), I can't imagine anyone but a
| small minority preferring vimscript over lua. My argument
| isn't that nobody programs vimscript, it's that hardly
| anyone does it by choice.
| fouric wrote:
| > vimscript plugins are better because they work with both vim
| and neovim
|
| I think you mean "vimscript plugins are better _for plugin
| adoption_ because they work with both vim and neovim ".
|
| From the language-design, performance, documentation,
| robustness/general codebase quality, and total number of users
| perspectives, Lua is overwhelmingly better than vimscript.
|
| > I cannot fathom why people would want to do that considering
| that there is nothing that init.vim cannot already do
|
| Ahh, yes, the Turing-equivalence fallacy: "technology A is
| theoretically capable of doing everything that B does,
| therefore they're equivalent". Brainfuck and Python are Turing-
| equivalent, and yet nobody would seriously argue that they're
| interchangeable.
|
| Design matters.
| jeppesen-io wrote:
| > I don't like how the nvim community seems to be throwing
| themselves wholeheartedly into lua and lua-only plugins
| (vimscript plugins are better because they work with both vim
| and neovim)
|
| How many decades do we continue to use, support and maintain a
| terrible DSL like vimscript? I personally don't want to be
| using vimscript in 2030.
|
| It's time to move on. Lua is a solid choice
| tharne wrote:
| > I don't like how the nvim community seems to be throwing
| themselves wholeheartedly into lua and lua-only plugins
|
| The transition to lua can't come soon enough, imho. The biggest
| downside to vim is vimscript. Lua is a delightful little
| language and the sooner it replaces vimscript the better.
| wirrbel wrote:
| There is no other credible alternative to betting on lua.
|
| vim script is too limited and there are no other options,
| really.
|
| Python plugins are a hassle.
| oblio wrote:
| The thing is, Vimscript sucks. Using a more mainstream language
| would be great for a modern advanced editor.
|
| Vim has a ton of Vimscript plugins but I wonder how long it
| will take the Neovim community to replicate most of their
| functionality in Lua. I'd guess that not that long.
| the_jeremy wrote:
| I spent 10 hours learning enough vimscript to make a command
| to check if a line is commented, comment it if not, or
| uncomment if it is, be able to handle multiple filetype and
| comment chars, and be able to handle proper indentation and
| multi-line selection.
|
| I have to imagine it would be simpler in other languages.
| Vimscript is hard.
| psalminen wrote:
| Out of curiosity, does your's have any benefits over
| NERDCommenter?
| the_jeremy wrote:
| I'm sure mine's strictly worse. It was written when I was
| working in an environment where it was easier to spend 10
| hours on something than it was to get permission / access
| to download vim plugins from the internet.
| revscat wrote:
| Gov?
| the_jeremy wrote:
| government contractor, yeah. It is insane how much effort
| there is put into getting butts in chairs for the right
| number of hours and how little effort goes to actually
| building something useful.
| johnchristopher wrote:
| Now that calls for story time.
| addicted wrote:
| I'm pretty sure that the primary reason we don't have more
| VIM plugins, despite many more emacs users, is vimscript
| being terrible.
|
| If vim had a more usable scripting language it would have
| easily surpassed emacs in plugins and more importantly, since
| plugins would have been more popular, vim would have been
| developed in a way to make it more extensible and nvim
| wouldn't even be needed.
| coliveira wrote:
| The philosophy of vim is to be able to do a lot without the
| need for complex plugins, as opposed to emacs' world view.
| That's why vim script is good only for simple scripting
| tasks.
|
| I think emacs having more plugins is a consequence of its
| design and philosophy, not the extension language itself.
| After all, emacs lisp is not the best language in the world
| and only a small group really knows it beyond the basics.
| jrop wrote:
| I think you are correct. I think this is why certain Vim
| "demigods" have arisen (aka tpope). Only a few take the
| time to learn VimScript. In my humble opinion, when I took
| the time to try and learn it a while back, I ascertained
| that it was not worth my time.
|
| Having never written a line of Lua in my life, on the other
| hand, I was able to pick it up in exponentially less time
| than the small bit of VimScript that I "know". Lua is not a
| fantastic language, but it is infinitely better than
| VimScript.
| coliveira wrote:
| There is a point when it doesn't make any difference if the
| language sucks or not. What matters is if it is capable. You
| can say the same about most successful languages: C sucks,
| shell script sucks, eLisp sucks, LaTeX sucks, but they're all
| there and will continue to be because they have been capable
| of support the communities for which they were designed.
|
| Now, you can freely dream about the perfect extension
| language for UNIX, or vi, or TeX, or emacs, but it won't make
| any difference because nobody will move from something that
| works to an unproven extension language just because some
| people (usually the minority) feel that it is a more
| comfortable language for them.
| redrobein wrote:
| I recommend checking out gui frontends for nvim on desktop.
| I've been using neovide[1] for a while now and it's decent. I
| also found out that you can use nvim as a backend with the
| vscode-vim plugin which will load your nvim config and scripts.
|
| [1] https://github.com/Kethku/neovide
| YorickPeterse wrote:
| > I also don't like how there looks to be an upcoming split in
| the plugin community when Vimscript 9 releases and the neovim
| community will ignore it while plugin authors in the vim camp
| (e.g tpope) may start moving their plugins over to it.
|
| Honestly Vimscript 9 always felt like a serious case of "not
| invented here". Bram could have easily chosen one of many
| existing languages, but instead decided to take Vimscript and
| make it even more bizarre (this was even more so the case at
| first as IIRC block delimiters for example were really odd).
|
| Setting that aside, you could also argue that people moving
| their Vimscript plugins over to Vimscript 9 is a problem on
| their end because it makes the plugins incompatible with
| NeoVim. In other words, the argument is basically silly.
| drbojingle wrote:
| Replacing init.vim with init.lua is, imo, a mistake. Lua is not
| a config language. I'd sooner use bash. Once you start writing
| functions tho lua feels more sane.
| packetlost wrote:
| As someone who maintains a vimscript plugin... HAHAHAHAHAHAHA
|
| There's API differences between vim8 and neovim that make it a
| pain to do certain tasks on both (UI manipulation or anything
| with asynchronous work). Supporting both in the same plugin is
| annoying. The split is already there and it's only going to get
| worse, so might as well go with a language that doesn't suck to
| write. I think upstream vim is the one needing to catch up.
| Vimscript sucks to write and maintain.
| tjdevries wrote:
| It always feels really nice knowing that people are getting
| excited by your work. Thanks for the shoutout!
|
| (I'm tjdevries)
|
| Happy to answer any nvim questions while I'm here.
| yanis_t wrote:
| When is it going to get released?
| tjdevries wrote:
| https://twitter.com/TeejDeVries/status/1396881477263036417 ;)
|
| (I hope you are in on the meme, otherwise I am sorry for
| posting our "inside joke" response)
| joemi wrote:
| Jokes (and especially inside jokes) don't really go over
| well here on HN.
| dvk13 wrote:
| Thank you for the nice work!
| tjdevries wrote:
| My pleasure :)
| modernerd wrote:
| Is anyone in the nvim community working on unifying UI widgets
| (popovers and pickers) for eventual inclusion in nvim itself?
|
| Consistent UI for users and great UI APIs for plugin devs would
| be a nice perk.
|
| I have a couple of nvim plugins in flight and building the UI
| has been the hardest part so far. (A couple of examples:
| https://imgur.com/a/RZV2eYJ )
| tjdevries wrote:
| Yup!
|
| We want to create interfaces to make this simpler for people
| to use.
|
| One example is here: https://github.com/mjlbach/neovim-ui
| which is just in a separate repo to make it easier to work on
| rather than one huge PR.
|
| This is an extension of the ideas that I started in
| https://github.com/nvim-lua/popup.nvim and a few other
| places.
|
| The idea would to be to create interfaces that users, plugins
| and/or GUIs could override to provide a unified experience
| while still being customizable for users.
|
| (and as a self plug, I think we have a lot of interesting
| ideas in telescope.nvim about UI that could be upstreamed
| over time)
| powmli wrote:
| The real killer feature of Neovim is Firenvim (
| https://github.com/glacambre/firenvim ). I'm still waiting for
| somebody to do the same thing with GTK inputs and the shell
| (yeah, I know that bash and zsh support a vim mode, but it
| sucks).
| rjldev wrote:
| control + x followed by control + e will drop you into $EDITOR
| from your shell - might do what you want
| nahuel0x wrote:
| Emacs and VSCode should follow Neovim and also use tree-sitter as
| their parsing engine, instead of manually crafting fragile
| regexes.
| ccchapman wrote:
| Have used Neovim 0.5 for quite some time now. It has been an
| incredible experience and I cannot see myself moving away. Prior
| to this I was using coc.nvim. Over the last many months, the
| Neovim community has certainly lowered the barrier to entry
| configuring LSP. There were a few times I spent way too many
| hours attempting to get everything playing well together. The
| installation process has become much more streamlined and
| beginner friendly.
| kzrdude wrote:
| Why has it been incredible?
| ccchapman wrote:
| The native LSP support is solid (auto-completion, diagnostic
| feedback) and there are a wide variety of plugin options to
| improve the experience e.g. trouble.nvim. Also, Treesitter
| syntax highlighting makes a notable difference in my
| experience. The further possibilities with TS are outlined in
| this thread. Plus the community has shown that Lua support is
| helping building a solid ecosystem surrounding the new native
| features. It's really on a different level from YCM, coc,
| ALE..
| cusx wrote:
| Does anyone have a setup for Typescript/React that works/feels
| similar to VSCode?
| ug02fast wrote:
| Spent hours over days trying to get this to work with vim/coc-
| vim. VSCode works better when working with TypeScript.
| davidkunz wrote:
| Hi, please have a look here:
| https://youtu.be/CcgO_CV3iDo?list=PLu-ydI-PCl0OEG0ZEqLRRuCrM...
| meagher wrote:
| Yup! https://github.com/tmm/dotfiles
|
| Happy to answer questions: tom@meagher.co or Twitter DM
| (@awkweb)
| ybbond wrote:
| using coc.nvim, with its extensions coc-typescript, coc-eslint,
| coc-prettier works great to me.
|
| even though there's an expected minor performance hit, it still
| faster than vscode
| CalChris wrote:
| neovim 0.5 is not quite out (but it's real close).
|
| https://github.com/neovim/neovim/milestone/19
|
| I've been using a neovim nightly along with VSC and Alexey
| Svetliakov's Neo Vim extension. His extension requires 0.5.
| dcow wrote:
| Neovim is awesome. I really hope it becomes a real successor to
| vi[m] to the point where it's integrated into server distros so
| it can be effectively the default.
| npmaile wrote:
| I just got lsp native set up last night, and I think it's great.
| It replaces a few manual steps and plugins that were necessary,
| and it seems to be pretty well integrated. I'm not sure about the
| performance or resource usage, but it feels pretty snappy.
| sriram_sun wrote:
| C++ folks, do you see any big improvement in cscope type
| navigation? I've tried ycm and a couple of others. Now settled on
| ripgrep. However, I do need a decent plugin that helps with
| finding references to a symbol and navigation back and forth in
| C++. Not finding it in nvim after several attempts. Coc+clangd
| has only added to the headache. Coc is pretty good for js and
| python though.
| mellery451 wrote:
| yes - I use coc + clangd and there is no comparison with
| cscope. The level of accuracy you get with clangd is
| significantly better than tags/cscope. The main thing you need
| to make clangd work properly is an accurate compile DB. Yes,
| you can general/coarse compile settings, but the accuracy drops
| off for a project of any size. I also suggesting staying
| reasonably up-to date with clangd releases since they are
| adding important features/fixes with each release.
| pdimitar wrote:
| NeoVIM seems like a big upgrade over a lot of editors.
|
| As a very casual Emacs user who never got excited enough for the
| "self-documenting and programmable editor" idea, VIM gets more
| appealing by the day for me. I am also using Spacemacs for a year
| or so and it's definitely better than normal Emacs. Haven't tried
| Doom Emacs and I doubt that I will, regardless of a lot of
| positive feedback.
|
| I mean, Emacs is alright but I am just not in the club of the
| people who'll use 25% of their workday chasing an Elisp error and
| maybe fix a plugin in the process. Always hated the heavy IDEs
| like Eclipse and IDEA so this led me to Emacs but I still prefer
| stuff to come semi-configured out of the box. I know that NeoVIM
| will require some love for that but I'm prepared to do it because
| it looks like much less work than Emacs.
|
| I'll try Emacs' `native-comp` branch for supposed quicker Elisp
| operation but I don't have much hope that it will help my
| grievances.
|
| Sadly, my 19 years of casual Emacs usage are coming to an end
| soon.
|
| I'm looking forward to trying NeoVIM.
| gosukiwi wrote:
| For me, Spacemacs with evil mode and Vim are quite similar, but
| I always end up going back to Vim because it's just a) way
| faster for me, and b) it integrates into my workflow better.
|
| For example, I don't want an extension to take care of git for
| me (magit), it's easier for me to just alt tab or bring a
| terminal in vim and do it there.
|
| I find Emacs users prefer to do everything in the editor, while
| I'd rather have one tool do one job. Of course what job exactly
| should a tool do is subjective, and varies from user to user :)
|
| Vim surely tales some "learning tax", new users are encouraged
| not to add every plugin they can find, instead, try to do
| things "the vim way". But that is also subjective.
|
| My experience with Vim was just make it more friendly first
| (installing things like NerdTREE and making it behave more like
| other editors I was used to), then slowly learn how to do what
| those plugins do with just vanilla vim, and see if I can either
| remove them or replace them with a more "barebones" and "vim-
| compatible" plugin.
|
| For example, I now use vim-dirvish which is like a better
| `netrw` (Vim's default file browser).
|
| I am biased of course, but I think Vim/Neovim is just great,
| and always worth checking out.
| davidkunz wrote:
| If someone is interested in a video showcasing the power of
| Neovim: https://youtu.be/CcgO_CV3iDo?list=PLu-ydI-
| PCl0OEG0ZEqLRRuCrM...
| timwaagh wrote:
| The problem with neovim is that it's often not available on
| corporate environments whereas vim usually is. But nice work
| anyways
| tharne wrote:
| You can pretty easily get around this by downloading the neovim
| appimage to your home directory and either putting it somewhere
| in your path or just creating a simple alias.
| criddell wrote:
| Offtopic, but I wish the author would add a bit of whitespace on
| the left and right sides. In my browser (Firefox) the text
| touches the outside edges and gives the impression that I need to
| horizontally scroll.
| crispgm wrote:
| Just found my post on HN. Thanks for the feedback. And i think
| i need a review my responsive codes.
| kzrdude wrote:
| It probably wasn't tested with such a narrow viewport, then.
| criddell wrote:
| It behaves oddly. If I make my window very wide, the text
| takes up a reasonable width in the center. Then as I drag the
| window edge to make it smaller, the column suddenly gets
| wider. As I continue to make the window narrower, it gets to
| the point where there's no whitespace until it gets very
| narrow, then a small amount of whitespace (but enough) is
| introduced on the sides.
| weeboid wrote:
| Use what is in the standard distro. Don't go too far downstream.
| MacVim/gVim
| joemi wrote:
| MacVim which you mention isn't part of any standard distro. But
| also: why should it matter really? If someone is a Neovim user,
| they'll have very little difficulty using vi/vim when that's
| all that's available. Basic no-plugins Vim is pretty
| indistinguishable from basic no-plugins Neovim, for the user.
| nautilus12 wrote:
| I've wasted SO much time trying to get vim set up to be roughly
| as productive as intellij. if there was some way I could get this
| out of the box i would be happy, but until then just using
| ideavim in intellij, pycharm will be my go to.
| tombh wrote:
| I'm in the curiously rare position of being a long time Neo/vim
| user who doesn't use its modal features. Namely I have all my
| keybindings setup like a "normal" editor, CTRL+S to save etc.
|
| I say it's curious because I've always been surprised that
| Neo/vim is mainly celebrated as "that modal editor". Whereas for
| me I celebrate it as the most feature-packed and lightweight
| terminal editor. Neo/vim is sooo much more than merely its modal
| editing.
|
| With this new release of Neovim maybe there's renewed interest in
| what Vim is beyond the stereotypes. I wrote a plugin a few years
| ago that intelligently disables Neo/vim's NORMAL mode [1]. It
| always seemed such an obvious idea when the majority of editors
| have their own plugins to intelligently enable Vim-style
| modality.
|
| 1. https://github.com/tombh/novim-mode
| tooltower wrote:
| Is this any different from vim's easy mode? I remember that
| being available as an extra shortcut by default when I tried
| gvim on windows (> 15 years ago).
|
| Easy mode, aka 'evim':
| https://vonheikemen.github.io/devlog/tools/vim-easy-mode/
| j-james wrote:
| Vim's "easy mode" also appears to be cut from Neovim (or not
| accessible by the -y flag, at least)
| tombh wrote:
| It's in the same spirit certainly, but it's just not
| complete. For example its interaction with other plugins
| means you get thrown back into normal mode a lot. Also I just
| think the name "easy" betrays its real intention as some sort
| of training wheels for newbies. I'm more interested in making
| non-modal editing a first class citizen.
| majkinetor wrote:
| You just didn't dig it.
|
| For example, name me another editor where you can jump in less
| then a second to any letter of the text ? You always have to
| click. Contrary to that, editing in vim is like programming
| since you have editing DSL. All editors provide shortcuts to
| just some of the editing capabilities (duplicate/delete line,
| next word, prev word etc.) but not ALL of the imaginable and
| unimaginable scenarios like vim does, in a way that is
| instantly programmable to your liking without messing with
| configuration.
| thomastjeffery wrote:
| Insert mode is a great text _writing_ app on its own, but
| normal mode is the best text _editor_ I have encountered.
|
| Being able to move to a specific part of a file quickly, edit a
| specific part of a file quickly, repeat that edit on a
| different part of the file (with .), write out an editing
| action as pain text and save that as a macro... The list goes
| on.
|
| The only thing I don't like about vim (normal mode) is that the
| keybinds and context are hardcoded. Sure, you can remap them,
| but that only gets you so far.
| oblio wrote:
| I didn't go that far, but for small movements I use arrow keys.
| hjkl don't make any sense to me and I'm not keen on using them
| just because someone had that keyboard layout in 1978.
| e12e wrote:
| How very, very naughty! Delightful, but not for me,
| thankyouverymuch!
|
| I'm curious about why, though? What parts of vi(m) do you get
| to _keep_ that this makes sense for you?
| markandrewj wrote:
| Watching ThePrimeagen and tjdevries has also given me some good
| insights into neovim. Tjdevries has put a lot of work nvim-
| treesiter, and it shows. I have stuck with regular vim for a
| while because I have everything configured the way I want, but I
| am setting up a new build now, and I will probably move to
| neovim.
| tjdevries wrote:
| Wow thanks!
|
| btw I'm tj :]
| tomerbd wrote:
| I'm using vim happy no plugins no config just edit files do I
| need neovim?
| joemi wrote:
| No. There's no real benefit in this case. For the most part,
| the main practical advantage of Neovim over Vim (from a user
| perspective) is that there are some plugins that are only
| supported by Neovim and there are some types of plugins that
| might work better on Neovim. So if you're not using plugins
| this won't affect you.
|
| There are some ideological advantages of Neovim over Vim, too,
| but those are relatively minor; neither is evil software, and
| it can be argued that Vim has some ideological advantages over
| Neovim, too.
|
| For a plugin dev or vim/neovim dev, there may be other
| practical advantages one way or the other.
___________________________________________________________________
(page generated 2021-05-26 23:00 UTC)