Re: quickfix information

Hi, I am reviving an old thread. On Monday, April 13, 2015 at 5:04:20 AM UTC-7, herm...@free.fr wrote: > Hello, > > I did not expect that many reactions. This is nice. Thank you all for > your interest in the matter. > > > > Ah, but as long as you are OK with that information showing up in > >

Re: Bug in ftdetect?

On May 24, Christian Brabandt wrote: > [...] > > However, I think you might have found a bug here. Your > ftdetect script does this: I don't know that I'd characterise it as a bug, since this: > autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown > > The :args command does fill

Re: Bug in ftdetect?

On Wed, May 24, 2017 at 11:08:58PM +, Antony Scriven wrote: > On May 24, Frew Schmidt wrote: > > > [...] > > > > Maybe a dumb question, but why would BufNew be more expensive > > than BufRead? Shouldn't the filetype stuff get run either way? > > I wouldn't expect BufRead to take 500ms

Re: Bug in ftdetect?

On May 24, Frew Schmidt wrote: > [...] > > Maybe a dumb question, but why would BufNew be more expensive > than BufRead? Shouldn't the filetype stuff get run either way? > I wouldn't expect BufRead to take 500ms and BufNew to take > multiple seconds, would you? The bufnew autocommands

Re: Bug in ftdetect?

I'm glad you were able to come up with a solution! So I guess `vim *` goes through a different codepath than `:args *`? Note that this also affects the quickfix, the location list, and the local args list. Initially I discovered this issue with `:cexpr` and reproduced it with `:lexpr` and

Re: Bug in ftdetect?

On Mi, 24 Mai 2017, fREW Schmidt wrote: > Yes. "If I replace the contents of /usr/share/vim/vim80/syntax/vb.vim with > `let > b:current_syntax = "vb"` everything is fast and, as I would hope, the support > files are not loaded N times per buffer but instead exactly once."  Well, I see the

which guifont on windows for vim-airline or spacevim ?

Hi, Want to use vim airline or spacevim in gvim build for windows 10 but which guifont or font to use to get all special characters of these plugins ? Thank you ! -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to.

Re: Vim startup profiling

Le mercredi 24 mai 2017 21:54:12 UTC+2, Christian Brabandt a écrit : > On Mi, 24 Mai 2017, Antony Scriven wrote: > > > Your colorscheme or vimrc or both appears to be causing > > syncolor.vim to go bananas. I'd take a look at the code > > there to find out what's going on. filetype.vim and

Re: Bug in ftdetect?

Yes. "If I replace the contents of /usr/share/vim/vim80/syntax/vb.vim with `let b:current_syntax = "vb"` everything is fast and, as I would hope, the support files are not loaded N times per buffer but instead exactly once." -- Sent from a telephone. Pardon my brevity. On May 24, 2017 12:52 PM,

Re: Vim startup profiling

On Mi, 24 Mai 2017, Antony Scriven wrote: > Your colorscheme or vimrc or both appears to be causing > syncolor.vim to go bananas. I'd take a look at the code > there to find out what's going on. filetype.vim and menu.vim > are just big. You can disable loading menu.vim with `set > guioptions+=M`

Re: Bug in ftdetect?

On Mi, 24 Mai 2017, fREW Schmidt wrote: > It is sorta weird that the vb syntax, is somehow part of the problem, > but whatever I understand that this was the wrong way to configure the > editor. Not sure I understand. Are you saying, that the vb syntax script is responsible for the long

Re: "superscript" asterisk is gone!

Bram Moolenaar wrote: > Charles Campbell wrote: > >> Tony Mechelynck wrote: >>> In Bitstream Vera Sans Mono 8 in gvim 8.0.600 for GTK3 (which I just >>> made using "make reconfig" after an update of the python2, python3 and >>> IIRC lua packages), U+20F0 is present in the buffer and gvim >>>

Re: "superscript" asterisk is gone!

