Re: change terminal colors

Em segunda-feira, 7 de maio de 2018 07:28:03 UTC-3, Renato Fabbri escreveu: > do your syntax highlighting settings (set with :hi) of an already started > terminal (started with :term) change? known Bug? tx++ -- -- You received this message from the "vim_use" maillist. Do not top-post! Type

reload ftdetect on the fly

source the file(s) with the new relation {filename pattern} -> {set filetyle=somethig)? the string search patterns for syntax highlighting are reloaded when the file is reloaded (on the same Vim session/run/instance). Something like that for setting filetypes would be useful (for me at least).

Re: autocmd terminal set signcolumn=no

Hi, I just read about the TerminalOpen event, when I use: au TerminalOpen * set signcolumn=no it works :-) thx, mark -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit

autocmd terminal set signcolumn=no

Hi, I set signcolumn=yes in my .vimrc. When starting a terminal the sign column is not displayed, but then going into normal mode for this terminal shows it again. I tried this - au BufWinEnter * if == 'terminal' | set signcolumn=no | endif but it does not work. Any idea how to automatically

Re: options window ignored

John Little wrote: > I must be missing something here. :h :options says > "For window and buffer specific options, the last accessed window is used to > set the option value in" > But the options window is ignored. F. ex. > > If I start vim with > vim -u NONE -U NONE -i NONE -N > then I

Re: 100000ii

Christian wrote: > On Di, 15 Mai 2018, Bram Moolenaar wrote: > > > There is an old entry in the todo list to do profiling on this, to find > > out what takes so much time. Apparently nobody bothered to look into > > this yet. > > I measured it once and I think the problem was the call to

Re: 100000ii

On Di, 15 Mai 2018, Bram Moolenaar wrote: > There is an old entry in the todo list to do profiling on this, to find > out what takes so much time. Apparently nobody bothered to look into > this yet. I measured it once and I think the problem was the call to getvcol(). More details in this old

Re: 100000ii

Eli wrote: > Prompted by a challenge here: > > https://fivethirtyeight.com/features/pirates-monkeys-and-coconuts-oh-my/ > > (Near the bottom of the page, in the answers to the previous challenge > dealing with editors.) > > I tried inserting a million letter "i"s into a new buffer with vim.

options window ignored

I must be missing something here. :h :options says "For window and buffer specific options, the last accessed window is used to set the option value in" But the options window is ignored. F. ex. If I start vim with vim -u NONE -U NONE -i NONE -N then I type 200ii and press escape, 200

Re: 100000ii

On Tue, 15 May 2018 at 10:40, Dominique Pellé wrote: > In theory, it could be done quickly in O(n). Actually pasting the character with 100p is super fast, so 100ix can surely be optimized. -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply

Re: 100000ii

Keith Edmunds wrote: > Optimising vim for a use case that will never exist in real life seems, well, pointless. > Why is this important to you? I would not say that it's a useless use case. It may be a rare case but it can happen. When it happens, insertion can take so

Re: 100000ii

Optimising vim for a use case that will never exist in real life seems, well, pointless. Why is this important to you? -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit