261–270 of 429 posts
Earlier quoted context omitted.
What's a good x-platform GUI for it?
1) Terminal 2) Neovide : https://github.com/Kethku/neovide 3) Neovim-Qt : https://github.com/equalsraf/neovim-qt
FireNvim [1] is a browser plugin which embeds a Neovim editor window in HTML textareas
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 cann…
> 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.
vim script is too limited and there are no other options, really.
Python plugins are a hassle.
Earlier quoted context omitted.
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 IDEs have vim bindings.
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.
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…
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 w…
Earlier quoted context omitted.
> Editing/moving over text is just way faster with vim then any other editor (not just slightly faster, light years faster). Text? Yes. Code? No. Since editing moving code is a subset of refactoring, and Vim has no knowledge about code.
Well, this update is all about that so I guess... solved ?
Earlier quoted context omitted.
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 di…
Earlier quoted context omitted.
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. Becau…
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 comm…
(These are also English-specific justifications)
Earlier quoted context omitted.
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 w…
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.
Earlier quoted context omitted.
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. Becau…