BPJ wrote: > > > Den 22 maj 2017 21:32 skrev "Charles E Campbell" > >: > > Tony Mechelynck wrote: > > In Bitstream Vera Sans Mono 8 in gvim 8.0.600 for GTK3 (which I just > > made using "make reconfig" after an update of the

Re: Bug/non-determinism in output of maparg() and map commands

On Wed, May 24, 2017 at 9:28 AM, Brett Stahlman wrote: > On Wed, May 24, 2017 at 2:08 AM, Bram Moolenaar wrote: >> >> Brett Stahlman wrote: >> >>> On Tuesday, May 23, 2017 at 8:25:33 AM UTC-5, Brett Stahlman wrote: >>> > On Tue, May 23, 2017 at 4:35

Re: Bug/non-determinism in output of maparg() and map commands

On Wed, May 24, 2017 at 2:08 AM, Bram Moolenaar wrote: > > Brett Stahlman wrote: > >> On Tuesday, May 23, 2017 at 8:25:33 AM UTC-5, Brett Stahlman wrote: >> > On Tue, May 23, 2017 at 4:35 AM, Bram Moolenaar wrote: >> > > >> > > Brett Stahlman wrote: >> > >

Re: Bug in ftdetect?

Aha! That's it Antony; thanks; that explains it and a lot more. Sorry for inexplicably missing this myself. On Wed, May 24, 2017 at 08:17:46AM +0100, Antony Scriven wrote: > Try taking out the BufNew autocmd. That'll get triggered for every > file in the args list, whereas BufRead is only

Re: Bug in ftdetect?

It is sorta weird that the vb syntax, is somehow part of the problem, but whatever I understand that this was the wrong way to configure the editor. On Wed, May 24, 2017 at 08:17:46AM +0100, Antony Scriven wrote: > Try taking out the BufNew autocmd. That'll get triggered for every > file in the

Re: Vim startup profiling

Le mercredi 24 mai 2017 11:01:31 UTC+2, Dominique Pelle a écrit : > Ni Va : > > > Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit : > >> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit : > >> > > Thank you > >> > Sped up by using a plugin manager supporting lazy

Re: Vim startup profiling

> Ok I save 100ms using the plugin manager vim-plug but not enough for me. > Is anyone can advise me or explain to me why some files are loaded twice and > take twice or more times N msec: > - vim80/menu.vim > - vim80\filetype.vim I never compared vimplug vs VAM, but I'd be interested in it.

Re: Vim startup profiling

Ni Va : > Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit : >> Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit : >> > > Thank you >> > Sped up by using a plugin manager supporting lazy loading or as needed >> > (vim-addon-manager/Neobundle maybe more). >> > >> >

Re: Vim startup profiling

Your colorscheme or vimrc or both appears to be causing syncolor.vim to go bananas. I'd take a look at the code there to find out what's going on. filetype.vim and menu.vim are just big. You can disable loading menu.vim with `set guioptions+=M` if you don't need it. --Antony 2017-05-24 9:39

Re: Vim startup profiling

Le mardi 23 mai 2017 21:46:01 UTC+2, Ni Va a écrit : > Le mardi 23 mai 2017 18:14:24 UTC+2, MarcWeber a écrit : > > > Thank you > > Sped up by using a plugin manager supporting lazy loading or as needed > > (vim-addon-manager/Neobundle maybe more). > > > > Typically sourcing twice is not a

Re: Bug in ftdetect?

P.S. If you want to detect name changes, there's BufFilePost. --Antony On 24 May 2017 at 08:17, Antony Scriven wrote: > Try taking out the BufNew autocmd. That'll get triggered for every > file in the args list, whereas BufRead is only triggered for the first > one that's

Re: Bug in ftdetect?

Try taking out the BufNew autocmd. That'll get triggered for every file in the args list, whereas BufRead is only triggered for the first one that's actually edited. FWIW 'BufNew' is not in the template ftdetect file in the docs. --Antony On 23 May 2017 at 22:28, Frew Schmidt

Re: Bug/non-determinism in output of maparg() and map commands

Brett Stahlman wrote: > On Tuesday, May 23, 2017 at 8:25:33 AM UTC-5, Brett Stahlman wrote: > > On Tue, May 23, 2017 at 4:35 AM, Bram Moolenaar wrote: > > > > > > Brett Stahlman wrote: > > > > %--snip--% > > > > > > The best solution is probably to also add the raw rhs, with