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

[Brett Stahlman]

On Fri, May 26, 2017 at 5:24 PM, Nikolay Aleksandrovich Pavlov
 wrote:
> 2017-05-27 0:32 GMT+03:00 Brett Stahlman :
>> On Fri, May 26, 2017 at 4:12 PM, Nikolay Aleksandrovich Pavlov
>>  wrote:
>>> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar :

 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 the 
> >> > > terminal
> >> > > codes replaced.  This won't work when changing the terminal type, 
> >> > > but
> >> > > that is very unlikely to happen.
> >> >
> >> > You mean adding a key such as "raw_rhs" to the dictionary returned by
> >> > maparg()? If so, then yes this would help, but there would still 
> >> > need to
> >> > be a way to determine lhs, which is currently even more ambiguous 
> >> > than
> >> > rhs. While it's true that I probably already have lhs if I'm calling
> >> > maparg(), I need a way to determine which lhs(s) is/are ambiguous 
> >> > with a
> >> > given lhs. Mapcheck() gives me only the rhs of the conflicting map. 
> >> > To
> >> > save and restore, I'd need to know the lhs in canonical form as well.
> >>
> >> Perhaps mapcheck() could take an optional arg requesting something 
> >> more than a simple boolean return. When called with this extra arg, 
> >> mapcheck() could return a conflicting/ambiguous lhs (or list thereof) 
> >> in some canonical format (possibly determined by the value of the 
> >> extra arg itself). As long as the format returned could be fed to 
> >> maparg(), it would be possible to find conflicting mappings, remove 
> >> them temporarily, and subsequently restore them...
> >
> > If you define a mapping you will want to know whether the mapping
> > already exists and needs to be restored.  For that you can use maparg(),
> > no need to use mapcheck().
> >
> > Not sure why you would want to remove "conflicting" mappings. Perhaps
> > when you map the ; key, and the user has ;x mapped?  Then you would need
> > a list.  Adding a maplist() function would be better than adding
> > arguments to mapcheck().
>
> Yes. Very much like that. I'm implementing a sort of transient mode, in
> which I'll "shadow" existing maps with very short (generally single
> character) mappings, which are expected to be ambiguous/conflicting with
> existing maps, and even builtin operators. Of course, when I exit the
> transient mode, I'd need to restore the mappings that were shadowed.
>
> The global and builtin maps are not a problem, since the transient maps 
> use
>  and ; however, without parsing the output of one of the 
> :map
> functions, I have no way of knowing which buf-local mappings will be 
> ambiguous
> with the transient maps I'm defining. And parsing the :map output is
> problematic for the reasons already mentioned: e.g., no way to tell the
> difference between function key  and the corresponding 4 characters. 
> I'd
> actually considered taking some sort of iterative approach: e.g., trying 
> all
> possible permutations of lhs as input to maparg() and testing the 
> results, in
> an attempt to deduce the canonical form, but this would be extremely 
> messy,
> and I don't even know whether it would be deterministic... The maplist()
> function you mentioned, if it returned all ambiguous left hand sides in
> canonical form, or even a list of the corresponding maparg()-style
> dictionaries, would be perfect. Of course, there would also need to be a 
> way
> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the 
> maparg()
> or maplist() dictionary.

 OK, so for this you would use maplist() to get the list of mappings to
 disable, use maparg() to get the current mapping, clear the mapping, do
 your stuff, then restore the cleared mappings.  You then need to make
 sure you restore the mappings exactly as they were, even when your
 "stuff" fails miserably.

 It's a lot easier if we would have a way to temporarily disable
 mappings.  It's mostly the same as above, but you won't need to use
 maparg() to get the current mapping and the restore operation.  Instead
 you would disable instead of clear, and later re-enable instead of
 restore.  Still need to make sure the re-enbling does happen, no change
 in that part.
