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.
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.
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.
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. :)
I recently gained a liking to search result highlighting, it's much more useful than I originally thought. The problem is not the highlighting itself but its persistence. I added a few autocmds to automatically hide it in certain events and a manual shortcut. Works better for me now, though it is annoying that `:noh` has some weird special status that makes it nonfunctional in autocmd.
I tend to avoid plugins for things that I can just do myself with a few keybindings or autocmds. I like that aspect of Vim (and Emacs) where the user is less reliant on plugins because there isn't really a clear, fixed boundary between configuration, scripting and external extensions. Though it comes with downsides (e.g. when plugin developers make the questionable decision of overriding user configuration).
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.
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 ;)
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.
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.
In English, sure. Not in Hindi for example (मैं खाना खाता हूँ - 'I food eat') or in .. object-oriented methods of many programming languages.
I don't think there's anything special about that mapping, whichever way around. I'm not inclined to think I'd perceive things or act any differently if my main way of describing things (English) had a different grammar - a rose would smell just as sweet.
I can see some value, especially for beginners, in 'highlight while object selecting, then act' (which you can do in vim with visual select and then action, e.g. instead of c2w do v2wc - or v2w -wait no that's not what I want-).
I do prefer it as it is though, probably just because I'm used to it, but I think of it as 'up to' rather than 'define the object', since it is always anchored (at least, without any plugins doing differently like is being discussed with Treesitter here, adding context awareness) by the cursor position. So I'm thinking 'change from here to..'. I suppose if one wants to think about 'object first' you could argue vim already is that anyway - you move to the object before typing any of the command.
Indeed, in Spanish we say "lava la ropa" do the laundry. I am pretty sure that is what my brain wants, action object. Once in object-oriented training I was told that In Cantonese the person does not act on objects but the objects act on themselves: "The deck of cards shuffles itself"
Latin has an extremely flexible word order (some of which Old English had too) which allows all kinds of fun stuff for style and communicating status/education. Japanese with its particle system also allows some good flexibility.
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.
I think you’re overestimating how well real life actions map to the object/verb dichotomy.
So you’d say that it’s object first because you first get the wood and saw and then decide to saw the wood with it.
I could argue it’s verb first because you first GET the wood and saw.
I’m not saying that I’m right and you’re wrong. In fact, quite the opposite. My point is that I don’t think real life actions can be broken cleanly into object-verb or verb-object, in the first place.
This whole back and forth in this subthread is ridiculous. People are comparing command syntax (not even a proper PL) with natural language syntax. First one is used to define actions first and foremost, and the second one to describe them.
How we formulate our actions in our head/speech to describe them is mostly irrelevant here.
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).
I think it's a wonderful thing that the IT ecosystem has created such a variety of different tool methodologies converging on the same purpose. It seems analogous to convergent evolution in biology.
It is pretty common nowadays in functional programming languages to find operators which reverse the order of application or composition, so rather than writing f(g(h(x))) one can instead write “x |> h |> g |> f”. This style is quite popular, which leads me to believe that many people prefer object-action over action-object in same way. (Although perhaps this is more a critique of action-object-object vs object-action-action)
While you didn't refer to any explicit programming language (so your example is correct by definition), I think you may have mixed up something. The order is reversed, but typically not in the way you describe. For your example of f(g(h(x))), you would write (f . g . h) x in Haskell. So for this particular example, the syntactical order is not reversed.
However, you could say the natural order of reading is reversed: The naive way to read (f . g . h) might be "first f, then g, then h", opposite the actual order of execution.
This x |> h |> g |> f syntax is Elixir (and F# perhaps? and surely other langs). In Haskell this is written
x & h & g & f
And in shell script, this is written
echo x | h | g | f
This operator is sometimes called the pipeline operator
Anyway, here is some ghci session exemplifying the usage of the & operator
$ ghci
λ import Data.Function((&))
λ a f g h x = x & h & g & f
λ b f g h x = (f . g . h) x
λ c = f g h x = f (g (h x))
λ a (+ 1) (* 2) (+ 3) 1
9
λ b (+ 1) (* 2) (+ 3) 1
9
λ c (+ 1) (* 2) (+ 3) 1
9
It's unfortunate that this is named & in Haskell and not |>. And what's worse, it's not in the prelude.
to be honest, idiomatic code in haskell-land tends to be written right-to-left and not left-to-right, so you'd usually write it with the ($) and (.) operators.
I personally have gotten used to reading it right to left more, as have probably most people who use haskell extensively.
And I think it's only fair that haskell chose a 1 character operator:
composing functions and applying them to arguments is the main way to make programs, so it's good that you have to type the least amount characters possible to do it, compared to something like F# where all the function composition and application operator take two characters (|>, <|, >>, <<)
I recently started using (&) a lot (e.g. `something arg1 arg2 & liftIO`) and frankly I think it's fantastic for readability, especially with adaptors like `liftIO` or `void` in `do` blocks. The relevant information is up front in a consistent position in the block; the adaptor is only even noticeable when I actually read the line - rather than being something I need to semi-consciously ignore. I also sometimes use it for chains of pure function application when the alternative is to read bottom-to-top or use where/let bindings with arbitrary names.
`import "flow" Flow` gives you (|>) = ($), (<|) = (&), (<.) = (.) and (.>) (by analogy). I slightly wish it were part of base - the symbols are much more intuitive, and I think that's important for increasing adoption - but I tend not to use it because it's non-standard. Most potential/plausible Haskell users, after all, haven't used Haskell at all, let alone extensively. Such people need to be taken seriously in decision making processes even though they almost necessarily have no voice.
I don't think the number of characters is at all relevant to the decision though: being non-surprising and understandable are far more important than using one vs two chars which in this case pull in both directions and I reckon the balance lies with sticking to the standard.
I'm assuming they were talking about Elixir, which uses that syntax to pipe the result of the left side into the first argument of the function on the right side. The transformation was correct in Elixir, and I can confirm that I at least do think that way.
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.
> “Basically, the only ‘intuitive’ interface is the nipple. After that, it's all learned.”
The nipple is not intuitive for everyone.
One of our children struggled mightily with the nipple and we had a miserable two or three months of breastpumping and finger-feeding before he finally figured it out.
Following-up on irrelevancy: what made you stick? We had the same experience, but gave up after 6 weeks because breastpumping was exhausting, and switched to bottles and artificial milk which our daughter loved immediately.
Just an FYI Kakoune is a modal editor. I've actually tried it and OP has a point, for many of the things that you would use visual mode in vim things are very natural in Kakoune. It's also surprisingly accessible to someone used to vim. That said, it's difficult to leave the huge community behind vim behind.
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.
I do exactly this when I'm doing complex commands and want to select-verify-run. Most commonly, something like vi(c where I want to confirm how the parentheses are nested before the operation.
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.
> 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 :)
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.
I think the only general claim that could be made is that the brain prefers to be certain of what's going to happen/what did happen. To get that you either need to have a good feel for where a motion is going to end up (which is harder the more inexperienced you are, and the more complex/farther the motion), or to get feedback.
Personally, I also struggle with a relatively high rate of accidental (or mis-registered) key presses, or being in the wrong mode, which means that even if I have high confidence in constructing the right command in my head, my confidence in the right command being executed is significantly lower, and direct, always-on feedback thus feels enormously helpful to me.
I suspect your hunch about object-action way brains work is very narrow and will not hold if extrapolated outside the western culture. My suspicion is based on a belief in [Sapi-Whorf hypothesis](https://en.wikipedia.org/wiki/Linguistic_relativity#:~:text=....). The need to reach of the object first is a very English specific language constraint afaik.
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.
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.
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.
```
" 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
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).
+1 easy motion makes the default jump-by-search feel really clunky. Typically it is mapped to double-tap leader then object, and it will then highlight those objects with a short-code to jump right to it.
Examples:
\\w -> will highlight all words after
\\b -> all words before
\\e -> ends of words after
\\ge -> ends of words before
\\fe -> all occurences of the char 'e' after
\\Fe -> 'e' before
\\se -> 'e' in both directions
\\j -> lines after
\\k -> lines before
etc.
but can even use it with traditional search:
\\n -> will highlight all search-matches found by a previous "/" or "?" search after current pos.
\\N -> will highlight all search-matches before.
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.
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.
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.
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.
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`) ?
Huh, somehow it’s never occurred to me to get binary logic by chaining :g and :v in this way—I’ve always done things in more complicated ways to make up for the lack.
You probably are familiar, but for some newer folks: I almost always add a "go to beginning of next line" as the end of the macro so that I can e.g. 10@t to repeat it 10 times. Makes it much quicker than @t on each line once you have more than a few.
I know I’ve read that part of the documentation before, but probably not for over five years. In cases where I’ve wanted something like that, I’ve tended to reach for macros, visual block editing, and s/\=. A few days ago I did a somewhat more complicated one that s/\U wouldn’t be sufficient for:
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.
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!
Sorry but column editing is a stripped-down multicursor mode. I use vscode-vim (so, VSCode with Vim mode) and never use column editing because the IDE multicursor is much more powerful. Without being any sort of editing wizard, I'm finding your video example slow and mildly painful to watch
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.
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.
Exactly. The best approach is layering, in my opinion. Learn the basics, maybe a couple of tricks, and then deliberately add one more thing to your toolbox which would improve your productivity. Then incorporate that new trick into your flow until it sticks, then repeat. Eventually your toolbox is getting full and you are able to recall all the things naturally.
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.
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...
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.
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.
Don't worry, you're not alone. 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode.
It's frustrating to see. CMD-D in VSCode does 95% of what's needed, with no mental burden.
But hey, you can't "brag" that you "know VIM" if you use VSCode...
> 100% of the people I've ever saw using Vim / Neovim spend much longer "calculating" their next command than they would spend just doing in with CMD-D in VSCode.
Right, there is mental overhead to calculate moves but often times you can extract out patterns into intuitive key mappings once you've solved the problem once.
The basic idea here is I can either move the cursor on top of a word or select some text, hit s*, type what I want to change that text to and then hit dot (.) as many times as I want to repeat the change to the next match. It's like being able to use multiple cursors except without needing multiple cursors and I also get to see the result applied once before I start applying it to multiple things. It's also possible to skip matches using existing Vim mappings (n).
I use the above all the time to make changes in spots where I would have used multiple cursors with VSCode.
You prove my point. You had to create this insane macro to solve something that cmd-d does automatically in VSCode. And cmd-d is much more versatile, since the same concept applies to many other use cases.
And sorry I say insane, but not knowing the language, your macro looks absolutely absurd and as obscure as a sample of brainf*ck.
I refuse to learn such a complicated language just to create a macro that replaces cmd-d and cmd-z, just so I can brag that I use Vim.
Clever! I think I might steal these, or make something based on your idea.
Kind of wild: in taking apart your command, I learned three things about Vim that I didn’t know, each one of which is massively useful. And I use it every day!
> I think I might steal these, or make something based on your idea.
Sure thing, if you can improve it let me know.
Here's an even wilder thing. I set those s* mappings up about 2 weeks after using Vim and I still don't know how they work in perfect detail but I was able to find them by Googling. There's definitely a stigma that you need to be some crazy wizard to use Vim but with a bit of repetitive learning and Google you can get pretty far.
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.
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?
You make your build system emit a compile-definitions.json file that has all the compiler flags for every file you compile and feed it to a language server (rtags or clangd usually, either standalone or part of another plugin like YouCompleteMe). CMake has a flag to do that as part of its configuration step (and remembers it), for other build systems you can use something like bear: https://github.com/rizsotto/Bear .
For future reference, as I found this information to be difficult to find: the flag for CMake is `CMAKE_EXPORT_COMPILE_COMMANDS=YES`. In out-of-source builds, the output file will be in the build directory, therefore one has to create a symlink to ensure the language server finds it in the project root.
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.
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.
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.
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.
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.
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.
Thank you! I tried this out on my setup, but was disappointed when it didn’t work. I’m new to evil and I’m constantly impressed with how big the ecosystem is!
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.
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.
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.
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.
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.
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
Please someone clean that tpope searchlight!
Na na na na na na na na tpope!
I would actually pay (although relatively small amount) for better programming text objects. It would feel so much more natural than the currently burned in muscle memory workarounds...
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?
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.)
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.
> 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.
Well, yes. Vimscript plugins will see better adoption. Lua matters for compute-heavy plugins.
> Ahh, yes, the Turing-equivalence fallacy: "technology A is theoretically capable of doing everything that B does, therefore they're equivalent".
Language design is not the full picture. init.lua is essentially a thinly-veiled init.vim with lua syntax. You will have to learn init.vim either way. It is extra work to do something in init.lua, and in using it you remove any chances of it ever working with an installation of vim (e.g. vim still has the best GUI options out there).
> From the language-design, performance, documentation, robustness/general codebase quality, and total number of users perspectives, Lua is overwhelmingly better than vimscript.
Even if ahead of Vimscript; from the language-design, performance, documentation and total number of users perspectives Lua sucks very very much.
> 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.
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.
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.
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.
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.
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.
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.
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.
> emacs lisp is not the best language in the world
Emacs-lisp is a Lisp. It may not be the best of Lisps, but even a bad Lisp can be far more powerful than many other non-lispy languages. To understand what makes Emacs so awesome, one has to understand the philosophy of Lisp. Emacs Lisp is not just a text editor, IDE, email client, project management tool, scientific calculator, etc.
Emacs, first and foremost is a Lisp environment. Definitely not the most ideal, but certainly the best one we have today.
> I think emacs having more plugins is a consequence of its design and philosophy, not the extension language itself
I believe, Emacs held the crown of "the most malleable" tool for over forty years, specifically because it builds on top of Lisp.
Number of plugins is not an indicator. They also have to "play nicely" with each other. I just checked - I pull over four hundred Emacs packages in my config, including built-ins and dependency libs. I just cannot imagine any other IDE or text editor with 400 plugins installed. That's just not possible.
Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs. It is the other way around: it was Emacs that created Emacs lisp. Initially, emacs was created on top of TECO, arguably the worst, most difficult programmable editor ever created. TECO language was so bad that they decided to switch. But emacs, the editor, was successful even running on top of a terrible language that nobody liked at the time.
> Emacs lisp is not a bad language, but it's also not the reason for the existence of Emacs
Early Emacs and the modern GNU/Emacs I think, are two distinct worlds.
I believe Lisp has shaped Emacs into its modern form.
I just can't imagine the possibility of building something like Org-mode, with the same level of extensibility and flexibility in any other language that is not a Lisp.
I bet if you ask any serious Emacsen - authors and maintainers of Magit, CIDER, or any other serious Emacs package if they could replicate their work, for example, in Python. I have no doubts, they'd definitely say: "that's nearly impossible"
Magit is not just a user interface. It's also a number of emacs-lisp packages useful on their own. It's Transient that's gaining popularity for building modal key UIs in Emacs. It's Forge that paved the road for nice packages like github.com/anticomputer/gh-notify. It is Org-mode integration and many other things.
What you're using is a ported subset of them.
There are always multiple paths to get something done. Some people prefer automation. Having "a bucket of bolts and nuts" makes it possible to hack your way around things.
Some people like Ferrari. For some - the utilitarian value of it, is minimal. They'd rather have "a bucket of bolts and nuts" instead. They can't go camping in a Ferrari. They can't take their bullmastiff to a vet in it. They can't help a friend to move furniture.
Emacs is that - it's not akin to a shiny, expensive but not very useful car. It's like a transformer - you can build a pickup truck, a camper, an ambulance, or a race car.
But some people like Ferrari. And that's totally fine.
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.
> 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.
Lua ia an extremely powerful and popular extension language. It probably has at least 10x the users that Vimscript has.
And people willingly choose Lua. Barely anyone chooses Vimscript, they're generally forced to use it.
If anything, Vimscript is the <<unproven>> extension language. It's in Vim because Bram made it the Vim language, but it was never voted on or designed. Vimscript will most likely die with Vim, because I'm quite convinced that outside of trolling attempts, no one will adopt it for another app ;-)
Which is just fine! Vimscript was created to create simple vim scripts, not to build full programs.
And if you need to do more than Vimscript can do, Vim already provides this: it has native bindings to Lua, among other languages. If Lua was such in demand to write vim scripts, at this point it should have taken over VimScript as the main extension language, but it hasn't, and I guess that unless something huge happens in the community, it won't.
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.
> 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.
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.
I don't have experience with Vimscript, but I know both Lua and Python. It seems that the biggest benefit is gained by stepping up from Vimscript to any of those two. Switching to the other would only have diminishing returns, if at all.
Apart from that, Lua was explicitly designed to be embedded. Python is designed as a scripting language that can bind to C code, and embedding seems to be an afterthought.
This is demonstrably and unequivocally untrue. Lua is designed to be fast, lightweight, and easy to use as an embedded scripting language. Python is a general-purpose kitchen sink language. Python is 10x bigger, and 10x slower than Lua. It is bad fit for an embedded language.
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.
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.
> 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.
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.
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.
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:
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)
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.
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.
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!
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.
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.
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.
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.
I was in the same boat, but I'm taking some time off work and I'm very happy with the Lua support. New link to my dotfiles to come. In the mean time, here are my current ones, in case they help anybody out: https://github.com/hoov/dotfiles. I use MacOS, WSL2, and Debian unstable.
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?
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.
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).
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.
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.
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.
> I think emacs is more likely to have breaking changes
Matter of fact - stuff in Emacs breaks all the time. Frankly, Emacs simply defies any logic - sometimes you feel it shouldn't work at all, yet it does.
You see, when talking about differences of configuring Emacs and any other text editor or IDE, one has to understand - there's really no "configuration" in common sense. Emacs is a Lisp environment where you run your programs. You can download, import, and use other programs. Very often those programs "talk" to each other. Sometimes (of course), the line of communication breaks, and then you have to step in and patch them up so they can continue working together.
That's the biggest headache and confusion for beginners. They shy away from learning Emacs Lisp, and they think they can focus on learning Emacs fundamentals by using some "minimal configuration".
But only after understanding the basics of Lisp - structural editing, evaluating s-expressions, macro-expansion, etc., one could appreciate the enormous capabilities of Emacs. And when something breaks, it's quite simple to spot the problem and put a workaround.
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.
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
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.
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.
I am not here to shit on Emacs -- I recognize that I am not its audience. Took me a long time because I was in denial but eventually I figured it out.
But I get Elisp warnings and errors every day. And mind you, I did abandon my monstrous init file a year ago and just yielded to Spacemacs with very minimal changes like font, cursor customization et. al. -- basically just 7-8 of these. It has a ton of stuff in it though. Spacemacs isn't a lightweight Emacs. Being on macOS might be another thing, too, I don't know.
Even with that, there is trouble on a regular basis. I would think an all-in-one package deal would have better debugging and proper care but oh well. :(
Again, not here to degrade Emacs itself, I am only here to share that the amount of effort I am willing to invest to maintain my local installation is apparently not enough to have a well-running editor, and that I will be giving up on it because of that.
No, it's not. Many people make a mistake, thinking that Doom, Prelude, or Spacemacs are ready-to-use, out-of-the-box solutions. They are more like collections of recipes. You have to judiciously remove things. You need to know how to use the built-in profiler.
> and that I will be giving up on it because of that
And that's okay. I myself abandoned Emacs and moved back to other things several times, until I finally learned how to make it work for me.
> ...still prefer stuff to come semi-configured out of the box
Maybe I'm weird, but stock GNU Emacs as out of the box is perfect for me. Tried configuring it with various bells-and-whistles over the years, but I always come back to stock Emacs.
(And no, despite using Emacs for 25 years I don't write elisp.)
Well it absolutely isn't for me, f.ex. I constantly need project-wide functionality like find files by name or contents. Just using C-x C-f all the time is much more inefficient.
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.
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.
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 :)
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.
> 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.
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.
> 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?
Thanks. I'd previously tried and failed a couple of times to get a NeoVim gui installed, mainly because I wanted to try one of those ligature fonts that display -> as → and the like. There seemed to be a few different options, in various states of being abandoned, or unpackaged, or needing libraries not in my OS, or ...
Turns out now all that's needed for Ubuntu is sudo apt install neovim-qt. Thank you for prompting me to look at this again.
However, on running it, the window seemed very wide, so one of the first things I tried was `:set columns=80` — and nothing happened. Checking :h 'co`, it looks like it's supposed to work.
Whenever I read about LSP I'm reminded of Jonathan Blow's talk Preventing the Collapse of Civilization where he talks about LSP and how it turns your single app into a fragile distributed system[1].
The sheer complexity of going from vi, to vim (and plethora of plugins), to vim + LSP is simply insane to me. It does feel like we've all lost our minds.
I didn't watch the whole talk just the part you linked. I'm sure he makes some good points. But yeah, this guy does not understand why we have lsp's at all.
An LSP is a program that parses and internalizes a project written in a particular language and serves information, diagnostics, and edits, to a generic editor. The protocol is broad enough to serve all the "smart" language-aware functions provided by full-blown IDEs.
This allows one LSP to be used in ... many different editors. The advantage to the users is obvious: if go has one standard LSP, people who use neovim, vscode, vim, emacs etc all have an interest in maintaining that one LSP and will contribute to it in various ways.
Let me give you a few reasons why not only is it fine that it's a separate process, but you want it to be in a separate process.
1. LSPs will be better written if they themselves are written using runtime and the language that they serve.
2. LSPs can potentially hold a lot of memory. Sometimes you need to manage them, and potentially even cut them off, for example if you have a few very large java projects that you're switching between. Generally if they are separate processes, you can just kill them without affecting the editor. Additionally this also means the editor itself doesn't risk a memory leak caused by a rouge LSP server.
3. Subprocess management is not that hard. The editors can do it. Neovim does it pretty well in my experience. The presenter acts as if the server is some totally separate thing that you have to manage yourself. In reality the language server process is launched, managed, and owned by the editor, and often just communicates over stdin and stdout, not that there's anything wrong with ports.
Using multiple processes to distribute work among programs that do one thing well has always been the UNIX way.
He's definitely got a point. I had some memory problem with a business calculation I was running, I needed all the memory I could get.
So I looked at the various memory hogs on the linux installation and could see that every Vim invocation had a node process hanging off of it as a child, that's the Coc code completion/language server client running. (Action => only trigger coc for certain filetypes)
And I had vscodium running too, and it had its own long lived subprocesses hanging off of it, for language support, etc.
A lot of apps are like this - humongous clusters of processes (firefox, teams, vscode, and also Vim with the right plugins...)
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.
Agree totally. My experience with NVim 0.5, which is what most configs require, was errors and instability all over the place. I also don't like telescope which froze nvim on me completely.
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)
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.
I agree that vim script needs replacement, but I don't know that Lua was the correct answer.
It's not a super-popular language and makes some things harder than necessary. Base 1 arrays means you are almost certain to bake in bugs accidentally. Meta tables are even worse though. They result in many subtly different object systems. Maybe that's not as bad in a unified project, but it's the path to a fractured ecosystem. The builtin string library is very barebones which isn't a great place to be in a text editor. Finally, the "regex" match function is hyper limited.
I'd argue that either Python or JavaScript would be better.
1-based indexing is boring subject, you just get used to it like you did with 0-based indexing. FORTRAN and Matlab also use it and Julia apparently supports both.
The OOP through meta tables is bit more interesting discussion. Meta tables also enable other dispatching mechanisms, if you want to get fancy. In my case I find it makes me reach for OOP less often, which in turn reduces code complexity. I agree that it's frustrating when different libs are each using own OOP implementation. It doesn't matter too much because all those implementations are light and don't pollute the code base. Fractured ecosystem is both good and bad thing.
The string handling is kind of a pain point, especially if you are spoiled by Python. I have no idea how Neovim + Lua handle Unicode text?
Python is huge & complex language, as well as 10x slower than Lua. JS has more rough edges due to historical baggage, also a fast VM would be much much harder to integrate than Lua. I'd say they would both be worse choices for maintainability and Neovim usability.
I didn't know about QuickJS, last time I checked Duktape was most suitable for these cases. I see QuickJS was made by Fabrice Bellard himself. While linked benchmark is impressive for QuickJS, in case of Neovim they chose to embed LuaJIT which is ~10x faster than "official" PUC Lua. I see your point though, QuickJS would still be a good choice. JS and Lua are not that different once you set aside syntax differences.
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.
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.
They make sense because they are directly under your fingers, so you don't have to move them all the way over to the arrow keys and back just to move around.
jkl; would make more sense, that's the only oddity.
They should be respecting their directions, like the arrow keys do. Think UHJK or IJKL. Plus they would need nubs or similar to make them stand out a bit.
If you search for "oldest computer keyboards" in your favorite image search utility, you'll notice that many keyboards there don't have arrows at all. I did not find any keyboards with the arrows on the left side, although it wouldn't surprise me.
WASD is fine. Because WASD is organized like the arrow cluster and up is up, down is down (sort of, but the placement makes sense), left is left, right is right.
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).
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.
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.
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.
I always thought it was obvious that Vim has one of the best, if not the best ecosystem, plugins, documentation, community. And its portable. I absolutely love Vim for so many reasons, normal mode is just not one of those reasons.
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'])
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.
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.
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).
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.
> 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.
> 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.
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? :)
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.
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.
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.
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.
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.
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.
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.
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.
> the real advantage of [vim] is its installed everywhere, and just works over ssh.
I've always thought this is a very silly reason to use vim, when almost any text editor can remotely access files via ssh, and FUSE tools like sshfs exist.
I use vim extensively as both an IDE and config file editor, but almost never actually run it remotely on servers. I would rather not lose my configs and have to have two separate sets of muscle memory.
I tried out neovim because of VSCode. The VSCode vim plugins are generally unsatisfying. They’re vim emulators at best. The plugin that uses neovim as a server is amazing.
I tried running it with neovim stable, but it always warned me that was unsupported and I got occasional bugs that required a VSCode reload. Thus, I’ve been on 0.5 nightly for a while. I didn’t know why the VSCode plugin demanded it. I think after reading this post, it’s the LSP support.
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.
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.
I've used emacs for about 10 years (written plugins, declared emacs.d bankruptcy, gone all-in on org-mode), so I'm familiar with the pros of configurable editors.
Here's a list of more advanced functionality built into Intellij that would be difficult to replicate:
- Bullet-proof navigation and advanced refactoring that works every time across a wide variety of languages.
- Database integration: syntax highlighting for SQL code in strings, runnable sql, database introspection
- Debugging: consistency and polish across languages, not relying on external tools that might not be installed, visual debugger
Text-editors struggle with the "integrated" aspect of an IDE. It's not terribly difficult to coerce text editors to perform well for a single language. It's much harder to integrate plugins and provide a consistent experience.
There's good reasons to use text editors (learn how it all works, extreme customization, magit, lightweight) but there's many development tasks Intellij is just better at.
I mean, it's a trade-off. IntelliJ is better at some things, and worse at others. There are certain programming languages where I prefer IntelliJ (mainly Java and PHP), and there are other cases where I prefer Neovim (Rust, Julia, Python, LaTeX, markdown).
> Text-editors struggle with the "integrated" aspect of an IDE.
Neovim integrates a lot better with my terminal heavy workflows than IntelliJ does.
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.
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.
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.
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.
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!
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.
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.)
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.
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).
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.
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.
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
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.
Netrw, as a sibling comment mentions, does this for a number of common protocols (and is built-in). So you just open an file with a URL starting with sftp or whatever.
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.
As long as I a can keep my fingers on the keyboard, and never touch the mouse, I may give it a try.
BTW: unlearning and editor is almost harder than learning a new one. I started with 'ed' in 1984, then 'vi' and plain text terminals (HP-2621) until the mid 1990s, when I get my first actual XTerminal. Then VIM from the mid 1990s until now.
The command aspect is highly underrated by people that don't know the commands. The ability to :>% a full block. Things like that.
I think that is why most long term Vim users sound like they are insane to other people. Note: In the early 2000s, I worked with a guy that only ever programmed on Windows with Visual Studio. We were coediting (side by side) a large file during some architectural changes, discussing it as we went, and I did one of those :g/this_old_thing/s//new_thing/gp changes on the file and he just yelled "stop". I though I had broken something. He just said what did you just do and how did you do that? So I undid, and slowly retyped the line explaining what each step did, and hit enter. He went out and got a vim book that night. I have to apologize for the mental damage that might have caused him (lol). He picked it up quickly, I showed him a couple plugin I use. (I don't use many, mostly plain stock Vim).
I have messed with VSCode a little. I may take a look at Neovim. I looked at it about four years ago, and I guess it just wasn't really ready yet.
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.
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.
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
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.
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.
> 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 - in terms of what it enables you to implement) with JetBrains IDEs and ReSharper already?
I haven't used LSPs too much, but I'll say they work to a good degree.
IDEA is hyper optimized for their target languages, from what I know Intellij builds custom engines for every language, so at least in some aspects (large scale refactoring) and at least for now, IDEA and its siblings are a step ahead.
Isn't a language server an engine custom built for a particular language?
> at least for now, IDEA and its siblings are a step ahead.
For the languages they supported back then, they have been [almost] as good 10 years ago as they are today. The step seem really huge if there still is nothing nearly catching up.
IDEA has wicked refactoring abilities. If I rename a class, it will find all the functions whith input param of this class and ask to rename them as well. It can identify class references from plain strings. This is useful at least in Java where xmls reference classes or testdata comes from another variable. The last one may be personal subjective bias, but auto complete options are always spot on, heavily affected by context and recent selection, while LSP auto complete suggestions while good, are a rough estimate of what I want.
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.
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.
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.
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.
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.
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.
You don't like programming? That is precisely how that sounds.
Most programming languages in use today, one way or another, were influenced by Lisp.
If you seriously into programming, I suggest re-evaluating your point of view about it. Learning and understanding Lisp will make you a better programmer. I am not trying to sound like a patronizing dick. I honestly wish someone gave me that advice a long time ago. Who knows, maybe I would've become much more accomplished today.
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.
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.
I've been a using vim for well over a decade. I switched over to neovim for the native LSP support. I spend most of my time programming in neovim but I also have goland installed which I use for high level refactorings such as "extract method" or "change signature". Once I can do these high level refactors with nvim+gopls then I can finally leave goland.
Can't say I really care about more syntax highlighting or lua. Less config is better.
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.
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..
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.
Maybe it’s MacOS or just working in generally larger files but for me vim seems to be lagging more recently… I think it might just my computer but I really find it annoying when typing on my local machine can sometimes lag as if I’m sshed into a remote machine… anyways still way faster editing in vim then not… neovim sounds neat and worth trying
People compare them like they have relative differences. I'd argue that they are two incomparable categories.
I'm a die-hard Vimmer who uses Emacs, and it's now clear to me that when talking about Vim and Emacs, one has to emphasize their foundational values, ideas at the root.
Vim is an amazing, incredible idea. It's the most satisfying and productive way to navigate around any kind of text. And as long as we have keyboard input and keyboards, Vim will stay relevant.
And Emacs is based on another fantastic idea. Arguably - the greatest idea in Computer Science to this day. Lisp. And understanding Lisp is a prerequisite required to appreciate the power of Emacs.
From my personal experience, when people try to compare one to another - there's usually one-sided incomprehension. They either don't have sufficient experience using Vim, or they lack understanding Lisp.
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 :)
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.
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.
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.
+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 :)
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.
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.
Are there any inherent reasons that I should switch to neovim from vim?
Everytime I try to do that, I don't see immediate benefits and vim kind of catches up or plugins start to support vim and I just go back to vim as all my script keeps working there.
What's the recommended way to run nvim on macOS these days?
Just run it within Terminal? I recall that unlike on Ubuntu, there was some scrolling lag to it that might have required some tweaking. Not sure if that's the case anymore.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
- I think VSCode is a great piece of software until my it starts using most of my laptops resources and my fan kicks in.
- I do a lot of work in a terminal. VSCodes terminal support is pretty bad. It might be better when they get nicer terminal tab support (not what they recently added)
- vim + terminal is considerably lighter and faster
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.
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.
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.
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.