New answers tagged

0

One thing I've just seen is that if cpo contains <, then special characters like <leader> won't be handled right: *cpo-<* < Disable the recognition of special key codes in |<>| form in mappings, abbreviations, and the "to" part of menu commands. For example, the command ...


2

Checking the output of filter helped diagnose the problem, my vimrc also contained the following line: " If installed using Homebrew Plug '/usr/local/opt/fzf' which referred to a program (fzf) that wasn't installed but also couldn't be installed by vim-plug. Installing it properly fixed the problem.


3

I am using a convenient macro Just FYI, one can also do :ls<CR> to achieve the same result. So that one does not look like "a life saver" to me. a way to then switch to the buffer of interest Again, that does not look so useful, as one can always do :b[Number]<CR> without any hassle. But let's figure out how we can create a "parameterized" ...


1

For single-digit buffers, you can actually hardcode 9 mappings, one for each digit: nnoremap <Leader>b1 :buffer 1<CR> nnoremap <Leader>b2 :buffer 2<CR> nnoremap <Leader>b3 :buffer 3<CR> nnoremap <Leader>b4 :buffer 4<CR> nnoremap <Leader>b5 :buffer 5<CR> nnoremap <Leader>b6 :buffer 6<CR> ...


1

This is default behaviour of Vim. Vim notices, the buffer has been modified and just warns you of quitting and (possibly) losing your changes. This is done by setting the modified option for the buffer you are currently editing. However, despite its name, it does not mean that the current buffer differs from the state on disk, but rather whether a change ...


4

First, your function can be simplified into let bufnr = term_start(&shell, {"hidden": 1}) Second, it's not a problem to have buftype ==# 'terminal' and set nobuflisted together, as these are two different options. So if bufnr call setbufvar(bufnr, "buflisted", 0) endif is very much okay. However, the real question is: why you create a terminal at ...


2

NERDTree does a great many things that are... unvim-like... in order to give the IDE “project drawer” experience. I consider most of them hacks, and I’m wary of a plugin which has to hack around default behaviors and usages to do something I don’t need (see Oil and Vinegar). All of that said, one of its hacks is actually quite normal—it’s an unlisted ...


1

If you just want to set the syntax always to context, just put this in your vimrc: autocmd BufReadPost *.tex set syntax=context


5

One possible solution is to do the calculation by yourself and add them in your status line: First you will need a function which returns as a string your current position as a decimal percentage: function! GetCurrentPosition() return printf('%.2f%%', ( 100.0 * line('.') / line('$') )) endfunction The function uses line('.') to get the position of the ...


3

system() is the right function; it should work fine also inside ~/.vimrc, but is best avoided as each external command delays Vim's startup and makes the user wait. Ideally, you'll be able to only invoke the external command once it's required for a user interaction (i.e. lazily) - and then cache the information in case it's needed again. If you absolutely ...


0

I would go with either " load Plugins.vim, searching it in "all vim places" runtime Plugins.vim or " load Plugins.vim from the relative path of your vimrc source <sfile>:h/.vim/Plugins.vim


1

You can try hiding it using set fillchars=vert:\ hi! VertSplit guifg=black guibg=black ctermfg=black ctermbg=black Instead of black use color of your terminal or colorscheme background (not sure about various fancy terminals out there) NOTE: vert:\ the space at the end. It also works with windows terminal (preview): (you have to set fillchars, though)


0

While you have fixed VertSplit highlighting I don't see anywhere here the replacement of the actual vert 'fillchar' value. We know removing it doesn't help as it will fall back to a default value but this seems to me to be a sufficient workaround: :set fillchars=vert:\ ,..the rest.. (That's an escaped Space char.)


0

it seems like its impossible to completely remove the fillchars You can't really remove it, but you can make it invisible: " must be before setting your colorscheme augroup nosplit | au! autocmd ColorScheme * hi VertSplit ctermfg=bg guifg=bg augroup end


2

I also have this problem. Unfortunately, I think the fault lies with Konsole. When I open Konsole, I can click Settings-> Edit Current Profile and it correctly edits my profile. Then I send the cursor change sequence (echo to the terminal, or from vim). If the font size has been changed, it will reset as described in the question. I then again go to ...


5

Result of map 0 : 0 * g0<Space> There is a space after g0, remove it should solve your problem. Put this to your vimrc to show trailing space, tab and other stuffs: scriptencoding utf-8 set list listchars=trail:┄,tab:†·,extends:>,precedes:<,nbsp:+ scriptencoding


1

The best thing to do is enable filetype detection: filetype on Vim defaults to setting .tsx files as typescriptreact (8.1.2100 for me at least). To enable filetype-plugins and indent scripts (recommended): filetype plugin on


1

I tried to use augroup SyntaxSettings autocmd! autocmd BufNewFile,BufRead *.tsx set filetype=typescript augroup END and it works.


2

Make a buffer active by its number You can combine win_gotoid() & win_findbuf() to accomplish this: :call win_gotoid(get(win_findbuf(g:tn), 0)) But we can do better for terminal like things by improving a few things: Automatically set our variable on TerminalOpen autocmd Provide methods to send text to the terminal Provide a command to jump to the ...


2

So the top buffer became "a mirror" of the terminal buffer with the number 2. Your problem is that you confuse "buffer" and "window". Those "rectangles" you see are called "windows", while their contents are called "buffers". So the command :b 2 says "I want a buffer number two to be shown in the current window". And that's not what you really wanted. ...


4

Due to the way that the keyboard input is handled internally, this unfortunately isn't generally possible today, even in GVIM. Some key combinations, like Ctrl + non-alphabetic cannot be mapped, and Ctrl + letter vs. Ctrl + Shift + letter cannot be distinguished. (Unless your terminal sends a distinct termcap code for it, which most don't.) In insert or ...


4

According to one of our former mods, the answer is no: Sending Control with a character from the 2nd column is useless. Control clears the 7th bit, but this is already 0, so Control+# will just send "#". Notice that & in the second column has binary representation 01 00110, so clearing the 0 doesn't help.


1

Every strange question have quite simple answers. Refer this thread. All that I had to do was enable cursor blinking in the terminal preference itself :/


0

The issue probably is that you don't use highlight group for the cursor you define. See pic: This is for GUI vim, not sure how it should be applied to terminal one.


3

The basics of simple mappings are explained in Vim's excellent user manual at :help 05.4. You want some key combination (Shift + Tab) to do what's already provided by Vim's Ctrl + D command, so you map <S-Tab> (using :help key-notation now) to <C-d>. As Vim is a mode-based editor, you need to consider the mode; :help i_CTRL-D is for insert mode. ...


1

Empty .vimrc is not the same as no .vimrc. Once I deleted it, it worked fine as before. Thanks to @Matt


1

As @statox suggested in comments I should have used tnoremap to implement it. The following works fine: execute "tnoremap ".g:toggle_term ." <C-w>:call ToggleTerminal()<CR>" The mistake I initially made was the space right after the N execute "tnoremap ".g:toggle_term ." <C-w>N :call ToggleTerminal()<CR>" and since I rebound ...


Top 50 recent answers are included