>>>
>>> Not sure I understood what exactly you suggest to disable/restore. All
>>> mappings at once with one command? I would actually disagree here: I
>>> 

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

[Brett Stahlman]

On Fri, May 26, 2017 at 4:12 PM, Nikolay Aleksandrovich Pavlov
 wrote:
> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar :
>>
>> 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 the 
>>> >> > > terminal
>>> >> > > codes replaced.  This won't work when changing the terminal type, but
>>> >> > > that is very unlikely to happen.
>>> >> >
>>> >> > You mean adding a key such as "raw_rhs" to the dictionary returned by
>>> >> > maparg()? If so, then yes this would help, but there would still need 
>>> >> > to
>>> >> > be a way to determine lhs, which is currently even more ambiguous than
>>> >> > rhs. While it's true that I probably already have lhs if I'm calling
>>> >> > maparg(), I need a way to determine which lhs(s) is/are ambiguous with 
>>> >> > a
>>> >> > given lhs. Mapcheck() gives me only the rhs of the conflicting map. To
>>> >> > save and restore, I'd need to know the lhs in canonical form as well.
>>> >>
>>> >> Perhaps mapcheck() could take an optional arg requesting something more 
>>> >> than a simple boolean return. When called with this extra arg, 
>>> >> mapcheck() could return a conflicting/ambiguous lhs (or list thereof) in 
>>> >> some canonical format (possibly determined by the value of the extra arg 
>>> >> itself). As long as the format returned could be fed to maparg(), it 
>>> >> would be possible to find conflicting mappings, remove them temporarily, 
>>> >> and subsequently restore them...
>>> >
>>> > If you define a mapping you will want to know whether the mapping
>>> > already exists and needs to be restored.  For that you can use maparg(),
>>> > no need to use mapcheck().
>>> >
>>> > Not sure why you would want to remove "conflicting" mappings. Perhaps
>>> > when you map the ; key, and the user has ;x mapped?  Then you would need
>>> > a list.  Adding a maplist() function would be better than adding
>>> > arguments to mapcheck().
>>>
>>> Yes. Very much like that. I'm implementing a sort of transient mode, in
>>> which I'll "shadow" existing maps with very short (generally single
>>> character) mappings, which are expected to be ambiguous/conflicting with
>>> existing maps, and even builtin operators. Of course, when I exit the
>>> transient mode, I'd need to restore the mappings that were shadowed.
>>>
>>> The global and builtin maps are not a problem, since the transient maps use
>>>  and ; however, without parsing the output of one of the 
>>> :map
>>> functions, I have no way of knowing which buf-local mappings will be 
>>> ambiguous
>>> with the transient maps I'm defining. And parsing the :map output is
>>> problematic for the reasons already mentioned: e.g., no way to tell the
>>> difference between function key  and the corresponding 4 characters. I'd
>>> actually considered taking some sort of iterative approach: e.g., trying all
>>> possible permutations of lhs as input to maparg() and testing the results, 
>>> in
>>> an attempt to deduce the canonical form, but this would be extremely messy,
>>> and I don't even know whether it would be deterministic... The maplist()
>>> function you mentioned, if it returned all ambiguous left hand sides in
>>> canonical form, or even a list of the corresponding maparg()-style
>>> dictionaries, would be perfect. Of course, there would also need to be a way
>>> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the 
>>> maparg()
>>> or maplist() dictionary.
>>
>> OK, so for this you would use maplist() to get the list of mappings to
>> disable, use maparg() to get the current mapping, clear the mapping, do
>> your stuff, then restore the cleared mappings.  You then need to make
>> sure you restore the mappings exactly as they were, even when your
>> "stuff" fails miserably.
>>
>> It's a lot easier if we would have a way to temporarily disable
>> mappings.  It's mostly the same as above, but you won't need to use
>> maparg() to get the current mapping and the restore operation.  Instead
>> you would disable instead of clear, and later re-enable instead of
>> restore.  Still need to make sure the re-enbling does happen, no change
>> in that part.
>
> Not sure I understood what exactly you suggest to disable/restore. All
> mappings at once with one command? I would actually disagree here: I
> need something similar for translit3, but it only remaps
> single-character mappings, leaving most of other user mappings alone.
> One mapping at a time? It would be good, but given that request is
> temporary remapping naming the functionality enable/disable looks
> strange. And there are still issues with determining {lhs}.

