81–90 of 429 posts
AFAIK Neovim 0.5 uses tree-sitter. Is there any effort to integrate tree-sitter with Emacs in an easy way?
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…
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.
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 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…
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.
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'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…
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 ;)
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.
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'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…
Does anyone have a setup for Typescript/React that works/feels similar to VSCode?
Happy to answer questions: tom@meagher.co or Twitter DM (@awkweb)
Does anyone have a setup for Typescript/React that works/feels similar to VSCode?
even though there's an expected minor performance hit, it still faster than vscode
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
project('project_name', 'cpp', version : '0.99', default_options : ['cpp_std=c++17'])