No. Not all maps at once. As I understood it, the maplist()
function would return a 

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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 0:12 GMT+03:00 Nikolay Aleksandrovich Pavlov :
> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar :
>>
>> 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 the 
>>> >> > > terminal
>>> >> > > codes replaced.  This won't work when changing the terminal type, but
>>> >> > > that is very unlikely to happen.
>>> >> >
>>> >> > You mean adding a key such as "raw_rhs" to the dictionary returned by
>>> >> > maparg()? If so, then yes this would help, but there would still need 
>>> >> > to
>>> >> > be a way to determine lhs, which is currently even more ambiguous than
>>> >> > rhs. While it's true that I probably already have lhs if I'm calling
>>> >> > maparg(), I need a way to determine which lhs(s) is/are ambiguous with 
>>> >> > a
>>> >> > given lhs. Mapcheck() gives me only the rhs of the conflicting map. To
>>> >> > save and restore, I'd need to know the lhs in canonical form as well.
>>> >>
>>> >> Perhaps mapcheck() could take an optional arg requesting something more 
>>> >> than a simple boolean return. When called with this extra arg, 
>>> >> mapcheck() could return a conflicting/ambiguous lhs (or list thereof) in 
>>> >> some canonical format (possibly determined by the value of the extra arg 
>>> >> itself). As long as the format returned could be fed to maparg(), it 
>>> >> would be possible to find conflicting mappings, remove them temporarily, 
>>> >> and subsequently restore them...
>>> >
>>> > If you define a mapping you will want to know whether the mapping
>>> > already exists and needs to be restored.  For that you can use maparg(),
>>> > no need to use mapcheck().
>>> >
>>> > Not sure why you would want to remove "conflicting" mappings. Perhaps
>>> > when you map the ; key, and the user has ;x mapped?  Then you would need
>>> > a list.  Adding a maplist() function would be better than adding
>>> > arguments to mapcheck().
>>>
>>> Yes. Very much like that. I'm implementing a sort of transient mode, in
>>> which I'll "shadow" existing maps with very short (generally single
>>> character) mappings, which are expected to be ambiguous/conflicting with
>>> existing maps, and even builtin operators. Of course, when I exit the
>>> transient mode, I'd need to restore the mappings that were shadowed.
>>>
>>> The global and builtin maps are not a problem, since the transient maps use
>>>  and ; however, without parsing the output of one of the 
>>> :map
>>> functions, I have no way of knowing which buf-local mappings will be 
>>> ambiguous
>>> with the transient maps I'm defining. And parsing the :map output is
>>> problematic for the reasons already mentioned: e.g., no way to tell the
>>> difference between function key  and the corresponding 4 characters. I'd
>>> actually considered taking some sort of iterative approach: e.g., trying all
>>> possible permutations of lhs as input to maparg() and testing the results, 
>>> in
>>> an attempt to deduce the canonical form, but this would be extremely messy,
>>> and I don't even know whether it would be deterministic... The maplist()
>>> function you mentioned, if it returned all ambiguous left hand sides in
>>> canonical form, or even a list of the corresponding maparg()-style
>>> dictionaries, would be perfect. Of course, there would also need to be a way
>>> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the 
>>> maparg()
>>> or maplist() dictionary.
>>
>> OK, so for this you would use maplist() to get the list of mappings to
>> disable, use maparg() to get the current mapping, clear the mapping, do
>> your stuff, then restore the cleared mappings.  You then need to make
>> sure you restore the mappings exactly as they were, even when your
>> "stuff" fails miserably.
>>
>> It's a lot easier if we would have a way to temporarily disable
>> mappings.  It's mostly the same as above, but you won't need to use
>> maparg() to get the current mapping and the restore operation.  Instead
>> you would disable instead of clear, and later re-enable instead of
>> restore.  Still need to make sure the re-enbling does happen, no change
>> in that part.
>
> Not sure I understood what exactly you suggest to disable/restore. All
> mappings at once with one command? I would actually disagree here: I
> need something similar for translit3, but it only remaps
> single-character mappings, leaving most of other user mappings alone.
> One mapping at a time? It would be good, but given that request is
> temporary remapping naming the functionality enable/disable looks
> strange. And there are still issues with determining {lhs}.
>
> One of the logical variants would be `:map  {lhs}
> {new-rhs}`/`:unmap  {lhs}`+`:map  {lhs}`, 

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

[Nikolay Aleksandrovich Pavlov]

2017-05-26 20:43 GMT+03:00 Bram Moolenaar :
>
> 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 the 
>> >> > > terminal
>> >> > > codes replaced.  This won't work when changing the terminal type, but
>> >> > > that is very unlikely to happen.
>> >> >
>> >> > You mean adding a key such as "raw_rhs" to the dictionary returned by
>> >> > maparg()? If so, then yes this would help, but there would still need to
>> >> > be a way to determine lhs, which is currently even more ambiguous than
>> >> > rhs. While it's true that I probably already have lhs if I'm calling
>> >> > maparg(), I need a way to determine which lhs(s) is/are ambiguous with a
>> >> > given lhs. Mapcheck() gives me only the rhs of the conflicting map. To
>> >> > save and restore, I'd need to know the lhs in canonical form as well.
>> >>
>> >> Perhaps mapcheck() could take an optional arg requesting something more 
>> >> than a simple boolean return. When called with this extra arg, mapcheck() 
>> >> could return a conflicting/ambiguous lhs (or list thereof) in some 
>> >> canonical format (possibly determined by the value of the extra arg 
>> >> itself). As long as the format returned could be fed to maparg(), it 
>> >> would be possible to find conflicting mappings, remove them temporarily, 
>> >> and subsequently restore them...
>> >
>> > If you define a mapping you will want to know whether the mapping
>> > already exists and needs to be restored.  For that you can use maparg(),
>> > no need to use mapcheck().
>> >
>> > Not sure why you would want to remove "conflicting" mappings. Perhaps
>> > when you map the ; key, and the user has ;x mapped?  Then you would need
>> > a list.  Adding a maplist() function would be better than adding
>> > arguments to mapcheck().
>>
>> Yes. Very much like that. I'm implementing a sort of transient mode, in
>> which I'll "shadow" existing maps with very short (generally single
>> character) mappings, which are expected to be ambiguous/conflicting with
>> existing maps, and even builtin operators. Of course, when I exit the
>> transient mode, I'd need to restore the mappings that were shadowed.
>>
>> The global and builtin maps are not a problem, since the transient maps use
>>  and ; however, without parsing the output of one of the :map
>> functions, I have no way of knowing which buf-local mappings will be 
>> ambiguous
>> with the transient maps I'm defining. And parsing the :map output is
>> problematic for the reasons already mentioned: e.g., no way to tell the
>> difference between function key  and the corresponding 4 characters. I'd
>> actually considered taking some sort of iterative approach: e.g., trying all
>> possible permutations of lhs as input to maparg() and testing the results, in
>> an attempt to deduce the canonical form, but this would be extremely messy,
>> and I don't even know whether it would be deterministic... The maplist()
>> function you mentioned, if it returned all ambiguous left hand sides in
>> canonical form, or even a list of the corresponding maparg()-style
>> dictionaries, would be perfect. Of course, there would also need to be a way
>> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the 
>> maparg()
>> or maplist() dictionary.
>
> OK, so for this you would use maplist() to get the list of mappings to
> disable, use maparg() to get the current mapping, clear the mapping, do
> your stuff, then restore the cleared mappings.  You then need to make
> sure you restore the mappings exactly as they were, even when your
> "stuff" fails miserably.
>
> It's a lot easier if we would have a way to temporarily disable
> mappings.  It's mostly the same as above, but you won't need to use
> maparg() to get the current mapping and the restore operation.  Instead
> you would disable instead of clear, and later re-enable instead of
> restore.  Still need to make sure the re-enbling does happen, no change
> in that part.

Not sure I understood what exactly you suggest to disable/restore. All
mappings at once with one command? I would actually disagree here: I
need something similar for translit3, but it only remaps
single-character mappings, leaving most of other user mappings alone.
One mapping at a time? It would be good, but given that request is
temporary remapping naming the functionality enable/disable looks
strange. And there are still issues with determining {lhs}.

One of the logical variants would be `:map  {lhs}
{new-rhs}`/`:unmap  {lhs}`+`:map  {lhs}`, but this is hard
to implement and is rather limited, though less limited then
enable/disable everything variant.

I would instead suggest a function mappings_dump()/mappings_add():
first is similar to 

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

[Brett Stahlman]

On Fri, May 26, 2017 at 12:43 PM, Bram Moolenaar  wrote:
>
> Brett Stahlman wrote:
>

%--snip--%

>>
>> Yes. Very much like that. I'm implementing a sort of transient mode, in
>> which I'll "shadow" existing maps with very short (generally single
>> character) mappings, which are expected to be ambiguous/conflicting with
>> existing maps, and even builtin operators. Of course, when I exit the
>> transient mode, I'd need to restore the mappings that were shadowed.
>>
>> The global and builtin maps are not a problem, since the transient maps use
>>  and ; however, without parsing the output of one of the :map
>> functions, I have no way of knowing which buf-local mappings will be 
>> ambiguous
>> with the transient maps I'm defining. And parsing the :map output is
>> problematic for the reasons already mentioned: e.g., no way to tell the
>> difference between function key  and the corresponding 4 characters. I'd
>> actually considered taking some sort of iterative approach: e.g., trying all
>> possible permutations of lhs as input to maparg() and testing the results, in
>> an attempt to deduce the canonical form, but this would be extremely messy,
>> and I don't even know whether it would be deterministic... The maplist()
>> function you mentioned, if it returned all ambiguous left hand sides in
>> canonical form, or even a list of the corresponding maparg()-style
>> dictionaries, would be perfect. Of course, there would also need to be a way
>> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the 
>> maparg()
>> or maplist() dictionary.
>
> OK, so for this you would use maplist() to get the list of mappings to
> disable, use maparg() to get the current mapping, clear the mapping, do
> your stuff, then restore the cleared mappings.  You then need to make
> sure you restore the mappings exactly as they were, even when your
> "stuff" fails miserably.
>
> It's a lot easier if we would have a way to temporarily disable
> mappings.  It's mostly the same as above, but you won't need to use
> maparg() to get the current mapping and the restore operation.  Instead
> you would disable instead of clear, and later re-enable instead of
> restore.  Still need to make sure the re-enbling does happen, no change
> in that part.
>
> Big advantage is that if we evern add functionality to mappings, it will
> keep working, while your save/restore pair probably fails.
>
> Ah, your later post goes in the same direction.

Yes. My thinking exactly. No need to translate back and forth between
internal and external representations if it's not too difficult to
provide a clean interface supporting sensible map operations at a
higher level.

So then maplist() would return a list of handles of some sort (rather
than a list of lhs)? I suppose the interface could even support
functions for mapping a handle to the information currently returned
in the maparg() dictionary (but perhaps with lhs/rhs in canonical
form) - unless you feel that would be leaking too much internal
state... I guess the bottom line is that if there is still a valid use
case for remapping/executing the rhs returned by maparg(), there
should probably be a way to obtain it in a more deterministic format.
E.g., I'm thinking this example (from the help on maparg()) might be
susceptible to breakage if user changes 'cpo' after mappings have been
created...

exe 'nnoremap  ==' . maparg('', 'n')

To make this sort of operation safer, the map interface could provide
an "execute" function, which would allow you to execute even a
currently disabled or shadowed map on demand. Something along the
lines of what might be achieved with maparg(), :normal!, or even
feedkeys(), but cleaner and safer. At any rate, the enable/disable
functions would suffice for the save/restore use case I described...

Thanks,
Brett S.

>
> --
> DENNIS: Look,  strange women lying on their backs in ponds handing out
> swords ... that's no basis for a system of government.  Supreme
> executive power derives from a mandate from the masses, not from some
> farcical aquatic ceremony.
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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 http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bug in ftdetect?

[Bram Moolenaar]

Christian Brabandt wrote:

> On Do, 25 Mai 2017, Bram Moolenaar wrote:
> 
> > Christian Brabandt wrote:
> > 
> > > 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 problem, although I cannot reproduce it.
> > > 
> > > The markdown syntax script sources the html syntax script and that one 
> > > does include a couple of other syntax scripts, like css.vim, 
> > > javascript.vim and also vb.vim. However from my testing vb.vim is not 
> > > guilty alone. If I uncomment vb.vim, the overall loading time only 
> > > shrinks by 0.2 seconds or so (it needs here a total of around 7 
> > > seconds). So you would need to disable all other to be included syntax 
> > > scripts as well (for a test, you could set main_syntax='java').
> > 
> > I haven't read the whole thread, but I suspect that the trick is to set
> > b:current_syntax (to anything), which will cause further syntax scripts to 
> > bail
> > out.  Anyway, this is all working around the actual problem.
> 
> Not for html, which explicitly resets b:current_syntax to be able to 
> include several other syntax scripts and even provides the main_syntax 
> global variable to make this work with other syntax scripts.

Well, it must be used somehwere to explain why making the file empty has
a different effect from only setting b:current_syntax in the file.

> > > However, I think you might have found a bug here. Your ftdetect script 
> > > does this:
> > > 
> > > autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown
> > > 
> > > The :args command does fill the argument list, calls ex_next() which 
> > > calls eventually alist_set() and then iterates over the argument list 
> > > and calls adlist_add(). This will finally call buflist_add() which in 
> > > turn calls buflist_new(), which triggers the BufNew autocommand, which 
> > > then triggers the FileType and finally the Syntax autocommands. So in 
> > > the end, we are iterating over the whole list of arguments and call 
> > > autocommands, for buffers that are not even going to be displayed next.
> > > 
> > > So I wonder, if we can't do a little bit better, similar to how vimgrep 
> > > sets the eventignore option to prevent at least the expensive FileType 
> > > autocommand:
> > 
> > I'm quite sure this will make other things fail.  Just don't use
> > BufNew for detecting the filetype, that is the cause of the problem.
> > The file type should only be detected when the buffer is loaded.
> > Doing it earlier indeed causes the overhead experienced.
> 
> Indeed, however, that doesn't mean, we shouldn't try to avoid this 
> problem. Vimgrep does the same.

Avoid what problem?  Detecting the filetype in cases it isn't used?  Not
sure how we can predict that.  For :vimgrep it's obvious, and it then
has to carefully jump to hoops later for when a buffer ends up not being
unloaded.  Probably can't be turned into a generic solution, since we
don't know what happens next.

-- 
OLD WOMAN: Well, how did you become king, then?
ARTHUR: The Lady of the Lake, her arm clad in the purest shimmering samite,
held Excalibur aloft from the bosom of the water to signify by Divine
Providence ...  that I, Arthur, was to carry Excalibur ...  That is
why I am your king!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
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 http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bram Moolenaar]

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 the 
> >> > > terminal
> >> > > codes replaced.  This won't work when changing the terminal type, but
> >> > > that is very unlikely to happen.
> >> >
> >> > You mean adding a key such as "raw_rhs" to the dictionary returned by
> >> > maparg()? If so, then yes this would help, but there would still need to
> >> > be a way to determine lhs, which is currently even more ambiguous than
> >> > rhs. While it's true that I probably already have lhs if I'm calling
> >> > maparg(), I need a way to determine which lhs(s) is/are ambiguous with a
> >> > given lhs. Mapcheck() gives me only the rhs of the conflicting map. To
> >> > save and restore, I'd need to know the lhs in canonical form as well.
> >>
> >> Perhaps mapcheck() could take an optional arg requesting something more 
> >> than a simple boolean return. When called with this extra arg, mapcheck() 
> >> could return a conflicting/ambiguous lhs (or list thereof) in some 
> >> canonical format (possibly determined by the value of the extra arg 
> >> itself). As long as the format returned could be fed to maparg(), it would 
> >> be possible to find conflicting mappings, remove them temporarily, and 
> >> subsequently restore them...
> >
> > If you define a mapping you will want to know whether the mapping
> > already exists and needs to be restored.  For that you can use maparg(),
> > no need to use mapcheck().
> >
> > Not sure why you would want to remove "conflicting" mappings. Perhaps
> > when you map the ; key, and the user has ;x mapped?  Then you would need
> > a list.  Adding a maplist() function would be better than adding
> > arguments to mapcheck().
> 
> Yes. Very much like that. I'm implementing a sort of transient mode, in
> which I'll "shadow" existing maps with very short (generally single
> character) mappings, which are expected to be ambiguous/conflicting with
> existing maps, and even builtin operators. Of course, when I exit the
> transient mode, I'd need to restore the mappings that were shadowed.
> 
> The global and builtin maps are not a problem, since the transient maps use
>  and ; however, without parsing the output of one of the :map
> functions, I have no way of knowing which buf-local mappings will be ambiguous
> with the transient maps I'm defining. And parsing the :map output is
> problematic for the reasons already mentioned: e.g., no way to tell the
> difference between function key  and the corresponding 4 characters. I'd
> actually considered taking some sort of iterative approach: e.g., trying all
> possible permutations of lhs as input to maparg() and testing the results, in
> an attempt to deduce the canonical form, but this would be extremely messy,
> and I don't even know whether it would be deterministic... The maplist()
> function you mentioned, if it returned all ambiguous left hand sides in
> canonical form, or even a list of the corresponding maparg()-style
> dictionaries, would be perfect. Of course, there would also need to be a way
> to get the rhs's canonical form: e.g., the extra "raw_rhs" key in the maparg()
> or maplist() dictionary.

OK, so for this you would use maplist() to get the list of mappings to
disable, use maparg() to get the current mapping, clear the mapping, do
your stuff, then restore the cleared mappings.  You then need to make
sure you restore the mappings exactly as they were, even when your
"stuff" fails miserably.

It's a lot easier if we would have a way to temporarily disable
mappings.  It's mostly the same as above, but you won't need to use
maparg() to get the current mapping and the restore operation.  Instead
you would disable instead of clear, and later re-enable instead of
restore.  Still need to make sure the re-enbling does happen, no change
in that part.

Big advantage is that if we evern add functionality to mappings, it will
keep working, while your save/restore pair probably fails.

Ah, your later post goes in the same direction.

-- 
DENNIS: Look,  strange women lying on their backs in ponds handing out
swords ... that's no basis for a system of government.  Supreme
executive power derives from a mandate from the masses, not from some
farcical aquatic ceremony.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_use" maillist.
Do not top-post! Type 

Re: Bug in ftdetect?

[Christian Brabandt]

On Do, 25 Mai 2017, Bram Moolenaar wrote:

> Christian Brabandt wrote:
> 
> > 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 problem, although I cannot reproduce it.
> > 
> > The markdown syntax script sources the html syntax script and that one 
> > does include a couple of other syntax scripts, like css.vim, 
> > javascript.vim and also vb.vim. However from my testing vb.vim is not 
> > guilty alone. If I uncomment vb.vim, the overall loading time only 
> > shrinks by 0.2 seconds or so (it needs here a total of around 7 
> > seconds). So you would need to disable all other to be included syntax 
> > scripts as well (for a test, you could set main_syntax='java').
> 
> I haven't read the whole thread, but I suspect that the trick is to set
> b:current_syntax (to anything), which will cause further syntax scripts to 
> bail
> out.  Anyway, this is all working around the actual problem.

Not for html, which explicitly resets b:current_syntax to be able to 
include several other syntax scripts and even provides the main_syntax 
global variable to make this work with other syntax scripts.

> 
> > However, I think you might have found a bug here. Your ftdetect script 
> > does this:
> > 
> > autocmd BufNew,BufNewFile,BufRead *.md :set filetype=markdown
> > 
> > The :args command does fill the argument list, calls ex_next() which 
> > calls eventually alist_set() and then iterates over the argument list 
> > and calls adlist_add(). This will finally call buflist_add() which in 
> > turn calls buflist_new(), which triggers the BufNew autocommand, which 
> > then triggers the FileType and finally the Syntax autocommands. So in 
> > the end, we are iterating over the whole list of arguments and call 
> > autocommands, for buffers that are not even going to be displayed next.
> > 
> > So I wonder, if we can't do a little bit better, similar to how vimgrep 
> > sets the eventignore option to prevent at least the expensive FileType 
> > autocommand:
> 
> I'm quite sure this will make other things fail.  Just don't use
> BufNew for detecting the filetype, that is the cause of the problem.
> The file type should only be detected when the buffer is loaded.
> Doing it earlier indeed causes the overhead experienced.

Indeed, however, that doesn't mean, we shouldn't try to avoid this 
problem. Vimgrep does the same.

Best,
Christian
-- 
Am Ende ist alles ein Witz.
-- Charlie Chaplin

-- 
-- 
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 http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim startup profiling

[Ken Takata]

Hi,

2017/5/24 Wed 17:39:34 UTC+9 Ni Va wrote:
> 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 problem, often guard [1] like guard
> > > has been setup which is a quick workraound which immediately saves most
> > > time.
> > > 
> > > Marc Weber
> > > 
> > > [1]
> > > 
> > >   if exists("loaded_")
> > > finish
> > >   endif
> > >   let loaded_ = 1
> > > 
> > >   
> > 
> > Ok this one seems better than vundle and save me 100ms at startup but I dig.
> > https://github.com/junegunn/vim-plug
> > 
> > Thank you Marc !
> 
> 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

> 096.000  047.000  044.000: sourcing D:\Logiciels\Vim\vim80/menu.vim
> 096.000  072.000  025.000: sourcing D:\Logiciels\Vim\vim80\filetype.vim

menu.vim uses `globpath()` to search some kind of files under the runtimepath.
If you search `globpath` in menu.vim, you may find the following lines:

  let s:n = globpath(, "colors/*.vim")
let s:n = globpath(, "keymap/*.vim")
  let s = globpath(, "spell/*." . enc . ".spl")
  let s:n = globpath(, "compiler/*.vim")

Color schemes, keymaps, spell files and compiler plugins are searched when
menu.vim is loaded.
This is why it takes long time to be loaded.

Unlike those items, file types are not listed automatically.  If a user
selects "Syntax" -> "Show File Types in Menu", they will be listed.
If we use a similar way for color schemes etc., the startup time would be
reduced.

Regards,
Ken Takata

-- 
-- 
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 http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_use+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.