Re: Questions about mapping information

[Nikolay Aleksandrovich Pavlov]

2018-03-21 10:34 GMT+03:00 Lifepillar :
> I am trying to debug an issue with my plugin (µcomplete) and auto-pairs,
> and I have a couple of questions about the way Vim displays information
> about mappings.
>
> I have these definitions in my vimrc:
>
> imap MyCR (MUcompleteCR)
> imap  MyCR
>
> Auto-pairs maps , too, and it tries hard not to override an existing
> mapping. After loading, :verbose imap  shows this:
>
> i  &@(MUcompleteCR)24_AutoPairsReturn
>  Last set from ~/.vim/pack/bundle/start/auto-pairs/plugin/auto-pairs.vim
>
> iMyCR
>  Last set from ~/.vim/vimrc
>
> I think auto-pairs expands the current mapping and appends its own
> definition.
>
> First question: why are there two definitions instead of one? I.e., why
> is the mapping from my vimrc shown at all?

Due to buffer-local mappings there may exist at most {number of loaded
buffers present}+1 mapping definitions, with buffer-local mappings
attached to the current buffer taking precedence over global mapping
definition and buffer-local mappings attached to other buffers
ignored.

>
> Second question: what does &@ mean in the first definition?

There is `:h map-listing` which explains both. You could found that by
searching for `&` after `:h :map`; though there are some mishits.

>
> For the record, the issue is that, with those definitions in place,
> when I type , Vim inserts (MUcompleteCR) literally in the
> buffer, although that plug exists.
>
> Thanks,
> Life.
>
> --
> --
> 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.

-- 
-- 
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: Prevent the use of italic

[Nikolay Aleksandrovich Pavlov]

2018-03-02 19:06 GMT+03:00 Oliver Knodel :
> Am Freitag, 2. März 2018 08:37:21 UTC+1 schrieb Anton Shepelev:
>> Hello, all
>>
>> I  am using GVim with a font that has no italic sub-
>> set.  When I edit markdown (.md) files, however, Vim
>> tries  to  render  *emphasized* text as italic.  How
>> can I prevent that?  Is it  configured  in  a  color
>> file or a syntax file?
>>
>> --
>> Please, do not forward replies to the list to my e-mail.
>
> It is set in the syntax/markdown file and links to htmlItalic:
> markdownItalic xxx links to htmlItalic
>
> You can override it in ~/.vim/after/syntax/html.vim:
> hi htmlItalic gui=NONE
>
> If you use vim inside terminal, substitute gui with term or cterm.

There is no need to use after/ directory, and especially after/syntax
which will be constantly reloaded. Sane syntax file authors (and
html.vim other is one of those) define highlight groups with
`:highlight default` which means that if highlighting group is defined
*before* sourcing syntax file then it will not be overridden, so
placing something like `hi link htmlItalic Normal` into the
colorscheme (if it is maintained by the OP) or vimrc is good and will
not create uselessly reloaded oneline files. Usage of the `:highlight
default` in syntax files aims precisely at allowing colorschemes to
provide defaults better suited to the user.

>
> --
> --
> 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.

-- 
-- 
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: making custom key names for mappings

[Nikolay Aleksandrovich Pavlov]

2018-02-26 4:20 GMT+03:00 Renato Fabbri :
> Em sexta-feira, 23 de fevereiro de 2018 15:51:35 UTC-3, ZyX  escreveu:
>> 2018-02-23 18:21 GMT+03:00 Renato Fabbri:
>> > Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX  escreveu:
>> >> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
>> >> > Well, from your comments, i put a:
>> >> >
>> >> > let g:aall = mapleader
>> >> > " let mapleader = ''
>> >> > if exists("g:aa_leader")
>> >> >   let mapleader = g:aa_leader
>> >> > el
>> >> >   let mapleader = 'anything'
>> >> > en
>> >> >
>> >> >
>> >> > before the mappings, and a:
>> >> >
>> >> > let mapleader = g:aall
>> >> >
>> >> > after them and it is all ok.
>> >> > (only these mappings use the
>> >> > temporarily defined leader key.)
>> >> >
>> >> > I did not understand how SourcePre
>> >> > would be used.
>> >> > Something like:
>> >> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = 
>> >> > ['something', mapleader]
>> >> >
>> >> > in combination with a somewhat SourcePost event to
>> >> > set mapleader to fooleader?
>> >>
>> >> No, you set mapleader for *all* scripts, either to default or to
>> >> something else. There is no SourcePost for some reason; an alternative
>> >> is messing with SourceCmd, but this is harder to do right in general,
>> >> but easier to use for specific use cases.
>> >
>> > hum... try this:
>> > let mapleader = 'a'
>> > nn j :ec 'a banana'
>> > let mapleader = 'b'
>> > nn j :ec 'an apple'
>> > let mapleader = 'a'
>> > nn k :ec 'an orange'
>> >
>> > which work 100% fine here.
>>
>> I do not understand what you are trying to say. I know that ``
>> is expanded only once, but that is not helpful: SourcePre is run only
>> before some script, so if your script is not the last one you have to
>> create SourcePre command which will set mapleader to one value for
>> your script and to another value for everything else.
>
> so that I understand what you are saying
> (I apologize if being slow),
> does this sequence of commands
> have the expected behavior in your Vim:
>
> " {{{ should make aj ec banana, bj ec apple, ak ec orange, bk not mapped:
> let mapleader = 'a'
> nn j :ec 'a banana'
> let mapleader = 'b'
> nn j :ec 'an apple'
> let mapleader = 'a'
> nn k :ec 'an orange'
> " }}}

I know what mappings this will result in. I do not understand how this
sequence is *relevant* to the discussion.

>
>>
>> > ((
>> > :version
>> > VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan  6 2018 23:48:57)
>> > Included patches: 1-1428
>> > Compiled by renato@xps
>> > Huge version without GUI.
>> > )) + python 2-3 and termguicolors
>> >
>> >
>> >>
>> >> >
>> >> > Anyway, I understood that it is not needed to define
>> >> > extra  key names, but is it possible within Vim standard
>> >> > capabilities?
>> >>
>> >> What is possible? All XXX in `` are defined at compile time only,
>> >> you can’t evaluate expression inside XXX or something like this.
>> >
>> > Ok, so question closed here.
>> > Notice that  is surely not completely
>> > defined in compile time, for we use
>> > g:mapleader to set  at run time.
>> >
>> > Am I following things right?
>>
>> You cannot change semantics of `` or e.g. evaluate `mapleader`
>> as an expression, so this fact is not helpful. And you also can’t add
>> any new keys. So “not completely” is not very helpful.
>
> exe g:mapleader
> evaluates mapleader as an expression, but I don't see the case to do this.

:let g:mapleader = '(expand("") =~# ''\mmyscript\.vim$''?"a":"b"')'

will not make `` expand to `a` for `myscript.vim` and `b` for
everything else.

>
> let mapleader += 'banana'
> should work to add new keys, but I again fail to see the point.

Neither there is a way to create `` key in runtime.

>
> "not completely" there is in the sense of being dependent also on
> the scripts/commands parsed at runtime, not at compile time.
> Apologies for not being palpable.
>
>>
>> >
>> >>
>> >> >
>> >> >
>> >> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX  escreveu:
>> >> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> >> >> > leader and localleader are the standard, so one might
>> >> >> > have conflicts between scripts because
>> >> >> > all of them use leader and localleader.
>> >> >> >
>> >> >> > how would you define, say
>> >> >> > , which you set to the
>> >> >> > leader by default,
>> >> >> > but can be changed to any key
>> >> >> > sequence (including c-v derived).
>> >> >> >
>> >> >> > ==
>> >> >> > ideally, I would have a command mkKeyName with which to define
>> >> >> >  such as
>> >> >> >
>> >> >> > :mkKeyName -default=leader coolleader
>> >> >> >
>> >> >> > and might set it to anything such as
>> >> >> > se mapcoolleader=^[
>> >> >> > se mapcoolleader=
>> >> >> > se mapcoolleader!
>> >> >> > se mapcoolleader!=
>> >> >> >
>> >> >> > (this implies that one would also able to use
>> >> >> > :setlocal mapcoolleader ??
>> >> >> >
>> >> >> > and use it in your mappings
>> >> >> > as in
>> >> >> > nnoremap B :call 

Re: making custom key names for mappings

[Nikolay Aleksandrovich Pavlov]

2018-02-23 18:21 GMT+03:00 Renato Fabbri :
> Em quinta-feira, 22 de fevereiro de 2018 22:05:29 UTC-3, ZyX  escreveu:
>> 2018-02-23 1:43 GMT+03:00 Renato Fabbri:
>> > Well, from your comments, i put a:
>> >
>> > let g:aall = mapleader
>> > " let mapleader = ''
>> > if exists("g:aa_leader")
>> >   let mapleader = g:aa_leader
>> > el
>> >   let mapleader = 'anything'
>> > en
>> >
>> >
>> > before the mappings, and a:
>> >
>> > let mapleader = g:aall
>> >
>> > after them and it is all ok.
>> > (only these mappings use the
>> > temporarily defined leader key.)
>> >
>> > I did not understand how SourcePre
>> > would be used.
>> > Something like:
>> > au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', 
>> > mapleader]
>> >
>> > in combination with a somewhat SourcePost event to
>> > set mapleader to fooleader?
>>
>> No, you set mapleader for *all* scripts, either to default or to
>> something else. There is no SourcePost for some reason; an alternative
>> is messing with SourceCmd, but this is harder to do right in general,
>> but easier to use for specific use cases.
>
> hum... try this:
> let mapleader = 'a'
> nn j :ec 'a banana'
> let mapleader = 'b'
> nn j :ec 'an apple'
> let mapleader = 'a'
> nn k :ec 'an orange'
>
> which work 100% fine here.

I do not understand what you are trying to say. I know that ``
is expanded only once, but that is not helpful: SourcePre is run only
before some script, so if your script is not the last one you have to
create SourcePre command which will set mapleader to one value for
your script and to another value for everything else.

> ((
> :version
> VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jan  6 2018 23:48:57)
> Included patches: 1-1428
> Compiled by renato@xps
> Huge version without GUI.
> )) + python 2-3 and termguicolors
>
>
>>
>> >
>> > Anyway, I understood that it is not needed to define
>> > extra  key names, but is it possible within Vim standard
>> > capabilities?
>>
>> What is possible? All XXX in `` are defined at compile time only,
>> you can’t evaluate expression inside XXX or something like this.
>
> Ok, so question closed here.
> Notice that  is surely not completely
> defined in compile time, for we use
> g:mapleader to set  at run time.
>
> Am I following things right?

You cannot change semantics of `` or e.g. evaluate `mapleader`
as an expression, so this fact is not helpful. And you also can’t add
any new keys. So “not completely” is not very helpful.

>
>>
>> >
>> >
>> > Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX  escreveu:
>> >> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> >> > leader and localleader are the standard, so one might
>> >> > have conflicts between scripts because
>> >> > all of them use leader and localleader.
>> >> >
>> >> > how would you define, say
>> >> > , which you set to the
>> >> > leader by default,
>> >> > but can be changed to any key
>> >> > sequence (including c-v derived).
>> >> >
>> >> > ==
>> >> > ideally, I would have a command mkKeyName with which to define
>> >> >  such as
>> >> >
>> >> > :mkKeyName -default=leader coolleader
>> >> >
>> >> > and might set it to anything such as
>> >> > se mapcoolleader=^[
>> >> > se mapcoolleader=
>> >> > se mapcoolleader!
>> >> > se mapcoolleader!=
>> >> >
>> >> > (this implies that one would also able to use
>> >> > :setlocal mapcoolleader ??
>> >> >
>> >> > and use it in your mappings
>> >> > as in
>> >> > nnoremap B :call MyCoolFunction()
>> >>
>> >> This is not needed, there is `:execute` as something requiring changes
>> >> to plugin code. E.g. my plugins (on my frawor framework) allow
>> >> defining plugin-specific leader.
>> >>
>> >> To override `mapleader` for plugins which are not nice enough to allow
>> >> defining plugin-specific leader there is SourcePre event.
>> >>
>> >> I personally find mapleader and maplocalleader as quite *incomplete*
>> >> thing. For plugins much better idea would be key-value store: e.g. in
>> >> place of
>> >>
>> >> nnoremap (FooPluginDoBar) :call foo#bar()
>> >> nnoremap (FooPluginDoZab) :call foo#zab()
>> >>
>> >> nmap fb (FooPluginDoBar)
>> >> nmap fz (FooPluginDoZab)
>> >>
>> >> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write 
>> >> just
>> >>
>> >> mapdefineprefix FooPlugin f
>> >> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()
>> >> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()
>> >>
>> >> and Vim will handle actually substituting values like this: each
>> >> `<:prefix:mapname(default)>` expands into a concat of two strings:
>> >>
>> >> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to 
>> >> `prefix`.
>> >> 2. The rhs of the first `:mapdefine` command or the `default` value if
>> >> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
>> >> issued. Inside `default` `<>` are good as long as they are balanced,
>> >> various special characters like `)` may be entered via something like
>> >> 

Re: making custom key names for mappings

[Nikolay Aleksandrovich Pavlov]

2018-02-23 1:43 GMT+03:00 Renato Fabbri :
> Well, from your comments, i put a:
>
> let g:aall = mapleader
> " let mapleader = ''
> if exists("g:aa_leader")
>   let mapleader = g:aa_leader
> el
>   let mapleader = 'anything'
> en
>
>
> before the mappings, and a:
>
> let mapleader = g:aall
>
> after them and it is all ok.
> (only these mappings use the
> temporarily defined leader key.)
>
> I did not understand how SourcePre
> would be used.
> Something like:
> au SourcePre mymappings.vim let [g:fooleader, mapleader] = ['something', 
> mapleader]
>
> in combination with a somewhat SourcePost event to
> set mapleader to fooleader?

No, you set mapleader for *all* scripts, either to default or to
something else. There is no SourcePost for some reason; an alternative
is messing with SourceCmd, but this is harder to do right in general,
but easier to use for specific use cases.

>
> Anyway, I understood that it is not needed to define
> extra  key names, but is it possible within Vim standard
> capabilities?

What is possible? All XXX in `` are defined at compile time only,
you can’t evaluate expression inside XXX or something like this.

>
>
> Em quinta-feira, 22 de fevereiro de 2018 18:22:51 UTC-3, ZyX  escreveu:
>> 2018-02-22 18:58 GMT+03:00 Renato Fabbri:
>> > leader and localleader are the standard, so one might
>> > have conflicts between scripts because
>> > all of them use leader and localleader.
>> >
>> > how would you define, say
>> > , which you set to the
>> > leader by default,
>> > but can be changed to any key
>> > sequence (including c-v derived).
>> >
>> > ==
>> > ideally, I would have a command mkKeyName with which to define
>> >  such as
>> >
>> > :mkKeyName -default=leader coolleader
>> >
>> > and might set it to anything such as
>> > se mapcoolleader=^[
>> > se mapcoolleader=
>> > se mapcoolleader!
>> > se mapcoolleader!=
>> >
>> > (this implies that one would also able to use
>> > :setlocal mapcoolleader ??
>> >
>> > and use it in your mappings
>> > as in
>> > nnoremap B :call MyCoolFunction()
>>
>> This is not needed, there is `:execute` as something requiring changes
>> to plugin code. E.g. my plugins (on my frawor framework) allow
>> defining plugin-specific leader.
>>
>> To override `mapleader` for plugins which are not nice enough to allow
>> defining plugin-specific leader there is SourcePre event.
>>
>> I personally find mapleader and maplocalleader as quite *incomplete*
>> thing. For plugins much better idea would be key-value store: e.g. in
>> place of
>>
>> nnoremap (FooPluginDoBar) :call foo#bar()
>> nnoremap (FooPluginDoZab) :call foo#zab()
>>
>> nmap fb (FooPluginDoBar)
>> nmap fz (FooPluginDoZab)
>>
>> (last two possibly surrounded by `if !hasmapto(…)|endif`) one would write 
>> just
>>
>> mapdefineprefix FooPlugin f
>> nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()
>> nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()
>>
>> and Vim will handle actually substituting values like this: each
>> `<:prefix:mapname(default)>` expands into a concat of two strings:
>>
>> 1. The rhs of the first `:mapdefineprefix` command with lhs equal to 
>> `prefix`.
>> 2. The rhs of the first `:mapdefine` command or the `default` value if
>> no `:mapdefine` commands with lhs equal to `prefix:mapname` were
>> issued. Inside `default` `<>` are good as long as they are balanced,
>> various special characters like `)` may be entered via something like
>> ``.
>>
>> In both cases using bang clears the prefix, so next non-banged command
>> will define it (normally it is ignored).
>>
>> E.g. in this case if user wants mappings of foo plugin start with `,o`
>> and not `f` all he needs would be putting
>>
>> mapdefineprefix FooPlugin ,o
>>
>> into the vimrc (requirement: before sourcing actual plugin). If
>> additionally he thinks that `DoZab` command is easier to run with
>> `,oo` he would need
>>
>> mapdefine FooPlugin:DoZab o
>>
>> (requirement is the same).
>>
>> Currently plugins may do this on top of `:execute`, but nobody
>> bothers. I normally want this functionality to e.g. make NERDCommenter
>> mappings all start with `,c` (no, redefining `` for all
>> plugins does not sound like a good idea; `SourcePre` is useful, but
>> still feels like a hack) or “undefine” (i.e. prefix with something you
>> would never type, e.g. `XXXIWouldNeverTypeThisXXX`) mappings for
>> plugins I install for functionality other then mappings (not everybody
>> is nice enough to have g:NERDCreateDefaultMappings setting).
>>
>> >
>> > thanks again,
>> >
>> >
>> > --
>> > Renato Fabbri
>> > GNU/Linux User #479299
>> > labmacambira.sourceforge.net
>> >
>> > --
>> > --
>> > 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" 

Re: making custom key names for mappings

[Nikolay Aleksandrovich Pavlov]

2018-02-22 18:58 GMT+03:00 Renato Fabbri :
> leader and localleader are the standard, so one might
> have conflicts between scripts because
> all of them use leader and localleader.
>
> how would you define, say
> , which you set to the
> leader by default,
> but can be changed to any key
> sequence (including c-v derived).
>
> ==
> ideally, I would have a command mkKeyName with which to define
>  such as
>
> :mkKeyName -default=leader coolleader
>
> and might set it to anything such as
> se mapcoolleader=^[
> se mapcoolleader=
> se mapcoolleader!
> se mapcoolleader!=
>
> (this implies that one would also able to use
> :setlocal mapcoolleader ??
>
> and use it in your mappings
> as in
> nnoremap B :call MyCoolFunction()

This is not needed, there is `:execute` as something requiring changes
to plugin code. E.g. my plugins (on my frawor framework) allow
defining plugin-specific leader.

To override `mapleader` for plugins which are not nice enough to allow
defining plugin-specific leader there is SourcePre event.

I personally find mapleader and maplocalleader as quite *incomplete*
thing. For plugins much better idea would be key-value store: e.g. in
place of

nnoremap (FooPluginDoBar) :call foo#bar()
nnoremap (FooPluginDoZab) :call foo#zab()

nmap fb (FooPluginDoBar)
nmap fz (FooPluginDoZab)

(last two possibly surrounded by `if !hasmapto(…)|endif`) one would write just

mapdefineprefix FooPlugin f
nnoremap <:FooPlugin:DoBar(b)> :call foo#bar()
nnoremap <:FooPlugin:DoZab(z)> :call foo#zab()

and Vim will handle actually substituting values like this: each
`<:prefix:mapname(default)>` expands into a concat of two strings:

1. The rhs of the first `:mapdefineprefix` command with lhs equal to `prefix`.
2. The rhs of the first `:mapdefine` command or the `default` value if
no `:mapdefine` commands with lhs equal to `prefix:mapname` were
issued. Inside `default` `<>` are good as long as they are balanced,
various special characters like `)` may be entered via something like
``.

In both cases using bang clears the prefix, so next non-banged command
will define it (normally it is ignored).

E.g. in this case if user wants mappings of foo plugin start with `,o`
and not `f` all he needs would be putting

mapdefineprefix FooPlugin ,o

into the vimrc (requirement: before sourcing actual plugin). If
additionally he thinks that `DoZab` command is easier to run with
`,oo` he would need

mapdefine FooPlugin:DoZab o

(requirement is the same).

Currently plugins may do this on top of `:execute`, but nobody
bothers. I normally want this functionality to e.g. make NERDCommenter
mappings all start with `,c` (no, redefining `` for all
plugins does not sound like a good idea; `SourcePre` is useful, but
still feels like a hack) or “undefine” (i.e. prefix with something you
would never type, e.g. `XXXIWouldNeverTypeThisXXX`) mappings for
plugins I install for functionality other then mappings (not everybody
is nice enough to have g:NERDCreateDefaultMappings setting).

>
> thanks again,
>
>
> --
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
>
> --
> --
> 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.

-- 
-- 
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: CTRL-[ == ALT == ESC to Vim? (or how to make them different)

[Nikolay Aleksandrovich Pavlov]

2018-02-21 14:51 GMT+03:00 Renato Fabbri :
> That is what I get when typing with
>  in insert mode.
>
>
> (((
>
> " C-V C-[
> " C-V A-x
> x
>
> " C-V 
> echo " " == " " == " "
> echo ' ' == ' ' == ' '
> )))
> where this strange symbol appears as ^[ here,
> and x seems to be any key.
>
> In summary, C-[ and ESC equivalent, as somewhat
> expected, and Alt is prepends an ESC to any key.
> So, for example, if I make an insert-mode mapping
>
> inoremap A-Y :echo 'a banana'
>
> it will make the insert mode wait for a next letter after ESC (or C-[),
> which I bypass with a command such as:
> inoremap [ :up
> BTW. A-Y does not work here to write the imap,
> I have to enter it by typing C-V A-Y.
>
> BTW2. I hope these unusual chars don't mess your
> emails as it is messing here (not writing it in Vim though..).
>
> Is there a way to make ALT and ESC distinct?
> (ok about ESC == CTRL-[).

You did not state what are you using exactly, this is essential to
answer a question. If you are using Vim in a terminal emulator then
you may need to ask *in terminal emulator’s mailing list* first
because Vim has no choice, but to swallow whatever terminal emulator
throws at it. Ability to get help here in this case would depend on
whether there are enough advanced users of your terminal emulator
reading vim_use.

Note that normally terminal emulators have a setting allowing to use
either `` or the eighth bit for `
> Best,
> rf
>
> --
> Renato Fabbri
> GNU/Linux User #479299
> labmacambira.sourceforge.net
>
> --
> --
> 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.

-- 
-- 
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: vimdiff - how to jump to next difference in long line - shortcut ]c does not work

[Nikolay Aleksandrovich Pavlov]

2018-02-21 12:43 GMT+03:00 Igor Forca :
> @ZyX, I did:
> 1. Start-up Vim in clean:
> gvim -u NONE -N
>
> 2. Open the first file:
> :e file1.txt
>
> 3. Diff mode second file:
> :vert diffsp file2.txt
>
> 4. Do the mapping you suggested:
> nnoremap a ]c
>
> 5. Press the a key and nothing happens.
>
> So still a problem.
>
> By the way if mappings would be the problem then ]c shortcut should be 
> working out of the box because I have run gVim in: "gvim -u NONE -N" clean 
> environment.

(Environment would be clean with `-i NONE` as well. But it should not
matter here, I know no way for viminfo file to define a mapping.)

>
> Any other idea?

Some other ideas:

1. Check whether `c` is an ASCII `c` by using `ga` with cursor over it
(first typing that in some file, of course). Same for `]`. If keyboard
is actually a problem then typing `]c` when defining mapping is just
as good as just typing `]c`. Though I do not see any problems in your
email.
2. Based on my observations a “change” is “block of changed lines not
interleaved with non-changed lines”. E.g. when I did `vimdiff` on
README.md and CMakeLists.txt from Neovim repository I saw that Vim
registered only two changes there: first line (README)/first two lines
(CMakeLists.txt) and everything else (the only non-changed line in
this case was a blank second (README)/third (CMakeLists) line). In the
example `]c` is only capable of jumping from the first few lines and
from nowhere else. Also `]c` will not bring you to the first change if
current change is the last one: it does not wrap.

   This problem should be immediately visible though.
3. Check what other diff command do in your case. Specifically, what
`:diffget` changes, maybe it will yield some hints.

Also AFAIK Windows may have some problems with diff.exe availability,
but it is supposed to be shipped with Vim and you would definitely see
the problem just after `:diffsplit` if that was the case.

>
> --
> --
> 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.

-- 
-- 
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: vimdiff - how to jump to next difference in long line - shortcut ]c does not work

[Nikolay Aleksandrovich Pavlov]

2018-02-21 11:45 GMT+03:00 Igor Forca :
> Hi,
> I have files with long lines and when doing diff it is time consuming to move 
> to the diff change (marked red in vimdiff).
>
> I have searched the help:
> :h jumpto-diffs
>
> With explanation that:
> ]c
> should jump to the next start of the change.
>
> But in my case this key shortcut does nothing.
>
> I started gVim on Windows 7 with command:
> gvim -u NONE -N
> and key shortcut still does not work.
>
> Maybe this is related to my keyboard (Slovenian keyboard):
> See keyboard layout: https://gate2home.com/Slovenian-Keyboard
> I have to press  to get ] key.
>
> Any idea what is wrong? Any workaroud?
> I tried to use mapping like:
> :map a ]c
> and when pressing a nothing happens.

You should not be ever using `map` unless you can say “I need a
mapping in select mode because … and I need my mapping trigger other
mappings because …”. `]c` may not work not because of keyboard, but
*because of mappings*. Use `nnoremap` to check; `nnoremap`, `xnoremap`
and `onoremap` when defining actual mapping for other modes.

>
> My gVim is v8.0.1529 witch is latest nightly build for win32 from:
> https://github.com/vim/vim-win32-installer/releases/download/v8.0.1529/gvim_8.0.1529_x64.zip
>
> --
> --
> 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.

-- 
-- 
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: build dict key:val from map list and substitute

[Nikolay Aleksandrovich Pavlov]

2018-02-20 22:52 GMT+03:00 Ni Va :
> Hi,
>
> map(copy(totaltimelist)[0:10], 'substitute(v:val, linepat, "\\1 : \\2", "")')
>
> Two values as backward ref are retrieved from a mapped list but I would like 
> to use :
> - first value \\1 as dict.key
> - second value \\2 is added to dict[key].values = [\\2,...,..]
>
>
> How doing this into first map( function above ?

You need to use `\=` as a replacement with `submatch(1)` for `\1`.
Expressions after `\=` are fully capable of side-effects, though I
should say that unless there are performance requirements replacing
`map()` with `:for` would be more readable. Also unless you do need
`substitute()` results it is better to discard `substitute()` and use
`matchlist()`, putting side-effects in the top-level expression thus
saving another level of escaping. Though most likely you would need
`extend(l:, …)` to create temporary variables in this case, as I said
earlier lambdas are not good for performance.

Ah, and you must remove `copy()`. What you are doing here is creating
a copy of a list, slicing it (thus creating *another* list) and
immediately discarding the list created by `copy()`.

>
> Thank in advance
> Nicolas
>
> --
> --
> 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.

-- 
-- 
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: substitue( optimize

[Nikolay Aleksandrovich Pavlov]

2018-02-14 11:31 GMT+03:00 Ni Va <nivaem...@gmail.com>:
> Entirely agree with your VimL principle : less command is fast/better, inner
> system apis... Principle that works for any Language.

Not actually. What I mean here is that you should use VimL expressions
where normally you would use commands: `let [a, b] = [1, 2]` should be
a bit faster then `let a = 1|let b = 2`, though both are semantically
equivalent and first even allocates a list to be disposed of when
command finishes. In many cases this reasoning applies to `call
map(copy(list), …)` vs `for val in list`, sometimes even if `for`
variant contains `:break` command while `map()` obviously can’t.

The principle may be reworded as “parsing VimL expressions is far
faster then parsing VimL commands”. Reasoning is simple: in modern
scripting languages code follows the path

source code ---(parser)--> AST ---(translator)--> bytecode[
---(compiler)--> machine code]

Only after undergoing all these translations code is actually
executed. In VimL there is no parser, no translator and no compiler.
Vim just stores source code strings (possibly with some minor
conversions like reencoding (:h :scriptencoding) or joining lines (:h
line-continuation)) and executes them as they are parsed, never
storing parsing results in any format for future executions. Thus
while in other programming languages equivalent commands and
expressions will produce nearly the same or even identical
byte/machine code, no matter how parsing commands is more/less
complicated then parsing expressions (if there is separate between
commands and expressions at all), in VimL you pay a price for parsing
command every time you execute it and commands parser is just slower
(`map()` vs `:for`), in addition to the fact that “one big expression
with side-effects” approach in many cases means that you need to call
expressions parser single time vs multiple times for multiple commands
with the same effect.

>
> Out the fact that it is not here a xml treenode parser but inlines binary
> file modifications, do you think modifying large xml file (1Million line
> 40Mo) can be as fast as libxml (ox ruby, python) or xpath parser ?

For the above reasons (no parser and no translator) VimL can never
hope to achieve performance comparable to a C library. This may change
in Neovim as I am working on adding parser and translator after some
time, but work is going rather slowly; currently there only is parser
for expressions and it is only used for command-line highlighting (I
mean, highlighting expressions in `=` and the like prompts): no
translator is available and neither there is code that executes AST
without translating.

>
> 2018-02-14 9:20 GMT+01:00 Nikolay Aleksandrovich Pavlov <zyx@gmail.com>:
>>
>> 2018-02-14 10:41 GMT+03:00 Ni Va <nivaem...@gmail.com>:
>> > Le mardi 13 février 2018 14:30:38 UTC+1, Luc Hermitte a écrit :
>> >> Hello Nicholas,
>> >>
>> >> > After reading a file and getting 1 million lines' List, I need to
>> >> > make similar substitutions over matched lines ~500 times with this
>> >> > func:
>> >> >
>> >> >
>> >> > fun! foo#set_new_val(ressource) abort "{{{
>> >> >
>> >> >   " position
>> >> >   let pos  = foo#getpos_ress(a:ressource)
>> >> >   let pres = foo#geth_presence(a:ressource)
>> >> >   let s:xml[pos] = substitute(s:xml[pos],'false\|true',pres,"")  <<<
>> >> >   HERE
>> >> >
>> >> >   " Slave/Voie01 to Voie08
>> >> >   for idx in [1,2,3,4,5,6,7,8]   <<< HERE
>> >> > let pos = foo#getpos_ress(a:ressource.'/bar0'.string(idx))
>> >> > let s:xml[pos] = substitute(s:xml[pos],'false\|true',pres,"")
>> >> > <<<
>> >> > HERE
>> >> >   endfor
>> >> >
>> >> > endfu"}}}
>> >> >
>> >> >
>> >> > 1/ Can I optimize this function ?
>> >>
>> >> So far my experiments on the subject taught me that we are best
>> >> avoiding :for and :while constructs when performances matter.
>> >> If you can use map() instead, do!
>> >>
>> >> HTH,
>> >>
>> >> --
>> >> Luc Hermitte
>> >
>> > Yess Luc !
>> >
>> > I finally reached to the same conclusion.
>> >
>> > 1/ But mapping Dict or List, inside the substitute func is needed no ?
>> > 2/ Other point, passing by register with emmbedded pattern is it faster
>> > ?
>> >
>> >   let @a = '\w\+\(<\/PRES\)

Re: substitue( optimize

[Nikolay Aleksandrovich Pavlov]

2018-02-14 10:41 GMT+03:00 Ni Va :
> Le mardi 13 février 2018 14:30:38 UTC+1, Luc Hermitte a écrit :
>> Hello Nicholas,
>>
>> > After reading a file and getting 1 million lines' List, I need to
>> > make similar substitutions over matched lines ~500 times with this
>> > func:
>> >
>> >
>> > fun! foo#set_new_val(ressource) abort "{{{
>> >
>> >   " position
>> >   let pos  = foo#getpos_ress(a:ressource)
>> >   let pres = foo#geth_presence(a:ressource)
>> >   let s:xml[pos] = substitute(s:xml[pos],'false\|true',pres,"")  <<<
>> >   HERE
>> >
>> >   " Slave/Voie01 to Voie08
>> >   for idx in [1,2,3,4,5,6,7,8]   <<< HERE
>> > let pos = foo#getpos_ress(a:ressource.'/bar0'.string(idx))
>> > let s:xml[pos] = substitute(s:xml[pos],'false\|true',pres,"")<<<
>> > HERE
>> >   endfor
>> >
>> > endfu"}}}
>> >
>> >
>> > 1/ Can I optimize this function ?
>>
>> So far my experiments on the subject taught me that we are best avoiding 
>> :for and :while constructs when performances matter.
>> If you can use map() instead, do!
>>
>> HTH,
>>
>> --
>> Luc Hermitte
>
> Yess Luc !
>
> I finally reached to the same conclusion.
>
> 1/ But mapping Dict or List, inside the substitute func is needed no ?
> 2/ Other point, passing by register with emmbedded pattern is it faster ?
>
>   let @a = '\w\+\(<\/PRES\)'
>   let @b = pres.'\1'
>
>   call map(voies_no, 'substitute(s:xml[v:val],"\=@a","\=@b","")')

Using registers here makes no sense, you can just use variables. `\=`
is not going to work like you typed here. For loop with preceding
substitute from original function look like they can be rewritten into

call map(
\[a:ressource] + map(range(1, 8), 'a:ressource."/bar0".v:val'),
\'extend(
\s:xml, {
\extend(l:, {"pos": foo#getpos_ress(v:val)}).pos
\: substitute(s:xml[pos],''\c\vfalse|true'',pres,"")})')

Note that my main VimL optimization principle is “less commands is
better”. “Avoid loops” is one of the special cases only: by “less
commands” I mean not “less commands in code”, but “less commands to
execute”. I used to write a `:while` loop which contained nothing, but
conditional expression and all the work was done there (`extend(l:,
{})`, list literals as a replacement for comma operator and no
optimizer messing with sequence points rock (until you need to debug
this mess)). Note that for this reason lambdas (with the current
implementation) are a no-go: they create functions with `return`
command. If you need optimization and you have a choice between lambda
and some kind of `eval()` (e.g. map string literal) then use `eval()`.

>
>
> Thanks 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 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.

-- 
-- 
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: Glob filename containing { (left brace) in Windows

[Nikolay Aleksandrovich Pavlov]

2018-02-11 21:44 GMT+03:00 Lifepillar :
> Is there any way for glob() to expand a filename containing
> { (left brace) in Windows *without* removing { from isfname?
>
> For example, if the current dir has a file called '{foo', then
>
>   :echo glob('\{*')
>
> correctly expands to '{foo' provided that isfname does not
> contain {; otherwise, the above gives E220: missing }.
>
> There is an example in `:h wildcard`, but it uses square brackets
> and I am not sure how it could be adapted.

It looks like your issue has the same source as $-related parts of
https://github.com/vim/vim/issues/541 (no resolution there though).

>
> Thanks,
> Life.
>
> --
> --
> 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.

-- 
-- 
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: Writing tests for completion

[Nikolay Aleksandrovich Pavlov]

2018-02-05 23:31 GMT+03:00 Lifepillar :
> I would like to automate the testing of my completion plugin,
> so I have started to write functions like this (I am using
> a test framework like the one in Vim):
>
> fun! Test_buffer_keyword_completion()
>   new
>   set completeopt=menuone,noselect
>   call feedkeys("ajump ju", "x")
>   call assert_equal("jump jump", getline(1))
>   bwipe!
> endf
>
> This test passes (using `vim --clean`), but if I feed this
> key sequence instead:
>
>   call feedkeys("ajump ju", "x")
>
> the test fails:
>
>   Expected 'jump jump' but got 'jump ju'
>
> Why is that? If I try the key sequences manually, both give the
> same result.

To emulate user input you must add `t` to the flags, there are some
differences between handling input from user and input from mappings
and without `t` you are emulating the latter. I could not list all the
differences though.

>
> Thanks,
> Life.
>
> --
> --
> 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.

-- 
-- 
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: Print to PDF (and open in browser)

[Nikolay Aleksandrovich Pavlov]

2018-01-27 13:29 GMT+03:00  :
> Hello (sorry for my poor English),
>
> I need to send a lot of emails (50-70) from lists everyday and I had found a 
> good way to save my time pasting the list to Writer, exporting it to pdf, 
> opening pdf in chromium and going directly to Gmail when I click on the links.
>
> Then I started to learn Vim (few months ago) and I found a new way to do the 
> job with one command: in my .vimrc I put the following remap
>
> "PRINT TO PDF / PRINT AND OPEN TO CHROMIUM
> nmap  :ha > newfile.ps  :! ps2pdf newfile.ps:! rm 
> newfile.ps
> nmap  :ha > newfile.ps  :! ps2pdf newfile.ps:! rm 
> newfile.ps && chromium newfile.pdf
>
> So, in the first line I put the command to create a PDF.
> In the second line I create PDF and open it to chromium (Debian is my OS, and 
> Chromium is my default and favorite browser).
> Then, as above, I click on the addresses in PDF document and go directly to 
> Gmail, which is my default email "client" (ok, it's not a client but I set it 
> to be the default email).
>
> The only problem is that I have to rename "newfile" to a different name 
> everytime. It's not a dramatic issue indeed, but...
>
> My questions:
>
> 1) Is there a more elegant or effective way to do the same things?
>
> 2) Is there a way to open an email address from VIM and land in Gmail without 
> creating  a PDF? In Vim I open urls using gx but it doesn't work with email 
> addresses.

f...@bar.baz looks much like going to bar.baz via http protocol (or
https in some cases due to HSTS), using user foo: you may check
https://en.wikipedia.org/wiki/URL#Syntax: side from omitting a
protocol this is a valid URL interpretation and http/https is the
default one. You should be able to do what is needed if you add
`mailto:` before emails so chromium would know what exactly you need.

>
> 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.
> 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.

-- 
-- 
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: :terminal mode ques

[Nikolay Aleksandrovich Pavlov]

2017-12-29 17:30 GMT+03:00 M Kelly :
>> > Off course you can. Type CTRL+\ CTRL+N and the terminal buffer will become 
>> > a regular buffer without ending the job. Then you can yank, mark or do 
>> > whatever you need.
>> >
>> >
>> > To go back to Terminal mode just type A.
>>
>> ok, yes, but this is more effort than before.  In more detail, if I am in a 
>> non-vim shell I can type cd then click on a dir with the mouse and click 
>> again to paste and its there.  In vim terminal mode I would like to do the 
>> same, if it is at all possible I am not sure.  In a vim terminal I can type 
>> cd then c-\ c-n then hold the mouse and drag across the dir then type i/a 
>> then paste but it would be really awesome if I could use typical shell/term 
>> mouse events when in vim terminal mode.
>
> Maybe go into visual mode (ie c-\ c-n) with a mouse click and then go back to 
> terminal mode with another click ??

 goes to normal mode, not visual. And you should be able to
use :tnoremap to remap mouse clicks as well, though I have not tested
that. There are some examples for other modes in `:h mouse-using`.

>
>
> --
> --
> 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.

-- 
-- 
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: location of vim rc files and directories. Making them relocatable.

[Nikolay Aleksandrovich Pavlov]

2017-11-25 19:17 GMT+03:00 Jose Caballero :
> Hi,
>
> this is a quick question about how to modify my .vimrc and all my
> plugins so I can copy all of them to different hosts (under different
> usernames) and still work.
>
> I have all of them (vimrc and all plugin directories) in a github account.
> So my intention is, when I login to a remote host -either root or any
> other user account-, I would like to clone that account, and being
> able to keep using them.
> I don't want to place them under the usual locations (~/.vimrc and
> ~/.vim) because, as mentioned, sometimes I log as root, on a shared
> host, so I cannot interfere with others.
>
> So basically I want to place the files under /tmp/, for example.
> However, I have things hardcoded in the files. Things like this:
>
>autocmd BufNewFile *.py :-1read ~/.vim/templates/emptypython
>
> So I would like to know if there is a mechanism, like an env var or
> similar, to avoid using hardcoded absolute paths, and make everything
> relative.
>
> googling, I got that I can use -u to point to .vimrc. That solves part
> of the problem.
> But I still need a way to make the rest of them relative.
> Which key word should I search for?

:h 

>
>
> Thanks a lot in advance,
> Jose
>
> --
> --
> 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.

-- 
-- 
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: python 3

[Nikolay Aleksandrovich Pavlov]

2017-11-25 3:09 GMT+03:00 Shidong Wang :
> no need to install python3.5 ， just set the value of pythonthreedll.

It is not going to work properly if Vim was compiled with python 3.5.
Python version Vim was compiled with and Python version actually used
must match, Python’s n.i and n.j are generally not ABI-compatible.

>
> 发自我的华为手机
>
>  原始邮件 
> 主题：Re: python 3
> 发件人：Ni Va
> 收件人：vim_use
> 抄送：
>
> Le vendredi 24 novembre 2017 14:58:17 UTC+1, andalou a écrit :
>> On 24/11/2017 03:46 a.m., rameo wrote:
>>  > On Wednesday, November 22, 2017 at 11:31:10 PM UTC+1, Ni Va wrote:
>>  >> Hi,
>>  >>
>>  >> Just try from vim.8.0.1330 to execute :py3 import sys (with python
>> v3.7.0a2) fails and exit vim.
>>  >>
>>  >>
>>  >> May I miss some things to do?
>>  >> Thank you
>>  >
>>  > You're using Python 3.7.
>>  > Vim is made for Python 3.5.
>>  > You need to install Python 3.5 (32 bits or 64 bits (the same as your
>>  > Vim version))
>>  >
>>
>> That's not true. I'm using vim 8.1333 with Python 3.6.3 on Windows 7.
>>
>> --
>> Cesar
>
> Effectively Windows 10, vim.8.0.1333, both python 2.7 and 3.7.0 are
> installed.
> Problem always here.
>
> --
> --
> 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.
>
> --
> --
> 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.

-- 
-- 
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 surprisingly slow?

[Nikolay Aleksandrovich Pavlov]

2017-11-16 16:35 GMT+03:00 Tim Chase :
> On 2017-11-16 08:03, Christian Brabandt wrote:
>> On the other hand, we can not fsync() at the end of the `:g`
>> command, because at that time, we would not have a filehandle to
>> fsync().
>
> I suppose one could gather the file-handles used during the :g
> command and then issue one fsync() for each of them when finished.
>
> Pseudocode something like
>
>   filehandle_set = set()
>
>   def begin_global_command():
> filehandle_set.clear()
>
>
>   def deferrable_fsync(fp):
> if in_a_global_command():
>   filehandle_set.add(fp)
> else:
>   fsync(fp)
>
>   def end_global_command():
> for fp in filehandle_set:
>   fsync(fp)
> filehandle_set.clear()
>
>> I suppose skipping the fsync() would be okay in this edge case
>> for :g command and trust, that the kernel will write the changes to
>> disk. The only problem would be a system crash or power failure but
>> I believe this is relatively unlikely.
>
> Alternatively, it might just be enough to document that ":w" also
> does an fsync() and might be slow, while writefile() doesn't issue
> fsync() and could be faster. For me it was as much the surprise as
> anything else.

I do not much like that, when I found that  does not apply to
writefile() I wrote a patch (for Neovim). Had to write another one
shortly after though: with a new flags that unconditionally
disable/enable fsync() call to fight a slowdown for a few plugins
where it does matter.

>
> -tim
>
>
>
> --
> --
> 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.

-- 
-- 
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 surprisingly slow?

[Nikolay Aleksandrovich Pavlov]

2017-11-16 8:43 GMT+03:00 Dominique Pellé :
> Dominique Pellé  wrote:
>
>>  Christian Brabandt  wrote:
>>
>>> On Mi, 15 Nov 2017, Dominique Pellé wrote:
>>>
>>> > As highlighted in red, notice that we only write 179,281 bytes to file
>>> > "20150425.txt" but we open/write/close/fsync 5004 times.
>>> > That repeated I/O patterns kills performance, especially because
>>> > of the frequent fsync().
>>> >
>>> > We also read 1,612,897 bytes from data.json, but that should be
>>> > fast since we do only 27 read and opened that file only twice
>>> > according to output of io.pl. Vim reads file deta.json by chunks
>>> > of 64 KB. 1,612,897 bytes is exactly the file size of data.json.
>>> >
>>> > Maybe we can change vim to avoid the constant open/write/close/fsync
>>> > on file "20150425.txt" which should speed it up greatly.
>>>
>>> Thanks for this nice analysis. It is probably the fsync call that is
>>> slowing Vim down. We can avoid the fsync by disabling the 'fsync'
>>> option. Also we might want to disable the writebackup option just in
>>> case it matters. And finally, when a file is written in a different
>>> encoding, Vim will try to check if conversion is safe by first trying to
>>> convert the buffer contents to the fileencoding before writing the file.
>>> That might make also a difference when encoding differs from the file
>>> encoding.
>>>
>>> Perhaps it makes sense to skip fsyncing while being busy in a `:g`
>>> command. Tim, does this patch make a difference?
>>>
>>> diff --git a/src/fileio.c b/src/fileio.c
>>> index d991822c3..eb626a675 100644
>>> --- a/src/fileio.c
>>> +++ b/src/fileio.c
>>> @@ -4731,7 +4731,7 @@ restore_backup:
>>>  * work (could be a pipe).
>>>  * If the 'fsync' option is FALSE, don't fsync().  Useful for 
>>> laptops.
>>>  */
>>> -   if (p_fs && fsync(fd) != 0 && !device)
>>> +   if (p_fs && !global_busy && fsync(fd) != 0 && !device)
>>> {
>>> errmsg = (char_u *)_("E667: Fsync failed");
>>> end = 0;
>>
>>
>> Hi Christian
>>
>> I measured the same command twice before and after your patch:
>>
>> Before patch:
>>
>> $ time ./vim  -u NONE data.json  -S new_engine.vim
>> real0m15.533s
>> user0m1.648s
>> sys0m0.824s
>>
>> $ time ./vim  -u NONE data.json  -S new_engine.vim
>>
>> real0m15.444s
>> user0m1.636s
>> sys0m0.820s
>>
>> After patch:
>>
>> $ time ./vim  -u NONE data.json  -S new_engine.vim
>>
>> real0m0.741s
>> user0m0.536s
>> sys0m0.200s
>>
>> $ time ./vim  -u NONE data.json  -S new_engine.vim
>>
>> real0m0.731s
>> user0m0.548s
>> sys0m0.184s
>>
>> So your patch makes it more than 20 times faster
>> on my Linux machine. Nice! Hopefully it's safe to
>> avoid fsync() in this case.
>
> I have not had the time to look in details, but the
> patch is wrong.  After patch, running the command with
> strace, I do not see any fsync() calls anymore.  I thought
> that the idea of the patch was to avoid intermediate fsync()
> but still fsync() at the end of the command.  But since

No, this is hard (impossible if you consider that command may modify
following text so that it will not match) to determine in the middle
of the global command whether it is going to run once more, so the
patch which intends to do something like this will have to do
something like caching file descriptors and emptying cache at the end,
additionally calling fsync().

> there is no fsync() call anymore, it's not safe.
>
> Regards
> Dominique
>
> --
> --
> 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.

-- 
-- 
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 surprisingly slow?

[Nikolay Aleksandrovich Pavlov]

2017-11-15 16:57 GMT+03:00 Tim Chase :
> On 2017-11-15 08:25, Christian Brabandt wrote:
>> On Mi, 15 Nov 2017, Dominique Pellé wrote:
>> > As highlighted in red, notice that we only write 179,281 bytes to
>> > file "20150425.txt" but we open/write/close/fsync 5004 times.
>> > That repeated I/O patterns kills performance, especially because
>> > of the frequent fsync().
> [snip]
>> > Maybe we can change vim to avoid the constant
>> > open/write/close/fsync on file "20150425.txt" which should speed
>> > it up greatly.
>
> However, my understanding is that the writefile() method should be
> doing the same thing (open, append, close) and that's as fast as I
> expect.  Though I could be wrong and writefile() might internally
> cache the file handle.
>
>> Thanks for this nice analysis. It is probably the fsync call that
>> is slowing Vim down. We can avoid the fsync by disabling the
>> 'fsync' option.
>
> Does the writefile() method does an fsync() too?  If not, it's a
> strong indicator that the fsync() may be part of the guilty slowness.

Does not, not in Vim. In Neovim this is governed by both  option
(by default it is respected) and additional s/S flags pair which
allows one to select a bit safer option vs faster option.

>
> If the writefile() version does an fsync() we may be barking up the
> wrong tree.
>
> I'll test the patch later today when I'm not about to run out the
> door.
>
> Thanks!
>
> -tim
>
>
>
> --
> --
> 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.

-- 
-- 
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: , , , , key notation in Vim documentation

[Nikolay Aleksandrovich Pavlov]

2017-11-10 19:31 GMT+03:00 'Andy Wokula' via vim_use :
> Am 10.11.2017 um 13:55 schrieb Renato Fabbri:
>>
>> I did not find explicitly in the manual,
>> e.g. in :h key-notation, so...
>>
>> does anyone know if there is any difference in:
>> , , 
>> for Vim?
>
>
> It's all the same, and the preferred notation is `'.
>
> But at least for gVim, `' is different from `'.
>
>> Also, when can one use A-C-S combinations?
>>
>> PS.  has the alias , right?
>
>
> ` `' is different from `'.
>
> Problem is, the Alt-combinations are normal characters and
> often come in the way.  And the :map output prints these
> characters instead of `'.
>
> And on Windows, Alt- also accesses the menu
> (sometimes I use the menu).
>
> On the plus side, the Alt combinations are otherwise completely free to use
> (no conflicts with builtin keys).
>
> Some experts may have more to say on the issue ...

On my linux desktops all `
> --
> Andy
>
>
> --
> --
> 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.

-- 
-- 
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: How to handle non-ascii characters?

[Nikolay Aleksandrovich Pavlov]

2017-10-21 19:39 GMT+03:00  :
> On Sat, Oct 21, 2017 at 08:43:23AM -0700, Barry Gold wrote:
>> Background: I write  documents in MS Word, but my target format is HTML. 
>> After
>> I do a Save as "Web Page (filtered)", I can use global replaces to get rid of
>> most of the cruft that Word generates, but I have a problem with non-ASCII
>> characters: cent sign, circle-r, dash, nbsp, etc.
>>
>> None of these looks like themselves when I edit the file with vim in a cygwin
>> Terminal window. I can search for [^ -~^t] to find the non-ASCII characters,
>> then go to the original word document to find out what the correct character
>> is. If I had only a few of these, that would be enough. But in a longer
>> document, a given non-ASCII can occur hundreds of times. So once I've found
>> (e.g.) an emdash, I want to replace _all_ occurrences with  "". But I
>> have no way of representing the character I want to replace on the command
>> line.
>>
>> I usually bring up the HTML file in Emacs so I can tell it to do a replace 
>> all
>> on the character. I know emacs sort-of, but every time I want to do anything
>> more than basic editing I have to look up the commands I want with ^hapropos.
>> Is there a way to do this in vim without getting into emacs.
>>
>> Note: ^t is what a tab character looks like on the vim command line.
>
>  I sometimes deal with something a bit similar. For
> example if I want to change all the fancy "right single
> quote" marks from a Windows file into a plain apostrophe,
> "'" I use 'ga' on the first found character (the fancy
> quote) to see that the code is U+2019. Then I search for
> that, using \%u2019.
>  Would that help?

Using `yl` to yank the character and `"` to paste it into the
command-line should be faster.

>
>  John Cordes
>
>
>
> --
> --
> 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.

-- 
-- 
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.

Small puzzler

[Nikolay Aleksandrovich Pavlov]

Hello, I have a small puzzler for you: describe all messages which the
below code may possibly yield depending on what you substitute for `^`
and `^^`, assuming that first may only be either zero or one and
second may only be a dictionary {}, dictionary {'a': 1} or number 2.

(Preferably do this without actually running, there are only six
combinations under given conditions after all.)

:function Foo(...)
:  let cond = ^
:  let dict = ^^
:  echo cond?dict.a:0|echo 3
:endfunction
:call Foo()

-- 
-- 
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: Lost in formatoptions …

[Nikolay Aleksandrovich Pavlov]

2017-10-01 21:43 GMT+03:00 Nikolay Aleksandrovich Pavlov <zyx@gmail.com>:
> 2017-10-01 14:01 GMT+03:00 Matěj Cepl <mc...@cepl.eu>:
>> Hi,
>>
>> trying to use vim for writing long prose and I am playing with
>> the optimal value for formatoptions. Currently I have
>>
>>  set formatoptions=1tcroqlav
>>
>> but I think I have something wrong.  Somehow 'a' is too active
>> to me and I am in the situation that I cannot split a paragraph
>> in the middle. When I enter one CR, the line splits, but when
>> I press ENTER again, nothing happens. I have to set paste, make
>> change, set nopaste and reformat, which is obviously wrong.
>>
>> What do I do wrong?
>
> You are trying to use `a` without `w`. Using trailing whitespaces is
> the only sane variant of using `a`  flag, other variants
> are too restrictive and thus utterly broken.
>
>>
>> Best,
>>
>> Matěj
>> --
>> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
>> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>>
>> As a rule of thumb, the more qualifiers there are before the name
>> of a country, the more corrupt the rulers. A country called The
>> Socialist People's Democratic Republic of X is probably the last
>> place in the world you'd want to live.
>>  -- Paul Graham discussing (not only) Nigerian spam
>> (http://www.paulgraham.com/spam.html)
>>
>> --
>> --
>> 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.

-- 
-- 
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: Lost in formatoptions …

[Nikolay Aleksandrovich Pavlov]

2017-10-01 14:01 GMT+03:00 Matěj Cepl :
> Hi,
>
> trying to use vim for writing long prose and I am playing with
> the optimal value for formatoptions. Currently I have
>
>  set formatoptions=1tcroqlav
>
> but I think I have something wrong.  Somehow 'a' is too active
> to me and I am in the situation that I cannot split a paragraph
> in the middle. When I enter one CR, the line splits, but when
> I press ENTER again, nothing happens. I have to set paste, make
> change, set nopaste and reformat, which is obviously wrong.
>
> What do I do wrong?

You are trying to use `a` without `w`. Using trailing whitespaces is
the only sane variant of using `a`  flag, other variants
are too restrictive and thus utterly broken.

>
> Best,
>
> Matěj
> --
> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> As a rule of thumb, the more qualifiers there are before the name
> of a country, the more corrupt the rulers. A country called The
> Socialist People's Democratic Republic of X is probably the last
> place in the world you'd want to live.
>  -- Paul Graham discussing (not only) Nigerian spam
> (http://www.paulgraham.com/spam.html)
>
> --
> --
> 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.

-- 
-- 
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: How to scroll back in Vim's built-in terminal?

[Nikolay Aleksandrovich Pavlov]

2017-10-01 21:28 GMT+03:00 Tony Mechelynck :
> On Sun, Oct 1, 2017 at 7:24 PM, Redesorr  wrote:
>> Hello,
>> I am using Vim's built-in ":terminal", it works well.
>>
>> However, I found it is impossible to scroll back in this terminal.
>>
>> I have tried several terminal emulators and Gvim. But none of them can let 
>> me scroll back in terminal opened by ":terminal" command.
>>
>> I tried SHIFT+PgUp and Ctrl+Shift+UP, both failed. And I don't find any 
>> information about scroll back in ":terminal" in Vim's document.
>>
>> Is there any way to scroll text in Vim's ":terminal"?
>>
>
> I haven't much experimented with Vim's new +terminal feature, but I
> remember how it was before, with the !something, :shell, etc.
> commands.
>
> In that case, Console Vim let you interact with the terminal it was
> started from, with just something like "Hit Enter to continue" at the
> end, but what you got (and IIUC still get) in gvim is a "dumb"
> terminal, which emulates the kind of paper-hammer-ribbon
> teletypewriter which could neither backspace nor move up the paper but
> only move forward and down. So unless gvim's new +terminal feature is
> radically different from what it used to run shells in before
> +terminal came around, the answer to your question could quite well be
> "In gvim there isn't, and in Console Vim you get what you started Vim
> from".

+terminal uses libvterm which is xterm-compliant to a great extent, it
has nothing to do with what was there previously. To scroll back one
just needs to exit to normal mode and scroll there using regular
scrolling commands, e.g. via ``.

>
> Best regards,
> Tony.
>
> --
> --
> 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.

-- 
-- 
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: libvterm color palette

[Nikolay Aleksandrovich Pavlov]

2017-09-24 0:36 GMT+03:00 Bram Moolenaar :
>
> Marcin Szamotulski wrote:
>
>> Is there a way to redefine color palette used by the `:terminal`
>> (libvterm)?
>
> No, but you can use RGB colors ('termguicolors').

I remember this issue popping up in Neovim bug tracker and it was
found that while libvterm provides a way to alter RGB of first sixteen
colors, what Neovim then allows to do as well (BTW, does Vim allow
that?), rest of the palette is not only non-overridable, but uses a
rather rough approximation that does not quite match colors used by
xterm and adopted by other terminals.

That is a single function though which maps color indexes to RGB
colors and can easily be fixed in Vim codebase since it does not have
libvterm as a dependency, but have it merged into its codebase
instead.

>
> --
> hundred-and-one symptoms of being an internet addict:
> 185. You order fast food over the Internet
>
>  /// 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.

-- 
-- 
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: new tool lib conflict with gvim lib

[Nikolay Aleksandrovich Pavlov]

2017-09-18 2:50 GMT+03:00 Sand Glass :
> I install a new tool, and I export the LD lib.
> 
> export 
> LD_LIBRARY_PATH="/opt/Xilinx/Vivado/2016.3/lib/lnx64.o:"$LD_LIBRARY_PATH
> 
>
> But my gvim cannot launch.
> 
> /usr/bin/gvim: /opt/Xilinx/Vivado/2016.3/lib/lnx64.o/libstdc++.so.6: version 
> `CXXABI_1.3.8' not found (required by 
> /usr/lib/x86_64-linux-gnu/libicuuc.so.55)
> 
>
> My gvim linked lib is replaced by Xilinx lib.
> So Xilinx tool can not run with gvim at the same time. Now I split the 
> .bashrc file as two. one basic env include gvim(.bashrc_basic), another only 
> include xilinx env(.bashrc_xil). When I run xilinx tool, I open a new cmd 
> window, and source .bashrc_xil, this window only run xilinx tool. The action 
> can solve my problem.
>
> Is there another way makes me run xilinx tool and gvim the same time in same 
> cmd window?

Create a wrapper function/alias/script around your tool which will run

LD_LIBRARY_PATH=/opt/Xilinx/Vivado/2014.3/lib your-xilinx-tool

, e.g. like adding

alias your-xilinx-tool="LD_LIBRARY_PATH=/opt/Xilinx/Vivado/2014.3/lib
your-xilinx-tool"

to the bashrc.

Given the nature of the message you are seeing it is extremely bad
idea to run *anything*, but xilinx tool with that LD_LIBRARY_PATH:
given that they override at least some system shared libraries any
application using overridden libraries may malfunction, not only gvim,
and possibly not only by refusing to work at all.

And I would suggest to contact whoever packaged xilinx tools, I have
seen software like this (coming with their own libs) placed in /opt
and corresponding packages *already come with a wrapper script* which
do exactly that (plus sometimes with more modifications to environment
and/or argument list) without requiring user to modify environment on
their own. But first search your xilinx package for preexisting
wrappers, maybe you are using what you are not supposed to use
directly.

>
> --
> --
> 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.

-- 
-- 
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: need help with regex and matchlist()

[Nikolay Aleksandrovich Pavlov]

2017-09-02 23:06 GMT+03:00 Lifepillar :
> On 02/09/2017 19:46, Jose Caballero wrote:
>>
>> Hi,
>>
>> As this is my first time I try to write a vimscript function that uses
>> regular expressions, I am a little bit of lost. Not sure which
>> built-in function is the most proper, and/or how to use it.
>>
>> Let's say I have this line (very familiar for python developers):
>>
>>  def __init__(self, x, y, z):
>>
>> I am trying to parse that line and end up with a list of input
>> options, like this
>>
>> ['x', 'y', 'z']
>>
>> Any tip will be more than appreciated.
>> Thanks a lot in advance,
>
>
> I'd use a combination of matchstr() and split(), e.g.:
>
> let s = 'def __init__(self, x, y, z):'
> echo split(matchstr(s, 'def.*(\s*self,\s*\zs.*\ze\s*)'), '\s*,\s*')
>
> The regex uses \zs and \ze to delimit the substring of the match
> to return, but you might also use a subgroup enclosed between
> \( and \).

matchstr() does not ignore , so that needs to be at least

echo split(matchstr(s, '\Cdef.*(\s*self,\s*\zs.*\ze\s*)'), '\s*,\s*')

(note \C).

But note that regex is not a proper tool for this job: e.g. given
regex is not able to handle annotations, default values or multiline
function signatures. Handling such things is generally not possible
with Vim regexes at all: Vim regexes can’t match balanced parenthesis
and this is required to handle both annotations and default values
properly. Better use Vim with +python[3] or a Python script
communicated with either by older system() or newer job API: Python
both provides `ast` module to parse its code and higher-level things
like `getargspec()` function from `inspect` module.

>
> Life.
>
>
> --
> --
> 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.

-- 
-- 
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: autocmd! followed by

[Nikolay Aleksandrovich Pavlov]

2017-08-20 21:53 GMT+03:00 'Andy Wokula' via vim_use :
> Am 19.08.2017 um 08:17 schrieb Lifepillar:
>>
>> It seems impossible to have autocmd! followed by another command, i.e.:
>>
>> autocmd! some_group | 
>>
>> According to `:help autocmd`, autocmd may be followed by another command
>> when the '|' appears before {cmd}. This does not seem to be the case for
>> autocmd!. Is that intentional?
>
>
> Help says "this works":
> :augroup mine | au! BufRead | augroup END
>
> but it doesn't (augroup "mine" still active afterwards), thus it can't be
> intentional and you found a bug.
>
> Also not working:
> :augroup mine | au! BufRead *| augroup END
> " `*|' is taken as autocmd-{pat}, `augroup END' becomes {cmd}
>
> :augroup mine | au! BufRead * | augroup END
> " uses `| augroup END' for {cmd}
>
> Weird that it went unnoticed for so long, probably because most people
> instead use
> :au! mine BufRead
>
> I think Vim should make anything after `:au' part of the command.
> `:au' is already listed under `:h :bar' without further notice.

I second this, there already are at least five variants of handling
command separator (bar), comment start (double quote) and escaping
characters. Let’s not make rules surrounding bar/dquote/backslash even
more weird by adding an exception.

>
> --
> Andy
>
>
> --
> --
> 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.

-- 
-- 
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: source or load an autoload script

[Nikolay Aleksandrovich Pavlov]

2017-08-18 11:13 GMT+03:00 Ni Va :
> Le jeudi 17 août 2017 22:55:13 UTC+2, Christian Brabandt a écrit :
>> On Do, 17 Aug 2017, Ni Va wrote:
>>
>> > Hi,
>> >
>> >
>> > I'am writing a plugin with autoload part:
>> > myplugin\autoload\myplugin.vim
>> >
>> >
>> > A Command mapped on a function of this autoload/myplugin.vim.
>> >
>> >
>> >
>> > I don't know other solution that quit vim and relaunch to source my 
>> > modifications.
>>
>> I don't understand what problem you are trying to solve.
>>
>>
>> Best,
>> Christian
>> --
>> Es liegt in der menschlichen Natur, vernünftig zu denken und unlogisch
>> zu handeln.
>
> OK. My problem is that I don't see effect when I modify a vimscript.
> In the joined screen, you can see two vimscript. The right one is a 'class' 
> instanciated in the left one. Then a simple command MK call MakeMyVim.
>
> So, if I modify my vimscritp class and launch MK command, I don't see effect 
> of my change as if it was not sourced.
>
> Thank you by advance.

You need to :source autoload file yourself, :unletting guard variable
before sourcing. But note that this is generally incorrect, e.g. if
you remove some function from autoload file, but forget to remove it
from the users of the file, then function will stay in memory and
users will still work, up until you restart Vim.

Thus in any case restart Vim before publishing the modified script.

>
> --
> --
> 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.

-- 
-- 
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: does VIM read OK the tags file if ctags was installed after VIM?

[Nikolay Aleksandrovich Pavlov]

2017-08-17 22:04 GMT+03:00 Jose Caballero :
> 2017-08-17 14:51 GMT-04:00 Gary Johnson :
>> On 2017-08-17, Jose Caballero wrote:
>>
>>> In both cases, after trying a tag, :ts gives me the same, similar to
>>>
>>># pri kind tag file
>>>   1 F C iStatusInterface  plugins/status/Plugin.py
>>>from interfaces import StatusInterface
>>>   2 F   cStatusInterface  interfaces.py
>>>class StatusInterface(object):
>>>
>>> And, indeed, typing the number opens the right file, as it was
>>> supposed to work with CTRL+]
>>>
>>> It is like the actual command CTRL+] is the one that is not working in
>>> one of the hosts, but the tags information has been read by VIM and
>>> it's reachable via :ts
>>
>> You could execute
>>
>> :verbose map 
>>
>> where those are all printable characters and not a literal CTRL-],
>> to see if there is a mapping for CTRL-] and if it exists, where it
>> is defined.
>>
>> Regards,
>> Gary
>>
>
> Thanks for the tip.
> At this point, I need to do a little bit of googling, as I am not sure
> how to interpret the results.
>
> :verbose map 
> No mapping found
>
> :nmap
> n  [m  *@:call 22_Python_jump('?^\s*\(class\|def\)')
> n  [[  *@:call 22_Python_jump('?^\(class\|def\)')
> n  ]m  *@:call 22_Python_jump('/^\s*\(class\|def\)')
> n  ]]  *@:call 22_Python_jump('/^\(class\|def\)')
> n  gxNetrwBrowseX
> n  NetrwBrowseX * :call netrw#NetrwBrowseX(expand(""),0)
>
>
> Here the problem is simply my lack of knowledge, I have homework to do.
> Thanks anyways to everyone for your time and tips.
>
> Cheers,
> Jose

One of the other things which may affect  is  setting:
check `:verbose set iskeyword?`. Note that  setting is
likely to be the culprint if presence of certain non-alphanumeric
characters (e.g. underscore) makes tag not possible to find: any sane
configuration for non-esoteric languages will include a-zA-Z0-9 in


>
> --
> --
> 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.

-- 
-- 
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: "real" shell in window?

[Nikolay Aleksandrovich Pavlov]

2017-08-16 5:01 GMT+03:00 Cesar Romani <cesar.rom...@gmail.com>:
> On 11/08/2017 01:12 a.m., Nikolay Aleksandrovich Pavlov wrote:
>> 2017-08-09 23:25 GMT+03:00 ANDY KENNEDY<andy.kenn...@adtran.com>:
>>> All,
>>>
>>> First, thanks Christian for adding me back to the list ;).
>>>
>>> Is there a way in Vim to open a :vs, then launch some sort of shell in
>>> that window?
>>>
>>> I found a couple of different plugins that appear to be loosely what I
>>> want, but I would rather have something that has been pushed back to
>>> the Vim.
>>
>> :terminal opens terminal emulator in a new window in Vim, in the
>> current window in Neovim. In Vim this functionality is new and
>> unstable, in Neovim it is much more established.
>
> I downloaded the stable version, 0.2.1, of Neovim for Windows.
> I did :terminal and it didn't work!
> It opens a cmd terminal, and it freezes. You cannot input any command!

On Windows :terminal is not supported yet, though there is an
unfinished PR which fixes that. <C-\> to quit terminal mode to
:bwipe opened buffer should still work. In Vim this is in master;
though I can’t compare stability of
https://github.com/neovim/neovim/pull/7007 to Vim Windows :terminal
support, latter definitely has more users.

>
>
> --
> --
> 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.

-- 
-- 
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: Silently edit a buffer

[Nikolay Aleksandrovich Pavlov]

2017-08-15 21:56 GMT+03:00 Dmitry Zotikov :
> Dear all,
>
> what would be the best way to silently edit a buffer? In particular, I want
> to
> be able to write the content of a variable to it, as well as to delete all
> of
> its content.
>
> The story goes, I'm writing a plugin that among other things reads from a
> network socket using Vim 8 channels and jobs; this is the corresponding
> call:
>
> call job_start(command_cmd, {'out_io': 'buffer', 'out_name': '_out'})
>
> The problem is that on the other side of the socket there's a server process
> which doesn't append a newline after it finishes its write. Consequently,
> reading from the channel set to NL mode would always leave one line of input
> in
> the socket, and so I'm forced to either fall back to RAW mode, or to check
> whether there's something left in the socket and read it later with a
> separate
> ch_read call:
>
> - Writing in RAW mode directly to the buffer leaves ^@ in place of proper
> linefeeds, meaning a callback function would have to be called, that would
> substitute ^@ with ^M and only then write to the buffer; this is where the
> initial question stems from.

I would say that what you see looks like a bug: ^@ is LF (also known
as NL or "\n", byte 0xA), but in a buffer LF is used to represent NUL
and this is why it appears as ^@ (see `:h NL-used-for-Nul`). So if you
have a server which outputs LF separators and buffer is opened with
`unix` `` appearing ^@ should be a bug. Though if the
server actually outputs NUL bytes it is not a bug.

Note that ^M or CR or `\r` or byte 0xD is *not* a line feed. Just
`:put` converts *both* CR and LF to a newline, so you probably don’t
need to do any substitutions.

(And note that newline in a buffer is neither CR nor LF. It is “NUL”
which terminates a C string which represents a buffer line, conversion
to CR, LF or CRLF is done on write according to `` option.)

> - ch_read() call would also have to be performed by a callback function that
> will, again, need a way to somehow write to the buffer.
>
> The closest solution I've got is to do something like
>
> :bufnr('_out') bufdo put =msg
>
> but that switches the current window to "_out" buffer.

You may try using Python `vim.Buffer` class, I am not aware of
anything else which may do update without switching buffers
explicitly. Or just write in a scratch tab page, with all commands to
create it protected by ='all' and =1, scratch
tab is to be destroyed after writing. Or create a wrapper script which
will add a newline at the end and which should be communicated with in
place of the server directly.

>
> --
> Regards,
> Dmitry
>
>
> --
> --
> 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.

-- 
-- 
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: A very naive question: any doc (book, web page, ...) to learn step by step how to custom configure vim?

[Nikolay Aleksandrovich Pavlov]

2017-08-11 21:36 GMT+03:00 Jose Caballero :
> I reply to myself so I don't pick any particular answer.
> Thanks a lot for your comments. I will have a look to those books. I
> have SAFARI account, so I can check them for free :)
> As I said, I am not that much concerned about learning editing
> features, or things I can do "with my fingers" when editing a file. I
> know what I don't know, and how to find it.
> I am looking for a way to learn how to improve the "behind the scenes"
> part, so to speak.
> But I think I got good comments on that from you already. Thanks a lot !!

I would say that [Learn Vimscript the Hard Way][lvhw] looks like
something more in line with your request.

[lvhw]: http://learnvimscriptthehardway.stevelosh.com/

>
> Jose
>
> --
> --
> 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.

-- 
-- 
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: "real" shell in window?

[Nikolay Aleksandrovich Pavlov]

2017-08-09 23:25 GMT+03:00 ANDY KENNEDY :
> All,
>
> First, thanks Christian for adding me back to the list ;).
>
> Is there a way in Vim to open a :vs, then launch some sort of shell in
> that window?
>
> I found a couple of different plugins that appear to be loosely what I
> want, but I would rather have something that has been pushed back to
> the Vim.

:terminal opens terminal emulator in a new window in Vim, in the
current window in Neovim. In Vim this functionality is new and
unstable, in Neovim it is much more established.

>
> Thanks,
> Andy
>
> --
> --
> 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.

-- 
-- 
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: Regex arithmetic

[Nikolay Aleksandrovich Pavlov]

2017-08-05 23:27 GMT+03:00 porphyry5 :
> On Friday, August 4, 2017 at 10:03:16 AM UTC-7, porphyry5 wrote:
>> :h submatch( includes
>> Example:
>> :s/\d\+/\=submatch(0) + 1/
>> This finds the first number in the line and adds one to it.
>>
>> Needing to increment several fields consisting of underscore and a single 
>> digit (_\d) I modified the above along the lines of
>>
>>   s/_\(\d\)/\='_'.submatch(1) + 1/gc
>>
>> most of which merely replaced the entire field with '1'
>>
>> Thinking the problem might be a conflict between the types, string and 
>> number, I tried
>>
>> s/_\(\d\)/\="_".nr2char(submatch(1) + 1)/gc
>> then
>> s/_\(\d\)/\="_".nr2char(submatch(1) + 31)/gc
>> and finally success with
>> s/_\(\d\)/\="_".nr2char(submatch(1) + 49)/gc
>> which is limited to operations on just a single digit.
>>
>> So, is there a generally reliable method of performing arithmetic on numeric 
>> fields embedded in a larger string pattern with :s? Thank you.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>> Graham Lawrence
>
> Thank you,
> s/_\(\d\)/\='_'.(submatch(1)+1)/g
> works perfectly, and I see what I was trying initially
> s/_\(\d\)/\='_'.submatch(1)+1/g
> is actually equivalent to
> s/_\d/\=submatch(0)+1/g
>
> In the meantime, I read :h substitute( and found
> s/_\(\d\)/\=substitute(submatch(0),'\d',submatch(1)+1,'')/g
> which avoids the problem by making a secondary pattern selection of the 
> number alone. But that's more typing, so I will pay attention to operator 
> precedence in future.

If you write using more then one language there is a good rule: do not
pay attention to operator precedence, just use parenthesis every time
you are not sure. I normally just assume that precedence is “[*/%] >
[-+] > binary comparison (>, <, >=, <=, ==, etc) > binary logical (not
bitwise) operators (&&, ||)” which is rather safe (though there are
languages where even these assumptions are not valid), and everything
else needs parenthesis.

>
> --
> --
> 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.

-- 
-- 
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: Regex arithmetic

[Nikolay Aleksandrovich Pavlov]

2017-08-04 20:03 GMT+03:00 Graham Lawrence :
> :h submatch( includes
> Example:
> :s/\d\+/\=submatch(0) + 1/
> This finds the first number in the line and adds one to it.
>
> Needing to increment several fields consisting of underscore and a single
> digit (_\d) I modified the above along the lines of
>
>   s/_\(\d\)/\='_'.submatch(1) + 1/gc
>
> most of which merely replaced the entire field with '1'

Which it did pecause you don’t pay attention to operator precedence,
not because there is some problem with Vim performing arithmetic on
strings. Just add parenthesis so it will *first* add *then* concat.
Currently all binary operators are left associative and `.` and `+`
have the same precedence. Exactly the same case (concat then add) is
disambiguated as an example at `:h expr-+`.

>
> Thinking the problem might be a conflict between the types, string and
> number, I tried
>
> s/_\(\d\)/\="_".nr2char(submatch(1) + 1)/gc
> then
> s/_\(\d\)/\="_".nr2char(submatch(1) + 31)/gc
> and finally success with
> s/_\(\d\)/\="_".nr2char(submatch(1) + 49)/gc
> which is limited to operations on just a single digit.
>
> So, is there a generally reliable method of performing arithmetic on numeric
> fields embedded in a larger string pattern with :s? Thank you.
>
>
> --
> Graham Lawrence
>
> --
> --
> 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.

-- 
-- 
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: Idea and prototype: Vim independent event based communication & completions?

[Nikolay Aleksandrovich Pavlov]

2017-08-03 0:23 GMT+03:00 Marc Weber :
> Vim8 / NeoVim / maybe Emacs and more
> languages: VimL/Python (maybe lua)/ others
>
> But common features such as
>   - completion
>   - templates
>   - describe thing at cursor
>   - goto thing at cursor
>   - show errors
>   - run compilation
>   - ...
>
> 500 plugins - but how to make them work together?
>
> http://github.com/MarcWeber/editor-cells
>
> Is an attempt to implement the features in an independent manner so that
> those parts can talk to each other by message passing style no matter
> what language they are written in.

Almost everything in your list is covered by language server protocol:
completion, describing things at cursor, goto definition, … It is more
logical to extend LSP then invent something else. Currently LSP does
not support only “templates” and, probably, “run compilation” ([code
action request][1] is documented to have different purpose) from your
list. What it does not support and what neither is on your list, but
what would be good to have is syntax highlighting support, [LSP’s
document highlight][2] is a different thing.

>From what I have read it looks like you are trying to create an LSP,
but without the “server” part, looking like a mesh network. Please, do
not do useless job, better work on LSP.

Though I am very unsure whether I understood right regarding how you
are going to implement anything you claim.

[1]: 
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#textDocument_codeAction
[2]: 
https://github.com/Microsoft/language-server-protocol/blob/master/protocol.md#textDocument_documentHighlight.

>
> Because reinventing the wheel sucks.
>
> It is an experiment, maybe it will hit speed bottlenecks, but I felt its
> the most flexible way to learn from the past.
>
> https://github.com/MarcWeber/editor-cells/blob/master/vimrc
> and SetupVimTestCells() shows how to setup completion and a simple auto
> triggering implementation. You see that you can add custom completions
> to existing omnifuncs easily by using wrappers around existing omnifuncs
> such as CompleteMonth.
>
> The long term goal is to provide completions which you could combine
> with machine learning to see which options should be ranked highest for
> instance.
>
> So the idea is that you can compose individual features the way you
> need.
>
> SetupPy2TestCells works, the py3 async code needs more work - but its
> enough to get an idea.
>
> Once there is a 'common format' many editors car do basic things with
> then libraries even can provide their own snippets / dsls / stuff and be
> done. Currently its a lot of work for everyone.
>
> Feedback welcome - its very early stage.
>
> Marc Weber
>
> --
> --
> 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.

-- 
-- 
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: Why the bufnew not work here?

[Nikolay Aleksandrovich Pavlov]

2017-07-29 18:45 GMT+03:00 Zhe Lee :
> I use
> au BufNewFile *.py 0r headerfile/python.header
>
> in my vimrc file . I want to auto add snippet when the python file is create. 
> But it doesn't work, when I use the "gvim newpy.py" command in command 
> prompt. How to fix this?

This looks like something which will not work in many cases: :read is
supplied relative path, but do you have `headerfile/python.header` in
each directory you happen to run Vim from?

It should “work” by throwing E484 error message though. For me it
works, but error message and “Press ENTER” prompt are hidden by
further setup. Check `:messages`.

>
> --
> --
> 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.

-- 
-- 
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: Function xxxx already exists, add ! to replace it

[Nikolay Aleksandrovich Pavlov]

2017-07-23 11:49 GMT+03:00 Length Power :
> here is my .vimrc
>
>  1 execute pathogen#infect()
>   2 execute pathogen#helptags()
>   3 syntax on
>   4 filetype plugin indent on
>   5
>   6 let g:pydiction_location = 
> '/home/guest/.vim/bundle/dict/pydiction/complete-dict'
>   7 let g:pydiction_menu_height = 10
>   8
>   9 au FileType python call PyFun()
>  10 function PyFun()
>  11 set  tags+=/home/guest/.vim/tags/python.tag
>  12 autocmd FileType python set omnifunc=pythoncomplete#Complete
>  13 endfunction
>  14
>  15 au FileType c call CFun()
>  16 function CFun()
>  17 set  tags+=/home/guest/.vim/tags/c.tag
>  18 autocmd FileType c set  omnifunc=ccomplete#Complete
>  19 endfunction
>  20
>  21 au FileType php call PhpFun()
>  22 function PhpFun()
>  23 set 
> dictionary-=$HOME/.vim/bundle/dict/vim-php-dictionariy/dict/PHP.dict   
> dictionary+=$HOME/.vim/bundle/dict/vim-php-dictionary/dict/PHP.dict
>  24 autocmd FileType php set  omnifunc=phpcomplete#Complete
>  25 endfunction
>  26
>  27 let g:tern_show_signature_in_pum = 1
>
>
> :source .vimrc
>
> result in some error info
>
> Error detected while processing /home/guest/.vimrc:
> line   13:
> E122: Function PyFun already exists, add ! to replace it
> line   19:
> E122: Function CFun already exists, add ! to replace it
> line   25:
> E122: Function PhpFun already exists, add ! to replace it
> Press ENTER or type command to continue
>
> Are there something wrong to fix?

There are many things wrong here, but with this vimrc you should be
restarting Vim in order to not get the errors (or add bang like it
requests, but if you keep writing code like this better just restart).

“Wrong”:

1. You are defining autocmds which run something on FileType event …
in a function which is *already* run on FileType event. I am not sure
whether these autocommands work, but this is a waste. Just remove all
`autocmd FileType {ft} {cmd}` from functions, keeping only `{cmd}`
parts.

   This is a waste not only because of needless autocmd creation, but
because new autocmd setting omnifunc will be added each time you open
php, etc file, this way after opening two php files you will have two
autocommands doing the same thing.

2. All autocommands are supposed to be in an augroup with a unique
name unless you want troubles (creating duplicate autocommands each
time) on resourcing vimrc. Example is right below `:h :augroup`.
3. Do not use `:set` for filetype-specific options, there is `:setlocal`.

>
> --
> --
> 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.

-- 
-- 
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: Really simple abbreviation I can't do

[Nikolay Aleksandrovich Pavlov]

2017-07-14 23:16 GMT+03:00  :
>> Use mappings as suggested here:
>>
>
> Thanks for everyone who has responded. I'm still curious about the extra
> space inserted by the :ab, when exactly the same sequence, (as far as I
> can see) does not generate it.

There is no “extra space” inserted, abbreviation is triggered only
after you type some text and a character which triggers the
abbreviation (space in some cases) *and that character is not being
removed*, it just stays there in an input buffer to be processed after
abbreviation is expanded. By default all characters except for control
ones are processed by inserting them into the buffer at the cursor
position, space is not a control character.

Eatchar technique I referenced in the first message works around the
problem for the cases when it is needed.

>
> --
> --
> 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.

-- 
-- 
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: Really simple abbreviation I can't do

[Nikolay Aleksandrovich Pavlov]

2017-07-14 1:03 GMT+03:00 Nikolay Aleksandrovich Pavlov <zyx@gmail.com>:
> 2017-07-14 0:45 GMT+03:00 Tony Mechelynck <antoine.mechely...@gmail.com>:
>> On Thu, Jul 13, 2017 at 9:55 PM,  <aroc...@vex.net> wrote:
>>>
>>> I hesitate to ask this question, since it appears to be so simple, but the
>>> answer ought to be useful to a lot of people.
>>>
>>> There are many constructs in most programming languages which involve
>>> paired characters - {} () [] particularly. It would be helpful for the
>>> first character (or the pair) to insert both ends, then skip back between
>>> them and start inserting. (That avoids leaving unbalances around.)
>>>
>>> Despite trying all sorts of combinations, I've been unable to achieve an
>>> abbreviation sequence that doesn't insert a space, either before or
>>> between the pair. Is there one?
>>>
>>
>> If you want the brackets to close themselves, you can use _mappings_,
>> not abbreviations, as follows:
>>
>> inoremap ( ()
>> inoremap [ []
>> inoremap { {}
>> or maybe instead of this last one,
>> inoremap { {}
>>
>> -- but if you want someday to type an unpaired bracket you will then
>> of course have to follow up with a  to delete the just inserted
>> closing bracket.
>
> I would rather suggest using `{` then `(`: no need to move
> hand to the other block. And, of course, if using my mappings instead
> (`,s` for `()`, `,h` for `[]`, `,u` for `<>`, `,f` for `{}`) ``
> will not be needed. One of the reasons I keep using them is that
> typing them is faster as they do not involve higher row (and shift
> should you use `us` keymap) and positioning for both keys may be
> performed simultaneously as `,` is to be pressed by one finger and
> everything else by others.
>
> Also all your mappings are incorrect: first ones use ``, pretty
> much sure you meant ``. As for the last one: it ignores
> , using two space indent always. Just use

Err, if I read correctly what are you suggesting will use 
*plus* two spaces. Last can just be removed to achieve the same result
as my variant (minus possible differences in interaction with undo or
`.`: not sure, but my autoclose mappings tend to have issues with
that).

>
> inoremap { {o}O
>
> Most of time indentation will be just fine due to indent scripts,
> including additional indentation on the new line created by the last
> `O`.
>
>>
>>
>> Best regards,
>> Tony.
>>
>> --
>> --
>> 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.

-- 
-- 
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: Really simple abbreviation I can't do

[Nikolay Aleksandrovich Pavlov]

2017-07-14 0:45 GMT+03:00 Tony Mechelynck :
> On Thu, Jul 13, 2017 at 9:55 PM,   wrote:
>>
>> I hesitate to ask this question, since it appears to be so simple, but the
>> answer ought to be useful to a lot of people.
>>
>> There are many constructs in most programming languages which involve
>> paired characters - {} () [] particularly. It would be helpful for the
>> first character (or the pair) to insert both ends, then skip back between
>> them and start inserting. (That avoids leaving unbalances around.)
>>
>> Despite trying all sorts of combinations, I've been unable to achieve an
>> abbreviation sequence that doesn't insert a space, either before or
>> between the pair. Is there one?
>>
>
> If you want the brackets to close themselves, you can use _mappings_,
> not abbreviations, as follows:
>
> inoremap ( ()
> inoremap [ []
> inoremap { {}
> or maybe instead of this last one,
> inoremap { {}
>
> -- but if you want someday to type an unpaired bracket you will then
> of course have to follow up with a  to delete the just inserted
> closing bracket.

I would rather suggest using `{` then `(`: no need to move
hand to the other block. And, of course, if using my mappings instead
(`,s` for `()`, `,h` for `[]`, `,u` for `<>`, `,f` for `{}`) ``
will not be needed. One of the reasons I keep using them is that
typing them is faster as they do not involve higher row (and shift
should you use `us` keymap) and positioning for both keys may be
performed simultaneously as `,` is to be pressed by one finger and
everything else by others.

Also all your mappings are incorrect: first ones use ``, pretty
much sure you meant ``. As for the last one: it ignores
, using two space indent always. Just use

inoremap { {o}O

Most of time indentation will be just fine due to indent scripts,
including additional indentation on the new line created by the last
`O`.

>
>
> Best regards,
> Tony.
>
> --
> --
> 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.

-- 
-- 
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: Really simple abbreviation I can't do

[Nikolay Aleksandrovich Pavlov]

2017-07-13 22:55 GMT+03:00  :
>
> I hesitate to ask this question, since it appears to be so simple, but the
> answer ought to be useful to a lot of people.
>
> There are many constructs in most programming languages which involve
> paired characters - {} () [] particularly. It would be helpful for the
> first character (or the pair) to insert both ends, then skip back between
> them and start inserting. (That avoids leaving unbalances around.)
>
> Despite trying all sorts of combinations, I've been unable to achieve an
> abbreviation sequence that doesn't insert a space, either before or
> between the pair. Is there one?

Why do you want exactly abbreviation? Though there is a Eatchar
technique described right above `:h :abbreviate-local` (under `:h
abbreviations`), I normally see this implemented on top of mappings.

Though personally I do not use things like autoclose, instead just
having simple mappings like `,s` inserting `()` with cursor left on
the closing `)` (so typed text will be inserted in the middle).

>
> --
> --
> 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.

-- 
-- 
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: Regula expressions: How to find a string without some other string

[Nikolay Aleksandrovich Pavlov]

2017-07-05 10:49 GMT+03:00 Christian Brabandt :
>
> On Mi, 05 Jul 2017, Igor Forca wrote:
>
>> Hi,
>> I have a log file with several text OK and error messages.
>>
>> OK message is always: AAA000A
>>
>> Error message starts with AAA, then three numbers (but not three zeros) and 
>> letter A.
>> Error sample: AAA001A
>>
>> From the Vim Regular Expression web site:
>> http://vimregex.com/#metacharacters
>> I can see:
>> \d digit
>> \D non-digit
>>
>> To find OK and error message in vim:
>> /AAA\d\d\d\D
>
> This will find okay or error messages.
>
>> but how to get only error messages.
>>
>> Something like:
>> - use: /AAA\d\d\d\D
>> - except: /AAA000A
>
> Something like this should work:
> A\{3}\%(\([^0]\d\{2}\)\|\(\d[^0]\d\)\|\(\d\{2}[^0]\)\)A
> which matches 3 As, followed by either:
> - a non-zero followed by 2 digits followed by another A or
> - a digit followed by a non-zero followed by another digit and A or
> - 2 digits followed by a non-zero followed by another A

These are too much combinations. I would suggest using lookahead instead:

\vAAA%(.{,2}[1-9])@=\d{3}A

I.e. three A’s followed by three digits and A where position just
after three A’s is occupied by zero..two characters followed by 1-9.

You already have three branches for three-digit error code. Will have
four branches for four-digit, etc. With lookahead you always need only
one lookahead for any given number of digits.

There are also concats as an alternative to positive lookahead, but
since they are not in PCRE and do not present anything new I do not
use them.

>
>
> Best,
> Christian
> --
> Warum überquerte das Huhn die Straße?
> Kindergärtnerin:
>   Um auf die andere Straßenseite zu kommen.
>
> --
> --
> 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.

-- 
-- 
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: vi.bat helper

[Nikolay Aleksandrovich Pavlov]

2017-06-30 0:16 GMT+03:00 Andrew Pennebaker :
> The Vim installer for Windows helps to add "vim" to the command PATH by
> adding a vim.bat file in C:\Windows. Could the installer also add a vi.bat
> file, so that developers can invoke Vim by the even shorter command "vi"?
>
> vi.bat:
>
> vim %*
>
> Cheers,
> Andrew

Those who need it can do same thing themselves. One letter is not
actually hard to type and `vi` has its own meaning, mostly “tiny
version of Vim” (in Debian-based) or “featureless Vi-like editor”
(i.e. busybox `vi` applet) now.

>
> --
> --
> 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.

-- 
-- 
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: save and load a micro

[Nikolay Aleksandrovich Pavlov]

2017-06-12 8:05 GMT+03:00 Ben Fritz :
> On Sunday, June 11, 2017 at 5:26:43 AM UTC-5, Sand Glass wrote:
>> And record a macro in register a. But the macro not completely right like 
>> ^Q(it's into block coloumn mode). I want to fix my macro and save it to a 
>> file, next time I open a file can load the macro to a reg.
>> The question is I don't how to fix my macro and load it to a reg next time.
>
> By default, it should be saved already, in your .viminfo file. Check your 
> 'viminfo' setting to make sure if you are worried.
>
> You can also paste the contents of your register into a file with this 
> normal-mode command:
>
>   "ap
>
> Then you can save that file if you like. To get your macro back, just yank 
> the content back into a register:
>
>   0"ay$
>
> This may not work in all cases for special characters in the register, etc. 
> The .viminfo method is probably more robust.

For robust keeping register in a file one should use
`writefile([getregtype('a')] + getreg('a', 1, 1), 'rega', 'b')`. For
restoring then: `let rega = readfile('rega', 'b') | setreg('a',
rega[1:], rega[0])`.

>
> --
> --
> 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.

-- 
-- 
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: mapping list with : v:val and index of v:val

[Nikolay Aleksandrovich Pavlov]

2017-06-11 18:36 GMT+03:00 Ni Va :
> Hi,
>
> Trying this
>
>
> let file = readfile(expand("%:p"),'b')
> let g:file=map(copy(file),'v:val.":".index(copy(file), v:val)')
>
> returns -1 for each v:val of list 'file' out of 0, 1 , 2 etc..

There is `v:key`, do not use `index()` here; and using `copy()` in
`index()` is not needed. And I am unable to reproduce your problem
(vim 8.0.582), maybe need a specific set of options or specific file
contents: using file created with `writefile(range(10),
'/tmp/filename')` for the test.

Wondering whether you understand that without the context (is this
placed in a function?) `g:file` and `file` are the same variables?
(Inside a function `file` would be `l:file`.) Though based on my
knowledge of VimL this should not matter in this code: `file` will be
reassigned only after expression evaluation finishes.

>
>
> 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.
> 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.

-- 
-- 
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: meaning of \= in syntax scripts

[Nikolay Aleksandrovich Pavlov]

2017-06-01 21:08 GMT+03:00 Erhy :
> Hello, I try to update a syntax script
> e.g.
> syn match scilabArithmetic  "\.\=[*/\\]\.\="
>
> Please tell me about\=

:h /\=

>
> Thank you
> Erhy
>
> --
> --
> 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.

-- 
-- 
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: Insert lines at begin of file with writefile

[Nikolay Aleksandrovich Pavlov]

2017-05-30 14:21 GMT+03:00 Ni Va :
> Le mardi 30 mai 2017 13:03:38 UTC+2, ZyX a écrit :
>> 2017-05-30 11:21 GMT+03:00 Ni Va :
>> > Hi,
>> >
>> >
>> > Is that a way to tell writefile() func to append lines at the beginning of 
>> > file?
>>
>> Just read the whole file, prepend and then write the whole file. In
>> any case I do not know a way to actually prepend bytes to the file: if
>> you seek to the end of file (or open it in append mode) and start
>> writing to it you get appending. If you seek to the start and start
>> writing you will just overwrite first bytes. So programming languages
>> do not have “prepending” abstraction because it is not supported by
>> the OS and thus is going to either cost very much or have problems
>> like loosing data on crashes.
>>
>> >
>> > Thank you
>> > Niva
>> >
>> > --
>> > --
>> > 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.
>
> Do you think readfile writefile would be faster than that :
>
> let begin = [$vimruntime."/gvim.exe", "-c", "edit ".makefile, "-c",
>   \"call append(0, 
> ".string(lines2Append).")", "-c", "wq"]
> call x.add_cmd(begin) " == Launch cmd as job

With readfile+writefile you load a file into memory and write there.
With gvim you are forking, loading gvim.exe and a big bunch of
libraries needed for GUI, loading a file into memory (though buffer
structure should be a bit more efficient then a list from `readfile()`
AFAIK), loading a big bunch of plugins (do not do such things without
`-u NONE -i NONE`), loading GUI (use `--cmd` for such things, not
`-c`). Which is faster? Actually may be your variant if you do not
need to wait for gvim to finish prepending because time would be
limited to only forking. readfile()+writefile() if you do need to
wait.

>
> --
> --
> 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.

-- 
-- 
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: Insert lines at begin of file with writefile

[Nikolay Aleksandrovich Pavlov]

2017-05-30 11:21 GMT+03:00 Ni Va :
> Hi,
>
>
> Is that a way to tell writefile() func to append lines at the beginning of 
> file?

Just read the whole file, prepend and then write the whole file. In
any case I do not know a way to actually prepend bytes to the file: if
you seek to the end of file (or open it in append mode) and start
writing to it you get appending. If you seek to the start and start
writing you will just overwrite first bytes. So programming languages
do not have “prepending” abstraction because it is not supported by
the OS and thus is going to either cost very much or have problems
like loosing data on crashes.

>
> Thank you
> Niva
>
> --
> --
> 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.

-- 
-- 
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

[Nikolay Aleksandrovich Pavlov]

2017-05-29 22:17 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Mon, May 29, 2017 at 3:19 AM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
> [...]
>>>>
>>>> This is not actually different from the current situation: was needing
>>>> to check for `exists('*win_id2win')`, will need to check for existence
>>>> of autoload functions (though probably better with EAFP since they are
>>>> autoload: run, catch the case when function not exists, assume old
>>>> version). The only bad thing is that for some rare cases you would not
>>>> be able to construct `bug_present()` condition where you could
>>>> previously rely on the availability of Vim patch. Not a big deal I
>>>> guess: you better not do this thing anymore in presence of Neovim
>>>> which may have neither a bug nor a patch which has fixed a bug (not
>>>> actually not have the patch, not have the information available).
>>>>
>>>> Also while Vim with Bram for some reason does not rely on runtime,
>>>> Neovim has a growing set of runtime files required for normal
>>>> operation. And we are not against bundling libraries, though I am not
>>>> aware of any except for my autoload/shada.vim and autoload/msgpack.vim
>>>> which are so far mainly used for standard plugin operation.
>>>>
>>>> I have programmed for Neovim in VimL, C and lua and can say for sure
>>>> that probability of making a hidden bug in C code is far greater then
>>>> probability of making a hidden bug in lua or VimL. Especially if you
>>>> do refactoring of core functionality (which you will need to in order
>>>> to be able to hide mappings) and not just adding methods for accessing
>>>> already-existing internal structures (which is all you need for my
>>>> proposal; I can bet that diff for necessary functionality may only
>>>> contain additions (better actually not though, in order to share some
>>>> code with maparg())). Since I do not propose to alter existing
>>>> functionality (except for some small refactorings to share code) new
>>>> features are most likely to not break anything not using them even if
>>>> new bugs are introduced.
>>>
>>> While I agree that your approach represents fewer changes to Vim's
>>> core, and hence, reduced risk of bugs, including but not limited to
>>> memory leaks, I don't believe that adding a function like
>>> mappings_get_conflicts() - or making mappings_dump() accept some sort
>>> of filter specification that allows this case to be handled
>>> idiomatically - would result in a dramatic increase in the complexity
>>> of the implementation, and I see definite advantages to having Vim
>>> implement the logic for ambiguity/conflict detection in its core.
>>
>> I do not understand the point. *Last few messages I was agreeing on
>> that prefix filter would be useful.* Never called this “conflict
>> detection” though because who knows what “conflict” may actually mean
>> while “filter out mappings which share the same specified prefix” is
>> simple to understand.
>
> Depends on what is meant by "ambiguous" and "conflicting", I
> suppose... If you define these terms by "shared prefix" only (the way
> mapcheck() works today), then...
>
> :nmap  foo foo
>
> ...would conflict with the following, previously defined global map
> (though in fact, there is really no conflict at all):
>
> :nmap foobar foobar
>
> I guess I was envisioning a smarter detection logic, which would
> consider modifiers like  and , as well as current
> enabled/disabled status, with the goal of answering the following
> questions: If I were to create the following map (defined by lhs,
> mode(s), scope (buffer/global), , etc.), would there be
> ambiguity/conflict with any existing maps? And if so, which ones? In
> your approach, "disable" is simply "remove/clear", so that check
> becomes unnecessary. So you're probably thinking that Vim's map
> scoping/shadowing logic is sufficiently simple that the plugin
> developer could easily include the applicable checks in his map filter
> expression. As things stand now, you may be right, though the idea of
> requiring each plugin developer who needs this check to implement the
> logic independently still suggests a missing primitive to me. I
> concur, however, that the plugin developer would have all the
> information he needs to do it himself, provided that the map filter
> expression has access to a suffic

Re: E114: Missing quote in gvim.exe', '-c'

[Nikolay Aleksandrovich Pavlov]

2017-05-28 23:10 GMT+03:00 Ni Va :
> Le dimanche 28 mai 2017 21:49:03 UTC+2, Ni Va a écrit :
>> Hi,
>>
>> An attempt to modify Make_mvc.mak with a gvim -c command and it fails :
>>
>> let makefile   = globpath(expand('$tmp'.'/vim/src'),'Make_mvc.mak')
>> call job_start([$vimruntime.'/gvim.exe', '-c', 'edit '.makefile, '-c', 'call 
>> setline(1,"SDK_INCLUDE_DIR")'])
>>
>>
>> Errors appear like that :
>> rror detected while processing command line:
>> E114: Missing quote: "SDK_INCLUDE_DIR)
>> E116: Invalid arguments for function setline
>>
>>
>> I don't understand why.
>> Thank by advance !
>> Niva
>
> Done sorry for disturbing
> -c call setline(1,\"SDK_INCLUDE_DIR\"

This looks like a problem with escaping for cmd.exe, you should not
need escaping quotes on your own, this is to be done by Vim.

>
> --
> --
> 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.

-- 
-- 
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

[Nikolay Aleksandrovich Pavlov]

2017-05-29 4:25 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sun, May 28, 2017 at 4:19 PM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
> [...]
>>>>>>
>>>>>> And why do you think that “do not make plugins reinwent the wheel” is
>>>>>> the same statement as “write needed functionality in C code”? You can
>>>>>> always add a new file to `autoload`, writing VimL code is easier then
>>>>>> writing C code.
>>>>>
>>>>> You mean implementing a sort of "DSL" layer (using the primitive
>>>>> functions you've proposed) in Vim script, and including it in the
>>>>> official distribution as an autoload file? If so, I suppose this could
>>>>> be done, but as part of the official distribution, it would still need
>>>>> to be thought through and tested pretty thoroughly, so I don't see much
>>>>> advantage over implementing it in source, where it would be
>>>>> significantly more efficient. But perhaps I misunderstood what you were
>>>>> suggesting...
>>>>
>>>> I think you have only written VimL code, but not C one. VimL does not have
>>>> - Memory leaks. You can provoke one, of course, but 90% of code will
>>>> not ever cause any memory leaks unless you intentionally wrote a code
>>>> which causes memory leak (e.g. an always-growing cache of something
>>>> which is never cleaned up).
>>>> - Using some resource after freeing it. Especially applies to memory.
>>>> You can do something with trying to use channels after closing, but at
>>>> maximum this will show you a nice error which even will not crash Vim.
>>>> Similar error with using memory after freeing it at best will crash
>>>> Vim and provide a big message with lots of hex codes which may even
>>>> frighten some unexperienced user. At worst all you get is crashing Vim
>>>> a message to stderr (GVim users may never see it depending on how they
>>>> run GVim) about catching deadly signal SEGV without any details at
>>>> all. (As you see, Vim will crash in any case.)
>>>> - Crash due to out-of-bounds array access, with same amount of data as
>>>> above. VimL will just show a nice error message. Python will show
>>>> nicer error message, but the point is that it will not crash.
>>>>
>>>> And do not forget about one other good thing about VimL: if a user has
>>>> a distribution with two-years-old Vim to fix problem in C code he will
>>>> need C compiler, git, some shell experience and at least six commands
>>>> to update Vim (clone, configure, build, install, update bashrc or
>>>> whatever; plus one command per shell to load the update or reboot;
>>>> plus maybe something to make *.desktop files with GVim menu entries
>>>> point to a newly compiled Vim location). With VimL code user just
>>>> needs to drop a new version of the file into `~/.vim/autoload`.
>>>>
>>>> I was suggesting autoload because it is easier to write and maintain,
>>>> not because you will need to write less *functionality*. Same DSL
>>>> implemented purely in VimL on top of my proposal will run slower, but
>>>> take much less lines of code.
>>>
>>> I have programmed a great deal in both C and VimL. While I'm not sure
>>> I agree that the possibility of memory leaks is a compelling reason
>>> for implementing the functionality in a script, I don't really have
>>> strong feelings on this. Would the functionality be documented in the
>>> official Vim help? I can't think of any user-facing Vim functions
>>> currently implemented outside Vim. Though it's certainly easier to
>>> update/override a distributed script than to download or build a new
>>> executable, as a plugin developer, I would probably not want to rely
>>> upon tweaked distribution scripts, since most of the plugin users
>>> would get the updated scripts only when they got the updated
>>> executable. Sure, the plugin README could instruct users with older
>>> Vim versions to install an updated autoload file manually outside the
>>> plugin directory, but users have grown accustomed to one-click plugin
>>> installation methods, and might consider this an annoyance...
>>
>> This is not actually different from the current situation: was needing
>> to check for `exists('*win_id2win')`, will need to check for existence
>> of autoloa

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

[Nikolay Aleksandrovich Pavlov]

2017-05-28 23:16 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sun, May 28, 2017 at 1:10 PM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
>
> [...]
>>>>
>>>> You may also ask Brett Stahlman whether my proposal is enough, it does
>>>> not look like he thinks it is not, just that it may be less
>>>> convenient.
>>>
>>> I believe it would be possible to do pretty much anything with the
>>> functions you propose, though for some common use cases, it puts more of
>>> a burden on the user than may be warranted. Yes,
>>> some_more_complex_filter_if_needed could be a function that tests
>>> canonical lhs for conflict/ambiguity, retaining only the ambiguous maps,
>>> and a subsequent call to mappings_load() (passing the filtered results
>>> with 'rhs' key removed) could be used to delete the conflicting
>>> mappings. But this feels a bit roundabout and error-prone compared to...
>>>
>>> let handles = maplist('', 'nv')
>>> call disable_maps(handles)
>>>
>>> Question: Would the map handles be mode-specific? E.g., for a map
>>> defined with :map, would there be 1 or 3 handles? I'm assuming that your
>>> mappings_dump() would return a single dict with a modes flag of 'nvo' or
>>> something like that. It occurs to me that either approach could allow
>>> finer-grained control than the :*map commands provide, and could obviate
>>> the need for kludges like this (from the help on omap-info):
>>>
>>> {{{
>>> To enter a mapping for Normal and Visual mode, but not Operator-pending 
>>> mode,
>>> first define it for all three modes, then unmap it for Operator-pending 
>>> mode:
>>> :mapxx something-difficult
>>> :ounmap xx
>>> Likewise for a mapping for Visual and Operator-pending mode or Normal and
>>> Operator-pending mode.
>>> }}}
>>>
>>> Also note that your approach does more than simply *disable*; it
>>> actually *removes* the mappings as far as Vim is concerned. Granted, if
>>> we keep a reference to disabled_mappings, it would be easy enough to
>>> recreate them later, but I would imagine this is significantly less
>>> efficient than simply toggling an internal flag indicating enabled
>>> status. Also, as I mentioned before, I don't think checking for
>>> ambiguity/conflict is something that *should* be done by a plugin
>>> developer. Sure, a plugin developer should be capable of writing an
>>> algorithm to do this (assuming he has access to a canonical lhs), but
>>> forcing each plugin developer to do it just feels wrong to me, even if
>>> it ends up being a smallish predicate function/filter (and I suspect
>>> doing it robustly would end up being more than a one-liner). Thus, at
>>> the very least, I would propose having mappings_dump() accept an input
>>> that requests ambiguous/conflicting maps only, or else a separate
>>> function such as mappings_get_conflicts().
>>
>> This is *not* as simple as “toggling the internal flag”. You want to
>> disable a mapping and use your own one instead, this means that there
>> will be other changes to the mapping code. Much likely the result will
>> be *less* efficient for a few first years: your plugin has one set of
>> users, but for features needed for your plugin *all* users will pay.
>> This is much less the case for my variant: additional functions also
>> cost space and CPU ticks for O(log N) function lookup (BTW, Neovim has
>> O(1) built-in function lookup), but this is all non-users will pay.
>
> There's no relationship between the old and new mapping. Disabling the
> old (which may not even have the same lhs as the new) simply allows
> Vim to find the new mapping without ambiguity or conflict. A disabled
> mapping would be shadowed by a  mapping in much the same way
> as a global mapping is shadowed by a buf-local mapping: i.e., Vim sees
> that the global would work, but prefers the buf-local. Depending on
> how they're stored, Vim may still have to iterate over the disabled
> mappings, but the disabled flag prevents their being considered as
> candidates.

That “still have to iterate” is what I am talking about.

>
>>
>> Though I would not talk about efficiency here: the question is whether
>> your plugin implemented on top of one feature or the other will switch
>> “modes” in ~50 ms I guess. If it can do this with my approach then my
>> approach is good enough. Also I have shared details regarding how my
>> proposed API will look like, bu

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

[Nikolay Aleksandrovich Pavlov]

2017-05-28 19:05 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sun, May 28, 2017 at 6:50 AM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
>> 2017-05-28 8:57 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>
>>> Nikolay Pavlov wrote:
>>>
>>> [..]
>>>
>>>> >> Enable, disable, query, execute plus two callbacks. *Four* functions
>>>> >> and two callbacks in place of just two simple functions, mostly using
>>>> >> the functionality that is already there. Five if you remember about
>>>> >> :mkvimrc and that somebody may want to replace that on top of new API:
>>>> >> query will need a mirror function for creating a mapping then.
>>>> >
>>>> > You are completely missing the point: those two functions don't provide
>>>> > the functionality we are talking about here.
>>>>
>>>> Why do you think so? They provide everything what is needed to
>>>> implement the functionality we are talking about here in VimL.
>>>
>>> This whole discussion started about the difficutly of using the result
>>> of maparg().  As far as I can see you only provide a function to get more
>>> mappings, it doesn't help with disabling and restoring mappings.
>>> Dealing with that is not easy at all (dealing with modes,
>>> escaping/unescaping, etc).  I would not want every plugin writer to
>>> re-invent the wheel.
>>>
>>> The basic discussion first need to be held is whether to refer to a
>>> mapping just by its LHS (plus mode) or a unique handle can be used.  The
>>> latter is useful if we disable a mapping but not delete it, it can then
>>> be shadowed by another mapping.
>>>
>>> We probably also need some kind of re-enable or restore function, that
>>> takes the result of maparg() and defines a mapping with it.  That avoids
>>> string manipulation and using :exe (this is tricky because of the way
>>> mappings need some characters to be escaped).
>>
>> Three functions:
>>
>> 1. Get mappings: mappings_dump(). Needs to output lhs and rhs in some
>> canonical form. Takes an argument which allows some basic filtering:
>> e.g. select only mappings belonging to buffer with number N or
>> globals, select only mappings with given modes and select only
>> mappings starting with some prefix.
>> 2. Create mappings: mappings_load(). Takes output from
>> mappings_dump(), with the help of mappings_canonicalize() it should be
>> possible to create your own mappings.
>> 2.1. Something to delete mappings: mappings_load() with missing rhs or
>> mappings_clear() which takes output of mappings_dump() and deteletes
>> those mappings.
>> 3. Create string for lhs or rhs in canonical form given something like
>> `"\"` or `""` (not sure what would be better) as the input:
>> mappings_canonicalize().
>>
>> So “disabling” is
>>
>> let disabled_mappings = mappings_dump(some_filter)
>> call filter(disabled_mappings, some_more_complex_filter_if_needed)
>> call mappings_load(map(deepcopy(disabled_mappings),
>> \'[remove(v:val, "rhs"), v:val][-1]'))
>>
>> “Enabling” is
>>
>> call mappings_load(disabled_mappings)
>>
>> One of the key points is that mappings_dump() and mappings_load() need
>> to work with canonical form of lhs and rhs strings and thus
>> dictionaries returned by them are not entirely compatible with
>> maparg() results. Canonical form needs to be independent of
>> , allow distinguishing `F1>` and `` and
>> `mappings_canonicalize(mappings_canonicalize(x))` should be identical
>> to `mappings_canonicalize(x)`.
>>
>> ---
>>
>> You may also ask Brett Stahlman whether my proposal is enough, it does
>> not look like he thinks it is not, just that it may be less
>> convenient.
>
> I believe it would be possible to do pretty much anything with the
> functions you propose, though for some common use cases, it puts more of
> a burden on the user than may be warranted. Yes,
> some_more_complex_filter_if_needed could be a function that tests
> canonical lhs for conflict/ambiguity, retaining only the ambiguous maps,
> and a subsequent call to mappings_load() (passing the filtered results
> with 'rhs' key removed) could be used to delete the conflicting
> mappings. But this feels a bit roundabout and error-prone compared to...
>
> let handles = maplist('', 'nv')
> call disable_maps(handles)
>
> Question: Wou

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

[Nikolay Aleksandrovich Pavlov]

2017-05-28 8:57 GMT+03:00 Bram Moolenaar :
>
> Nikolay Pavlov wrote:
>
> [..]
>
>> >> Enable, disable, query, execute plus two callbacks. *Four* functions
>> >> and two callbacks in place of just two simple functions, mostly using
>> >> the functionality that is already there. Five if you remember about
>> >> :mkvimrc and that somebody may want to replace that on top of new API:
>> >> query will need a mirror function for creating a mapping then.
>> >
>> > You are completely missing the point: those two functions don't provide
>> > the functionality we are talking about here.
>>
>> Why do you think so? They provide everything what is needed to
>> implement the functionality we are talking about here in VimL.
>
> This whole discussion started about the difficutly of using the result
> of maparg().  As far as I can see you only provide a function to get more
> mappings, it doesn't help with disabling and restoring mappings.
> Dealing with that is not easy at all (dealing with modes,
> escaping/unescaping, etc).  I would not want every plugin writer to
> re-invent the wheel.
>
> The basic discussion first need to be held is whether to refer to a
> mapping just by its LHS (plus mode) or a unique handle can be used.  The
> latter is useful if we disable a mapping but not delete it, it can then
> be shadowed by another mapping.
>
> We probably also need some kind of re-enable or restore function, that
> takes the result of maparg() and defines a mapping with it.  That avoids
> string manipulation and using :exe (this is tricky because of the way
> mappings need some characters to be escaped).

Three functions:

1. Get mappings: mappings_dump(). Needs to output lhs and rhs in some
canonical form. Takes an argument which allows some basic filtering:
e.g. select only mappings belonging to buffer with number N or
globals, select only mappings with given modes and select only
mappings starting with some prefix.
2. Create mappings: mappings_load(). Takes output from
mappings_dump(), with the help of mappings_canonicalize() it should be
possible to create your own mappings.
2.1. Something to delete mappings: mappings_load() with missing rhs or
mappings_clear() which takes output of mappings_dump() and deteletes
those mappings.
3. Create string for lhs or rhs in canonical form given something like
`"\"` or `""` (not sure what would be better) as the input:
mappings_canonicalize().

So “disabling” is

let disabled_mappings = mappings_dump(some_filter)
call filter(disabled_mappings, some_more_complex_filter_if_needed)
call mappings_load(map(deepcopy(disabled_mappings),
\'[remove(v:val, "rhs"), v:val][-1]'))

“Enabling” is

call mappings_load(disabled_mappings)

One of the key points is that mappings_dump() and mappings_load() need
to work with canonical form of lhs and rhs strings and thus
dictionaries returned by them are not entirely compatible with
maparg() results. Canonical form needs to be independent of
, allow distinguishing `F1>` and `` and
`mappings_canonicalize(mappings_canonicalize(x))` should be identical
to `mappings_canonicalize(x)`.

---

You may also ask Brett Stahlman whether my proposal is enough, it does
not look like he thinks it is not, just that it may be less
convenient.

---

And why do you think that “do not make plugins reinwent the wheel” is
the same statement as “write needed functionality in C code”? You can
always add a new file to `autoload`, writing VimL code is easier then
writing C code.

>
> --
>A village.  Sound of chanting of Latin canon, punctuated by short, sharp
>cracks.  It comes nearer.  We see it is a line of MONKS ala SEVENTH SEAL
>flagellation scene, chanting and banging themselves on the foreheads with
>wooden boards.
>  "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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 20:29 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sat, May 27, 2017 at 11:51 AM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
>> 2017-05-27 19:32 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
>>> On Sat, May 27, 2017 at 10:39 AM, Nikolay Aleksandrovich Pavlov
>>> <zyx@gmail.com> wrote:
>>>> 2017-05-27 18:02 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
>>>>> On Sat, May 27, 2017 at 8:35 AM, Nikolay Aleksandrovich Pavlov
>>>>> <zyx@gmail.com> wrote:
>>>>>> 2017-05-27 12:45 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>>>>>
>>>>>>> Nikolay Pavlov wrote:
>>>>>>>
>>>>>>>> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>>>>>> >
>>>>>>>> > 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 
>>>>>>>> >> >> > <b...@moolenaar.net> 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().
>>>>>>>> >> >
>>>>>>&

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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 19:48 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>
> Nikolay Pavlov wrote:
>
>> 2017-05-27 18:02 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
>> > On Sat, May 27, 2017 at 8:35 AM, Nikolay Aleksandrovich Pavlov
>> > <zyx@gmail.com> wrote:
>> >> 2017-05-27 12:45 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>> >>>
>> >>> Nikolay Pavlov wrote:
>> >>>
>> >>>> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>> >>>> >
>> >>>> > 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 
>> >>>> >> >> > <b...@moolenaar.net> 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
>> >>>> 

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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 19:32 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sat, May 27, 2017 at 10:39 AM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
>> 2017-05-27 18:02 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
>>> On Sat, May 27, 2017 at 8:35 AM, Nikolay Aleksandrovich Pavlov
>>> <zyx@gmail.com> wrote:
>>>> 2017-05-27 12:45 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>>>
>>>>> Nikolay Pavlov wrote:
>>>>>
>>>>>> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>>>> >
>>>>>> > 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 
>>>>>> >> >> > <b...@moolenaar.net> 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
>

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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 18:02 GMT+03:00 Brett Stahlman <brettstahl...@gmail.com>:
> On Sat, May 27, 2017 at 8:35 AM, Nikolay Aleksandrovich Pavlov
> <zyx@gmail.com> wrote:
>> 2017-05-27 12:45 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>
>>> Nikolay Pavlov wrote:
>>>
>>>> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>>> >
>>>> > 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 
>>>> >> >> > <b...@moolenaar.net> 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 ma

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

[Nikolay Aleksandrovich Pavlov]

2017-05-27 12:45 GMT+03:00 Bram Moolenaar :
>
> Nikolay 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 

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 <zyx@gmail.com>:
> 2017-05-26 20:43 GMT+03:00 Bram Moolenaar <b...@moolenaar.net>:
>>
>> 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 <b...@moolenaar.net> 
>>> >> > 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 w

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: :right command on Chinese characters

[Nikolay Aleksandrovich Pavlov]

2017-05-21 14:54 GMT+03:00 Joey :
> When I run :right command in gvim, it's ok, like this:
>
>彼外道常说自然，我说因缘。——楞严经
>
> But if I open the txt file with Word, it's like this:
>
> 彼外道常说自然，我说因缘。——楞严
> 经
>
> The last character is returned to the next line, what's wrong?

As Tim Chase said Vim does right justification with spaces, it is not
“real” right justification which is done using some form of “set
paragraph attribute ‘align’ to ‘right’”. You can do this in HTML (via
using CSS attribute `text-align: right`), doc[x] (Word has a button
for this), etc, but not in a txt file, and not with `:right` command.

You need to ask yourself “what do I need right alignment for” and act
accordingly, adjusting  to make text look right *on your
computer with yours Word window size, zoom factor and window
resolution* will do no good because it will no longer look right once
some of factors changes. Maybe you just need to create an rtf document
instead using Word and set that paragraph attribute there.

>
> --
> --
> 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.

-- 
-- 
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: am getting a CRITICAL error using gvim and linux

[Nikolay Aleksandrovich Pavlov]

2017-05-18 8:04 GMT+03:00 Tony Mechelynck :
> On Thu, May 18, 2017 at 5:35 AM, Charles E Campbell
>  wrote:
>>
>> Here it is:
>>
>>   ** (gvim:62530): CRITICAL **: murrine_style_draw_box: assertion 'width >=
>> -1' failed
>>
>> Suggestions appreciated.
>>
>> Regards,
>> Chip Campbell
> [...]
>
> Is that at every startup (even with -u
> /usr/local/share/vim/vim80/defaults.vim) or do you know of any
> circumstances making the problem happen or nor happen?
>
> Or is that a link-time error (at which version and patchlevel)?

? AFAIK linker is not a thing which may trigger assertion error. Also
OP has `vim --version` output which he could not if it was a link time
problem.

>
> Best regards,
> Tony.
>
> --
> --
> 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.

-- 
-- 
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: Retrieve

[Nikolay Aleksandrovich Pavlov]

2017-05-16 14:44 GMT+03:00 Ni Va :
> Le mardi 16 mai 2017 12:27:34 UTC+2, ZyX a écrit :
>> 2017-05-16 11:38 GMT+03:00 Ni Va :
>> > Hi,
>> >
>> > How to retrieve the result of this expression in a vimscript var
>> >
>> > let myvar = executable(prevline.',.s/PATTERN//gn')
>> >
>> > this seems to don't work.
>> >
>> > thank you!
>>
>> I do not understand what “expression” you mean, but `executable` is
>> for checking whether there is some executable e.g. for use in
>> `system()`. Given that you are trying to feed it a VimL command I
>> think you at least wanted `execute()`.
>>
>> >
>> > --
>> > --
>> > 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.
>
> Assuming this expre : prevline.',.s/PATTERN//gn' returns the number of 
> occurences of pattern between prevline and currentline, I just want to store 
> the result in a var.

The expression `prevline.',.s/PATTERN//gn'` returns a string which may
look like a VimL command (depends on what is in `prevline`). It is not
returning any numbers, it returns a string. If you execute this string
as a VimL *command* (commands are not expressions, what is an
expression is described at `:h expr`) it will print a number of
occurrences of PATTERN and number of lines where they occurred.
`execute` and `redir` are capable of capturing what command prints (it
is not a *result*, it is one of the side effects, commands do not
return anything).

You may do what you asked with `execute()`, but I would not suggest
actually doing this: most of what built-in commands print is affected
by the locale and the output you are seeking for definitely is. You
need to either create a wrapper which calls `language messages C` and
restores the locale afterwards, or use different technique to get the
numbers:

```VimL
let d = {'total_count': 0, 'prevline': 0, 'line_count': 0}
let pattern = 'PATTERN'
let expr = 'extend(d, {"prevline": line("."), "total_count":
d.total_count + 1, "line_count": d.line_count + (line(".") !=
d.prevline)})'
execute 'silent' printf('%s,s/%s/\=[%s, ""][-1]/en%s', prevline,
pattern, expr, repeat('g', !))

let myvar = printf('%u matches on %u lines', d.total_count, d.line_count)
```

Note that you also have not cared about `` option. And my
variant does not error out if there are zero matches (remove `e` from
flags if you need this).


>
> Thanks
>
> --
> --
> 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.

-- 
-- 
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: Retrieve

[Nikolay Aleksandrovich Pavlov]

2017-05-16 11:38 GMT+03:00 Ni Va :
> Hi,
>
> How to retrieve the result of this expression in a vimscript var
>
> let myvar = executable(prevline.',.s/PATTERN//gn')
>
> this seems to don't work.
>
> thank you!

I do not understand what “expression” you mean, but `executable` is
for checking whether there is some executable e.g. for use in
`system()`. Given that you are trying to feed it a VimL command I
think you at least wanted `execute()`.

>
> --
> --
> 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.

-- 
-- 
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: Please explain highlight groups User1 ... User9!!!

[Nikolay Aleksandrovich Pavlov]

2017-05-10 17:01 GMT+03:00  :
> On Wednesday, May 10, 2017 at 9:37:41 AM UTC-4, Tony Mechelynck wrote:
>> On Wed, May 10, 2017 at 6:09 AM,   wrote:
>> > On Tuesday, May 9, 2017 at 11:35:47 PM UTC-4, Tony Mechelynck wrote:
>> >> On Wed, May 10, 2017 at 3:04 AM,   wrote:
>> >> [...]
>> >> > Thanks a ton for the reply, Tony!
>> >> >
>> >> > So, just to confirm:  There is NO WAY to conveniently specify a pair of 
>> >> > colors that the status line will use to alternate between to indicate 
>> >> > active/inactive status? I find that hard to believe. This seems 
>> >> > extremely odd to me if it's the case.  In fact, it would appear to be a 
>> >> > deficiency within Vim itself.
>> >> >
>> >> > As another follow up question regarding the documentation: Note that it 
>> >> > says "the difference ... will be applied".  This seems to indicate that 
>> >> > vim should automatically "darken" inactive windows for me when I've 
>> >> > defined and used User1 to highlight my statusline.  The documentation 
>> >> > is then poorly written if this is not the behavior.  In fact, I have no 
>> >> > idea what it means... Any thoughts?
>> >> >
>> >> > Thanks again for the reply, man!
>> >>
>> >> The status line for the current split-window is highlighted in the
>> >> StatusLine highlight group. Status lines for all other split-windows
>> >> (the inactive ones) are highlighted in the StatusLineNC highlight
>> >> group. In addition, when doing command-line completion, the currently
>> >> selected match is highlighted in the WildMenu highlight group. These
>> >> are used on the default status lines and if you don't specify special
>> >> highlighting they will be used in custom status lines too.
>> >>
>> >> Anything that can be tested fom the context of a split-window can be
>> >> used to set a different highlight to part of the status line. The
>> >> colours themselves are global, but by using appropriate constructs in
>> >> your 'statusline' option you can build it with almost infinite
>> >> variety. if?then:else expressions can be used advantageously there to
>> >> put various text, and even various highlight groups, depending on
>> >> circumstances; and any highlight groups can be used: "User" groups by
>> >> using %1* to %9* and any other ones by using their name, e.g. (IIUC,
>> >> and including the option-backslashes to guard the double quotes)
>> >> %{?\"%#Error#BINARY%0*\":\"\"} to output the text BINARY in the
>> >> scary Error highlight group at that point of the statusline for
>> >> windows displaying buffers where the 'binary' local option is set.
>> >>
>> >> See
>> >> :h 'statusline'
>> >> :h option-backslash
>> >>
>> >> P.S. Here's how I set my status line. Rather complicated but I like the 
>> >> result:
>> >>
>> >> if has('statusline')
>> >>   set statusline=%<%f\
>> >> %h%m%r%=%k[%{(==''?:)}%{(?',BOM':'')}][U+%04B]\
>> >> %-12.(%l,%c%V%)\ %P
>> >> endif
>> >>
>> >> and here is how I set my text-style tab bar (even in gvim, using
>> >> 'showtabline' set to 2 and e absent from 'guioptions') with fancy
>> >> colors (the principle is the same as for the status line but I use a
>> >> function to construct it in steps):
>> >>
>> >> if has('windows') && exists('+tabline')
>> >>   function MyTabLine()
>> >> let rv = ''
>> >> let i = 1
>> >> while i <= tabpagenr('$')
>> >>   let rv .= '%#Normal#'
>> >>   let icur = tabpagewinnr(i)
>> >>   let imax = tabpagewinnr(i, '$')
>> >>   let rv .= '%' . i . 'T'
>> >>   let rv .= i . '|' . icur . ':' . imax . ' '
>> >> if i == tabpagenr()
>> >> let rv .= '%#NonText#'
>> >>   else
>> >> let rv .= '%#SpecialKey#'
>> >>   endif
>> >>   let buf = fnamemodify(bufname(tabpagebuflist(i)[icur-1]),':t')
>> >>   if buf == ""
>> >> let buf = '[NoName]'
>> >>   endif
>> >>   let rv .= buf . ' '
>> >>   let i += 1
>> >> endwhile
>> >> let rv .= '%T%=%999X%#Error#X%#Normal#%X'
>> >> return rv
>> >>   endfunction
>> >>   set tabline=%!MyTabLine()
>> >>   set showtabline=2
>> >> endif
>> >>
>> >> Best regards,
>> >> Tony.
>> >
>> > Tony,
>> >
>> > Thanks again for your efforts.
>> >
>> > The code you posted is broken, I'm afraid.  In particular, the following 
>> > example
>> >
>> >   > %{?\"%#Error#BINARY%0*\":\"\"} to output the text BINARY in the
>> >
>> > does not work as you might expect. This has caused me much grief in the 
>> > past couple of weeks of looking for a solution to my problem. It is not 
>> > possible to nest highlight group items within expression items.  I 
>> > certainly wish it were! That would solve ALL of my problems!
>> >
>> > The definition of my statusline can be found here: 
>> > https://github.com/lifecrisis/vim-vimrc/blob/master/vimrc#L434.
>> >
>> > I want to emphasize that I think the documentation here is wrong. To quote 
>> > again:
>> >
>> >   > * -   

Re: Swap directory changes when opening files under /media [Fedora]

[Nikolay Aleksandrovich Pavlov]

2017-04-21 13:16 GMT+03:00 Ian :
> Perfect, thanks. Here's what I get:
>
> --- Auto-Commands ---
> fedora  BufReadPre
> /media/*  set directory=~/tmp,/var/tmp,/tmp
> Last set from /etc/vimrc
> /run/media/*
>   set directory=~/tmp,/var/tmp,/tmp
> Last set from /etc/vimrc
> /mnt/*set directory=~/tmp,/var/tmp,/tmp
> Last set from /etc/vimrc
> ...
>
> This lead me to /etc/vimrc which has a line:
>
>   " don't write swapfile on most commonly used directories for NFS mounts or 
> USB sticks
>   autocmd BufNewFile,BufReadPre /media/*,/run/media/*,/mnt/* set 
> directory=~/tmp,/var/tmp,/tmp
>
> Which confuses me. The aim appears to be to NOT write swap files but all it 
> does is change the location of swap files. And I do want swap files for my 
> mounts in case of recovery.
>
> I am tempted to remove this line though it feels a bit hacky to change this 
> in /etc/vimrc. I will see if I can work out how to override this autocmd in 
> my own profile perhaps.

Files in /etc are editable, it is OK to modify them if you are system
administrator, correct package manager must not overwrite edited files
in /etc. I would suggest to file a bug report to fedora Vim package
maintainers: these autocommands serve no purpose if  option
contains no `.`. Additionally they change a global option so if you
open file in /media and another file you will find out that swap files
for that another file are also put into ~/tmp, or /var/tmp, or /tmp.

>
> --
> --
> 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.

-- 
-- 
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: width of help text on a small device

[Nikolay Aleksandrovich Pavlov]

2017-04-19 13:28 GMT+03:00 Christian Brabandt :
> On Di, 18 Apr 2017, tu...@posteo.de wrote:
>
>> on my 7" tablet (Android) I installed a chrooted Linux on which
>> in turn I installed vim (*not* gvim. *not* neovim. "vim" != "gvim" != 
>> "neovim".
>> The console version. The only one called simply "vim").
>>
>> Unfortunately the tablet is not that wide.
>>
>> With readable sized characters the width is not wide enough to display
>> the help pages in full width. Each line is either wrapped (looks
>> awfull and destroys any table and such) or you have to scroll back
>> and forth each line.
>>
>> Is there a way to initially -- for example when doing "helptags" --
>> re-arrange the help pages to smaller sized widths?
>> How?
>
> What is your textwidth on the device? I believe the help pages are
> written for a textwidth of 78 characters. Perhaps it is enough to set
> 'nowrap' to prevent wrapping. See also the answer from Zyx.

 is “scroll back and forth” option mentioned by the OP.

I would also mention  with , but this is only
slightly better and still going to destroy tables as well, unless OP
adjusts  to match the table each time viewing different
table. Maybe that could be automated though.

>
> Best,
> Christian
> --
> Schön ist eigentliches alles, was man mit Liebe betrachtet.
> -- Christian Morgenstern
>
> --
> --
> 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.

-- 
-- 
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 Improvement suggester

[Nikolay Aleksandrovich Pavlov]

2017-04-18 17:28 GMT+03:00 Patrik Iselind :
> Hi,
>
> I am interested in a way to be suggested what i can improve with my personal 
> usage of Vim commands. So i thought it would be useful if Vim could record 
> the commands i use somehow. Then once a month or something (cron job?) i 
> could get a top 3 suggestion on how i can improve my Vim usage, both to 
> improve speed but mostly to get rid of repetive key pressing that i might not 
> be aware that i'm doing. It could save my joints later in life.
>
> The design and architecture could of course be different from what i describe 
> above but some form of "suggestion box" on how i can improve my personal Vim 
> usage.
>
> Does anyone know of some feature/functionality available that would, at least 
> in part, take me there?
>
> Anyone else that thinks this might be a good idea?
>
> Looking forward to what the list have to say on this.

1. Parsing , see :h 'verbose' and :h 'verbosefile'. Should
only work for Ex commands, but not for normal-mode commands.
2. Recording your input in `-w {scriptout}` and parsing to guess where
are commands there and where is regular input.

Though I am not thinking this would be a good idea: based on my
experience Vim commands are normally not a bottleneck, designing what
and how to write is.

>
> // Patrik
>
> --
> --
> 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.

-- 
-- 
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: width of help text on a small device

[Nikolay Aleksandrovich Pavlov]

2017-04-18 20:51 GMT+03:00  :
> Hi,
>
> on my 7" tablet (Android) I installed a chrooted Linux on which
> in turn I installed vim (*not* gvim. *not* neovim. "vim" != "gvim" != 
> "neovim".
> The console version. The only one called simply "vim").
>
> Unfortunately the tablet is not that wide.
>
> With readable sized characters the width is not wide enough to display
> the help pages in full width. Each line is either wrapped (looks
> awfull and destroys any table and such) or you have to scroll back
> and forth each line.
>
> Is there a way to initially -- for example when doing "helptags" --
> re-arrange the help pages to smaller sized widths?
> How?
>
> Thanks a lot for any help in advance!
> Cheers
> Meino

The help files in question are simple text files with some constructs
which have special meaning. Unlike e.g. ReST-based files which are
parsed into an AST and then converted into something else Vim help has
no structure, only plain text written in a manner “looks like
surrounding text + looks good for me + has (references to) tags where
needed”, so there is basically no way to automatically reformat Vim
help files and guarantee any good results. For the same reason all vim
help to HTML converters yield result which looks like in a editor -
and will have exactly the same problem if you try to view them in the
browser.

You may try setting  to something small enough and use `gq`,
but to have nicely looking results you cannot do this automatically.
And that will help you only in plain paragraphs: some tabs/spaces used
to right-align some text or a table and you are doomed and need to do
the thing manually without even `gq`.

>
>
> --
> --
> 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.

-- 
-- 
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: execute sub command without moving cursor

[Nikolay Aleksandrovich Pavlov]

2017-04-05 22:21 GMT+03:00 Ni Va :
> Hi,
>
>
> I use this kind of command but it moves my cursor pos.
>
>
> silent! exe '?^BEGIN?,/^END/s/^NETWORK.*$/\="NETWORK".s:inc()." \/\/In 
> ".s[0]." : ".s[1]/e'
>
>
> Can I avoid to move cursor when I replace executing sub command ?
> Thanks
> niva

You can restore it afterwards: use winsaveview()+winrestview().
Otherwise you will have to emulate `:substitute` with search() and
setline() and this is going to be way too tricky.

>
> --
> --
> 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.

-- 
-- 
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: Word definition includes period?

[Nikolay Aleksandrovich Pavlov]

2017-04-02 3:17 GMT+03:00 Saurabh T :
> Hi,
>
>
> While using vim 7.4 on cygwin, I noticed that word characters include a
> period, for example "cw" with cursor on the f of file.html attempts to
> change the entire file.html rather than just file. I have LANG set to C and
> "se encoding" shows latin1, and there's not much in vimrc (identical to the
> one on Linux where this works as expected). What may be the problem here?

$LANG is completely irrelevant, the meaning of word (what is treated
as a word character) is controlled by `` option. What is
worse is that there is a number of syntax and ftplugin files which
think that this is not a user setting, so this option is rather
filetype-specific.

Note that resetting it may break syntax, need to adjust syntax file to
use :syn iskeyword. If this is the case it is a bug. Note: :syn
iskeyword is relatively recent addition (7.4.1142, Jan 2016), you may
get a difference in the behaviour solely because your Vim is very
outdated (7.4 was released in Aug 2013).

Also feel free to file a bug report to ftplugin maintainer if filetype
plugin happens to alter this setting.

Do not forget to update Vim before filing any bug reports.

> Thanks,
>
>
> saurabh
>
> --
> --
> 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.

-- 
-- 
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: encoding file

[Nikolay Aleksandrovich Pavlov]

2017-03-12 22:21 GMT+03:00 Ni Va :
> Hi,
>
> I am rreading some windows help in french and got a little pb.
>
> Reading help of robocopy
>
> ---
>ROBOCOPY   ::   Copie de fichiers robuste pour Windows
> ---
>
>   D<82>but instead of Début.
>
>
> In my _vimrc i got these encoding settting :
> set fileencodings=latin1,ucs-bom,utf-8,cp949,euc-kr

`:h 'fileencodings` clearly states that

1. Encodings are searched in order they are given.
2. First encoding which produces no conversion errors is the winner.

So when you use 8-bit encoding like `latin1` first you will never get
conversion errors, you can just as well use `set
fileencodings=latin1`. Also having two 8-bit encodings with full range
occupied is useless: not sure about `euc-kr`, but AFAIK you when you
try having `latin1` or `cp949` automatically detected you always get
whatever is the first of them in the list.

If encoding detection did not work, use `e ++enc=needed_encoding`, `:h ++opt`.

>
>
> Thank for help
>
> --
> --
> 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.

-- 
-- 
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: Ambiguity about what $ means?

[Nikolay Aleksandrovich Pavlov]

2017-03-06 23:09 GMT+03:00 Bram Moolenaar :
>
> Shawn Corey wrote:
>
>> On Mon, 6 Mar 2017 08:01:58 -0800 (PST)
>> Ben Fritz  wrote:
>>
>> > But, you can still match end-of-line in the middle of a pattern using
>> > "\n".
>>
>> No, that matches a new-line character. The difference is that $ matches
>> the end of the line, not a character. This is called an anchor.
>>
>> "Anchors are a different breed. They do not match any character at all.
>> Instead, they match a position before, after, or between characters."
>> http://www.regular-expressions.info/anchors.html
>
> Using '\n' does not match a character.
>
> Don't try to apply terminology from some other regexp engine to Vim, it
> will just confuse you.  In Vim terminology there is no anchor.

For reference: Vim documentation names such things “zero-width match”
(`:h /zero-width`). `\n` may match a character if you use it in
functions like `substitute()` (where pattern applies to one of the
string arguments), but when searching a buffer this is some kind of
pseudocharacter:

1. not zero-width because you can join lines using `s/\n//`,
2. also matches at the very end of the buffer even if `` is
set to zero (designating that last line in the buffer should not end
with a LF/CRLF/CR)
3. matches line end always, regardless of  setting (meaning
that “physically” file may contain \n, \r\n or \r when being written)
4. internally there are no characters corresponding to a line end:
each line is a NUL-terminating C string.

>
> --
> hundred-and-one symptoms of being an internet addict:
> 72. Somebody at IRC just mentioned a way to obtain full motion video without
> a PC using a wireless protocol called NTSC, you wonder how you never
> heard about it
>
>  /// 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.

-- 
-- 
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: How to map to ?

[Nikolay Aleksandrovich Pavlov]

2017-03-06 9:34 GMT+03:00 'Suresh Govindachar' via vim_use
:
> Hello,
>
> How can  be made to work as ?  Following does not work for
> me:
>
>nnoremap  

Why do you use `
> Asking because I want to use  aka  to move among split buffers
> via:
>
> nnoremap  w
>
> while using  and  to navigate the jump-list.
>
> Thanks,
>
> --Suresh
>
> --
> --
> 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.

-- 
-- 
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: autcommand problem.

[Nikolay Aleksandrovich Pavlov]

2017-03-02 10:07 GMT+03:00 sinbad :
> why doesn't the following auto command work. If i run the same command 
> manually it works.
>
>  au BufWritePost *.[ch]
>   \ if ( == 'c' ||  == 'h')
>   \ |  silent call GenerategtagsFiles()
>   \ |  silent execute redraw!

In addition to missing `endif`: `silent execute redraw!` is not going
to work, `execute` receives expression as an argument and `redraw!` is
not one. You actually do not need `execute` here at all, just use
`silent redraw!`.

>
>
> command! GenerategtagsFiles call GenerategtagsFiles()
> function! GenerategtagsFiles()
> silent exectue '!global --single-update '. bufname("%")

There is a typo here, also missing proper escaping for `bufname()`,
and in addition to this `execute` is not needed again:

silent !global --single-update %:S

(`:S` handles escaping for shell).

>
> endfunction
>
> --
> --
> 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.

-- 
-- 
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: How do I get C++ comments to wrap correctly?

[Nikolay Aleksandrovich Pavlov]

2017-03-02 20:07 GMT+03:00 Barry Gold :
> I want to use word-wrap on my C++ comments.
>
> My .vimrc file contains
> set tw=75
> set fo+=tcjro
>
> But when I type a long C++ style comment, I get
> // This object contains the logic (code and data) for making the
> first pass over the input
>
> I want the second line to start with a // like the first one.
>
> Ideally I'd like it to also work for sh-style comments:
> # stuff
> and for javadoc comments
> /**
>  * some stuff that may line-wrap
> */

All of this is done automatically after Vim sources proper filetype
plugin. If you need to do the same stuff without sourcing it, check
`:h 'comments'`.

And note that specifically for C comments this is done by default:
check behaviour of `vim -u NONE -i NONE -N --cmd 'set tw=75
fo+=tcjro'`, it does insert comment leader automatically because
`` option for some reason is set for C by default.

If you do not see this behaviour then you have some plugin and/or
setting interferring.

>
> --
> --
> 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.

-- 
-- 
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: Reload ~/.vim/pythonx libraries without quitting vim?

[Nikolay Aleksandrovich Pavlov]

2017-02-24 15:35 GMT+03:00 BPJ :
> Is there a way to reload libraries in ~/.vim/pythonx (after editing them)
> without quitting/restarting vim?
>
> If there is it's probably in the help, but I usually can't find things there
> without already knowing the tag I should look for...

Without intentionally creating code in libraries (and all of their
users, though you may try to construct something which will only need
code in your library: I have some ideas) which will reload them you
can’t possibly do this properly. You can use `reload()` Python
function (Python-3+: in imp module, Python-2: just there in
__builtin__) and end with a reloaded module in sys.modules, but this
is not going to do you any good in general: all existing references to
your module will still reference the old version.

You may want to check how powerline implements reload():
https://github.com/powerline/powerline/blob/72572c86954cdf8869a1abe9957857f79990d354/powerline/__init__.py#L907.
Note the modules_keeper: I do not remember the details, but it was
fixing some bug. Not sure, but AFAIR one of the initial versions used
reload().

It is also generally good to ask on Python mailing list, Vim does not
provide any code for this job. Additionally you may want to try doing
something on top of Neovim: since it is running Python in a separate
process it may be feasible to kill it and restart. Obviously such
action will take down *all* plugins, not just the one you want to
reload.

>
> TIA,
>
> /bpj
>
> --
> --
> 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.

-- 
-- 
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: syntax question.

[Nikolay Aleksandrovich Pavlov]

2017-02-22 23:10 GMT+03:00 sinbad :
> How does vim syntax formatting works? for instance when i type ':' the whole 
> line gets left justified to the start of the line, though this action makes 
> sense for c-coding, it also happens for other file types. I want to disable 
> this specific syntax action. how can i achieve that ?
>
> :set filetype
>   filetype=new
>
> :set syntax
>   syntax=new
>
> these are my current filtype and syntax settings. I just set both of them to 
> a nonexistent value 'new'. but i still see that left justification.

 is completely irrelevant, it is only used for highlighting.
What you need is normally managed by indentation scripts placed in
`{runtimepath}/indent/{filetype}.vim` (uses ). But in
addition to indentation scripts there are default values, specifically
all options containing indent are relevant: `:helpgrep
\*'\w*indent\w*'\*` (or use the same search in `:h options.txt`). Also
there may be option values leaked from previously open filetypes or
global settings set in vimrc/etc.

The easiest solution should be `:setlocal indentkeys-=:`, but this
will only disable reindenting on colon. Vim will *still* think that
line needs to be shifted to the start, yet it will not autoindent when
you type colon.

>
> --
> --
> 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.

-- 
-- 
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: Buffer number explodes when :vimgrep is called.

[Nikolay Aleksandrovich Pavlov]

2017-02-15 3:00 GMT+03:00  :
> Hello all,
>
> When I call :vimgrep, I'll usually search a directory of 600-1000 files.  The 
> number of unlisted buffers explodes after the call (I assume because buffers 
> must be loaded into vim in order for the text to be searched).  Lately I've 
> been using buffer numbers for navigation, but entering three-digit buffer 
> numbers has become annoying. Is this property of :vimgrep able to be switched 
> off with a Vim setting?  I'm surprised I can't find another instance of this 
> question being asked online...
>
> On the note of buffer numbers, is it advisable that I side-step using buffer 
> numbers for navigation/file switching and find a better way?  What would more 
> experienced users suggest?

I like fuzzy-finder plugins for navigating buffers. Specifically I use
Command-T which requires +ruby, but there are lots of alternatives:
unite/denite, CtrlP, FUF, ku, constructing something on top of tlib, I
also saw a Command-T reimplementation in Python somewhere.

My workflow also suggests that I open all project file with a single
shell command and then use Command-T to navigate through
already-created (though not yet loaded, Vim does not load all files
specified on command-line immediately) buffers because scanning
filesystem of large projects sucks; or, at least, sucket last time I
bothered to use it in Command-T: zsh does scanning much faster (also
because it does not attept to scan absolutely everything: I have
specific globs) though yet it can’t beat `find` if you consider only
speed.

There is also a good replacement for :vimgrep: ag.vim uses less
verbose PCRE syntax (via ag aka the_silver_searcher), runs much faster
and will not load all files ag visits.

>
> Best,
> Jason
>
> --
> --
> 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.

-- 
-- 
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: Python 2/3 scripting in vimscript

[Nikolay Aleksandrovich Pavlov]

2017-02-07 17:27 GMT+03:00 Jonathan Crall :
> I've recently made the jump to python3 and I went to recompile vim with 
> +python3 instead of +python. When I did this I noticed that all my python 
> blocks in my .vimrc were failing.

You can compile with both +python/dyn and +python3/dyn

>
> Example of a python block:
> ```
> python << endpython
> # 
> endpython
> ```
>
>
> I was able to replace all of these with
> ```
> python3 << EOF
> # 
> EOF
> ```

It is bad idea to have such blocks: every variable defined inside is
global. Use modules.

>
> but all of my code in these blocks is 2/3 compatible and is critical for my 
> .vimrc to function properly. Furthermore, I have several external vimscripts 
> that use python blocks and having to change those is a pain.
>
> Is there a way to dynamically define which python script to use?
>
> ```
> if has('python3')
> #define pythonX python3
> else
> #define pythonX python2
> endif
>
> pythonX << EOF
> # 
> EOF
> ```

With modules it is really easy to write

execute g:myplugin_python 'import myplugin; myplugin.do_stuff()'

where `g:myplugin_python` is either `python` or `python3`.

Recently a patch was made to add `:pythonx` command which may use
either version of Python, but I would not recommend using it in
plugins (except that it is a good idea to check for it when setting
default value of `g:myplugin_python`) for at least a year: Vim
versions without :pythonx are going away rather slowly.

>
> --
> --
> 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.

-- 
-- 
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: How to open another file and go to a search pattern

[Nikolay Aleksandrovich Pavlov]

2017-01-27 15:20 GMT+03:00 Mayuresh <mayur...@acm.org>:
> Sorry, when typing out text I have made some mistakes, which may have
> given wrong impressions of what I tried at a couple of places. I should
> have rather pasted the code I tried, but I had changed it by the time I
> thought of writing a mail. Will correct it now.
>
> On Fri, Jan 27, 2017 at 02:13:24PM +0300, Nikolay Aleksandrovich Pavlov wrote:
>> > function! GoToFile()
>> > let line = getline(".")
>> > let searchpat = split(line,":")[1]
>> > let file = split(line," ")[1]
>> > " See below what all I tried here
>> > endfunction
>> > map  :exec GoToFile()
>>
>> Given how this function looks, you should not be using `:execute`. For
>> calling functions there is `:call`. This works only because
> Point taken.
>
>> > 1. Tried loading the file and searching in it using two different
>> > statements:
>> >
>> > exec "e" file
>> > search(searchpat,"")
>> >
>> > With this, I find that such search is applied to current file instead of
>> > new file and then the file is loaded. I find this strange.
>>
>> How did you check that “search is applied to current file”? I see that
>> these commands are not going to work because there is no `:search`
>> command.
>
> Clarification: Tried exec search(searchpat)

That does not make sense, `search` already moves cursor. No need to
make `exec` move cursor afterwards (similar problem to the above
point).

> It did not search in the current file. (My mistake in above  mail.)
>
> However the other thing that I tried was:
> exec "/"searchpat
> or more precisely, to avoid an extra space after "/"
> exec join(["/",searchpat],"")

If you want to avoid spaces, do use concat.

:execute arg1 arg2

is the same thing as

:execute arg1." ".arg2

for convenience. You just need to have explicit concat:

:execute arg1.arg2

does not add any spaces.

>
> On either of these the message "Search hit bottom " appeared in the
> current buffer itself. Only on hitting Enter the next file was opened.
> From this I thought it is searching in current file.
>
>> And you forgot `fnameescape()`. First line should be `:execute 'e'
>> fnameescape(file)` or you get problems with special characters in
>> `file`.
> Thanks for the tip. Will incorporate.
>
>> > 2. From above, assuming loading and searching as two statements won't
>> > work, tried:
>> >
>> > exec "+/" searchpat file
>> >
>> > But this breaks with searchpat having spaces (even if I use \" to cover
>> > the search pattern).
>>
>> ?! This command is not opening a file, it will run something like
>>
>> +/{space}{search pattern}{space}{filename}
>>
>> : perform search in the current file, starting from the current line
>> (same {range} without command interpretation).
>
> Precise command is:
>
> exec "e " join(["+/",searchpat],"") file
>
> This is opening the file, but to highlight the pattern I have to press
> "/". Looking for this last step to happen automatically.

I am unable to move to the search result even with this code. You are
using :execute on a function which returns 0, it *must* bring you to
the first line once function exits, so all your attempts to move to
the search pattern are useless. To move and highlight you need to use
something like

execute 'edit' fnameescape(file)
let @/ = searchpat
normal! gg0n

. E.g. this works as I expect:

vim -u gtf.vim -i NONE -N

" gtf.vim:
function GoToFile() abort
let line = getline(".")
let [file, searchpat] = matchlist(line, '\v\C^(.{-})\ \:\ (.*)$')[1:2]
execute 'edit' fnameescape(file)
let @/ = searchpat
normal! gg0n
endfunction
nnoremap  :call GoToFile()

call writefile(['/tmp/gtf-test : abc def'], '/tmp/gtf-test-init')
call writefile(['foo', 'abc def'], '/tmp/gtf-test')
set hlsearch
edit /tmp/gtf-test-init
call feedkeys("gg\", "t")

. Note:

0. `nnoremap`: you must not use `*map` without `nore` unless you know
what you are doing. This avoids possible issues with other mappings.
1. `:`: check how function behaves when you press `10` without this.
2. `call GoToFile()`, not `execute`.
3. Original `file` and `searchpat` definition will not work correctly
with `SomeFileName : Some Multiple Words of Search Pattern`. I assumed
that code is wrong, not example line.

>
> Mayuresh
>
> --
&g

Re: How to open another file and go to a search pattern

[Nikolay Aleksandrovich Pavlov]

2017-01-27 5:46 GMT+03:00 Mayuresh :
> I have a requirement where the cursor is on following line:
>
> SomeFileName : Some Multiple Words of Search Pattern
>
> I want to define a hot key (Say ) to open SomeFileName and go to and
> highlight the whole pattern "Some Multiple Words of Search Pattern"
>
> Following is my attempt to solve it, which has not succeeded fully:
>
> In vimrc:
>
> function! GoToFile()
> let line = getline(".")
> let searchpat = split(line,":")[1]
> let file = split(line," ")[1]
> " See below what all I tried here
> endfunction
> map  :exec GoToFile()

Given how this function looks, you should not be using `:execute`. For
calling functions there is `:call`. This works only because

1. Without explicit `:return` statement function returns `0` at exit.
2. Vim can implicitly convert numbers to strings.
3. `:{range}` takes you to the last line in range if run without a command.
4. Line number 0 means first line, even though first line has number 1.

>
> Following things are tried at the end of the function:
>
>
> 1. Tried loading the file and searching in it using two different
> statements:
>
> exec "e" file
> search(searchpat,"")
>
> With this, I find that such search is applied to current file instead of
> new file and then the file is loaded. I find this strange.

How did you check that “search is applied to current file”? I see that
these commands are not going to work because there is no `:search`
command.

And you forgot `fnameescape()`. First line should be `:execute 'e'
fnameescape(file)` or you get problems with special characters in
`file`.

>
>
> 2. From above, assuming loading and searching as two statements won't
> work, tried:
>
> exec "+/" searchpat file
>
> But this breaks with searchpat having spaces (even if I use \" to cover
> the search pattern).

?! This command is not opening a file, it will run something like

+/{space}{search pattern}{space}{filename}

: perform search in the current file, starting from the current line
(same {range} without command interpretation).

>
>
>
> 3. To overcome above problem, I replaced all spaces in searchpat with ".".
> Now this is closest to what I need. But now the pattern is not highlighted
> automatically. I have to say "/" to get the search pattern again
> interactively and then it jumps to and highlights the pattern.
>
>
> Sorry about the length of mail. Just wanted to share whatever is already
> tried to describe the problem.
>
> Hope some solution is possible.
>
> Mayuresh
>
> --
> --
> 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.

-- 
-- 
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: GNU screen hardstatus line

[Nikolay Aleksandrovich Pavlov]

2017-01-25 19:12 GMT+03:00 Allan :
> Hi
>
> Is there a way to note down the starting time or the duration of the current 
> screen session? I always resume after a long time after and feel it would be 
> helpful to know when the screen session was started.

`ps -p {process id} -o etime` (for the current shell: `ps -p $$ -o
etime`). Universal, works for every app. Though can’t say how this
interacts with hibernation and  suspends.

May need to check `pstree -p -h` or `ps -t $TTY` to get `{process id}`.

>
> Thanks
>
> --
> --
> 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.

-- 
-- 
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: Powerline without commandline?

[Nikolay Aleksandrovich Pavlov]

2017-01-22 3:09 GMT+03:00 Benny Powers :
> Hello,
>
> I'm trying to replicate the screenshots on 
> https://github.com/powerline/powerline, meaning a single powerline at the 
> bottom of the vim screen. What I get is a powerline, followed by the standard 
> vim commandline (--INSERT-- or ".config/vim/vimrc" 29L, 748C), then the tmux 
> powerline below that. What I'd like is just a single vim powerline, followed 
> by the tmux powerline below that.

There are no such screenshots: what you see is the screenshot of
status line only. And AFAIK moving status line onto the command line
is not possible: you can make command line occupy more space (:h
'cmdheight'), but you can’t make it occupy zero space.

>
> Here is my vimrc.
>
> python from powerline.vim import setup as powerline_setup
> python powerline_setup()
> python del powerline_setup
>
> set nocompatible  " be iMproved, required
> filetype off  " required
>
> " set the runtime path to include Vundle and initialize
> set rtp+=~/.config/vim/bundle/Vundle.vim
> call vundle#begin()
> " alternatively, pass a path where Vundle should install plugins
> "call vundle#begin('~/some/path/here')
>
> " let Vundle manage Vundle, required
> Plugin 'VundleVim/Vundle.vim'
>
> " All of your Plugins must be added before the following line
> call vundle#end()" required
> filetype plugin indent on" required
>
> set relativenumber
> set number
> syntax on
> set tabstop=2
> set shiftwidth=2
>
> set ls=2
> set noshowmode
> set noruler
>
> --
> --
> 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.

-- 
-- 
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: How to modify the trigger key in the snip mate?

[Nikolay Aleksandrovich Pavlov]

2017-01-15 17:32 GMT+03:00 Zhe Lee :
> The mappings SnipMate uses can be customized with the |:map| commands. For
> example, to change the key that triggers snippets and moves to the next
> tab stop, >
>
> :imap  snipMateNextOrTrigger
> :smap  snipMateNextOrTrigger
>
>
> I check the doc, and find the lines above,
>
> but when I press c-j in vim the literaly "snipMateNextOrTrigger" text 
> was inserted in the vim. why is that?

Did you use literally `:imap` or used `:inoremap` instead?

>
> --
> --
> 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.

-- 
-- 
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: Issue with using gvim system() and fzy

[Nikolay Aleksandrovich Pavlov]

2017-01-09 0:18 GMT+03:00 Gary Johnson :
> On 2017-01-08, justrajdeep wrote:
>> On Saturday, January 7, 2017 at 1:20:14 PM UTC-5, Gary Johnson wrote:
>> > On 2017-01-07, Justin M. Keyes wrote:
>> >
>> > > On Jan 6, 2017 17:09, "justrajdeep" wrote:
>> >
>> > >> Having an issue while doing a system() call with 
>> > >> fzy(https://github.com/
>> > >> Dkendal/fzy-vim)from inside gvim
>> > >>
>> > >> Code snippet
>> > >>
>> > >>   silent let output = system("ag -l -g '' --nocolor | fzy")
>> > >>
>> > >>   Decho(1)
>> > >>   Decho (output)
>> > >>   Decho(2)
>> > >>   Decho(3)
>> > >>
>> > >>
>> > >> The output is
>> > >>
>> > >> 1
>> > >> Failed to open /dev/tty^J
>> > >> 2
>> > >> 3
>> > >>
>> > >>
>> > >> If i remove fzy from the command the result is fine. Can someone 
>> > >> please
>> > >> help me debugging the issue?
>> >
>> > > Most likely, fzy wants to write to a tty, not a file.
>> >
>> > Looking at the web page https://github.com/jhawthorn/fzy, it's
>> > pretty clear that fzy writes directly to a terminal, separately from
>> > its stdout, which vim running in a termina provides, but which gvim
>> > doesn't.
>> >
>> > Regards,
>> > Gary
>>
>>
>> Thanks Gary,
>>
>> Can you please point me to the details of this in vim help or
>> somewhere? Sorry I am new to vim programming and would like to
>> understand the difference and try to see if I can somehow get it
>> working.
>
> Hi Rajdeep,
>
> I couldn't find a very detailed explanation in the Vim help.  There
> is a little bit here.
>
> :help gui-pty
>
> I originally thought the problem was just that the terminal
> emulation provided by gvim lacked some of the capabilities needed by
> fzy, but that's not what fzy is complaining about when it says it
> "Failed to open /dev/tty".
>
> fzy assumes that it is running in a terminal and that this terminal
> can be accessed by the device name /dev/tty.  That is true when fzy
> is run from the shell executed by a terminal emulator or by vim's or
> gvim's :sh command, and it is true when fzy is run from the shell
> executed by vim's system() function, but it is not true when fzy is
> run from the shell executed by gvim's system() function.
>
> You can see that by running "tty < /dev/tty" in those environments.
> In all cases but one the command prints "/dev/tty".  When run in
> a system() function from within gvim, the results are different:
>
> :echo system("tty < /dev/tty")
> /bin/bash: /dev/tty: No such device or address
>
> But you _can_ send output from a system() command to the pty that
> gvim creates for shell commands.
>
> :!tty
> /dev/pts/16
> :call system("ls > /dev/pts/16")
>
> So, if one could coerce gvim or the shell into creating a /dev/tty
> for programs run from system() in a GUI environment, as is done now
> for :! and :sh, then your fzy command should work.
>
> I don't know why gvim's system() doesn't do that already.

This is too much work: basically you need to reimplement terminal
emulator and somehow integrate it with the rest of the UI. You should
rather ask why Vim does not follow Neovim way which intentionally
disallows access to /dev/tty from system() or :! so a set of dirty,
unportable hacks do not work (hacks require both terminal Vim and
*nix).

Note that GVim does not provide fully featured terminal emulator. Do
not try to write just `ls` output there, try using something which
emits control sequences which change color or move cursor: both are
required for fzy to work and “terminal emulator” attached to the
pseudo-terminal created by GVim will fail interpreting them correctly.

>
> Regards,
> Gary
>
> --
> --
> 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.

-- 
-- 
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: What's the minimum version of GCC required to build the latest Vim? Are there any patches to allow one to build it with even older versions of GCC?

[Nikolay Aleksandrovich Pavlov]

2017-01-08 17:40 GMT+03:00 Brenton Horne :
> Sorry, I just read about how it can't be in HTML. Here is the message
> without HTML
>
> Hi,
>
> I maintain Vim packages in my Open Build Service home project, for
> example here are the packaging files I use to build it for
> CentOS/Fedora/Scientific Linux
> https://build.opensuse.org/package/show/home:fusion809/vim-redhat. I
> would like to build Vim for CentOS 5 and 6, but I cannot presently do
> this, because the build fails and I think the reason why is that GCC
> is too old. So I am here to ask what's the minimum version of GCC
> required to build the latest Vim (so 8.0) and are there any ways to
> build Vim with an older GCC? The build log (showing the error from
> building Vim on 64-bit CentOS 6) can be found here
> (https://build.opensuse.org/build/home:fusion809/CentOS_6/x86_64/vim/_log),
> if you're wondering whether it's a bug.

This does not look like something that has something to do with GCC:
apart from “may be used uninitialized” warnings there are only
“undefined reference” errors which indicate that your system has no
(not true: configure found it) or incompatible (most likely outdated)
ncurses library. First try to supply to configure script something
other then --with-tlib=ncurses: search for tlibs in src/configure.ac
for a list, but guess better start with absent --with-tlib argument
and check whether automatic detection succeeds.

>
> Thanks for your time,
> Brenton
>
> On 9 January 2017 at 00:38, Brenton Horne  wrote:
>> Hi,
>>
>> I maintain Vim packages in my Open Build Service home project, for example
>> here are the packaging files I use to build it for CentOS/Fedora/Scientific
>> Linux https://build.opensuse.org/package/show/home:fusion809/vim-redhat. I
>> would like to build Vim for CentOS 5 and 6, but I cannot presently do this,
>> because the build fails and I think the reason why is that GCC is too old.
>> So I am here to ask what's the minimum version of GCC required to build the
>> latest Vim (so 8.0) and are there any ways to build Vim with an older GCC?
>> The build log (showing the error from building Vim on 64-bit CentOS 6) can
>> be found here, if you're wondering whether it's a bug.
>>
>> Thanks for your time,
>> Brenton
>
>
>
> --
> Thanks for your time,
> Brenton
>
> --
> --
> 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.

-- 
-- 
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: How to use * to search the word with dash under cursor?

[Nikolay Aleksandrovich Pavlov]

2017-01-08 4:45 GMT+03:00 Zhe Lee :
>
>
> for example the text is like this
> ```
> a-b
> b-c
> a-b
>
> ```
>
>
> if the cursor is on the first line first column (on `a` now). And then I 
> press `*` I want to find the `a-b` but the vim just search `a` instead of 
> `a-b`, so how to make * to include the dash `-`?

This is controlled by  option (:h 'iskeyword'). Beware that
many syntax and some filetype plugin files think that  is
not a user setting.

>
> --
> --
> 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.

-- 
-- 
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: perl vs python bindings for vim and tab page object access

[Nikolay Aleksandrovich Pavlov]

2017-01-06 5:56 GMT+03:00 Arif Khokar :
> [I sent this to the vim_dev list earlier, but didn't get a response]
>
> After looking through the documentation for if_perl and if_pyth, I noticed
> that the python bindings had the ability to query and manipulate tab page
> objects, while the perl bindings did not.
>
> Is there a technical reason for the difference (i.e., a limitation for the
> perl C bindings?), or is it something that was never implemented?

Perl is not so popular nowadays, so there are less authors willing to
contribute to if_perl.xs. I do not think there are any technical
reasons (I do not know XS, but I am the person who initially wrote
Python tab page objects and can say that there should not be any
problems on the Vim side and given that there are objects like $curbuf
I do not see why there could not be something like $tabpages).

>
> --
> --
> 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.

-- 
-- 
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: 'maxfuncdepth' ignored

[Nikolay Aleksandrovich Pavlov]

2017-01-02 23:36 GMT+03:00 Brett Stahlman :
> On Monday, January 2, 2017 at 11:40:32 AM UTC-6, ZyX wrote:
>> 2017-01-01 0:40 GMT+03:00 Brett Stahlman :
>> > On Saturday, December 31, 2016 at 12:23:10 PM UTC-6, ZyX wrote:
>> >> 2016-12-30 20:09 GMT+03:00 Brett Stahlman :
>> >> > Consider the following recursive user function...
>> >> >
>> >> > fu! Fun(count)
>> >> > if a:count > 0
>> >> > call Fun(a:count - 1)
>> >> > endif
>> >> > endfu
>> >> >
>> >> > :h 'maxfuncdepth' describes the option's purpose as follows:
>> >> >
>> >> > Maximum depth of function calls for user functions.  This normally
>> >> > catches endless recursion.  When using a recursive function with
>> >> > more depth, set 'maxfuncdepth' to a bigger number.
>> >> >
>> >> > So I would expect to be able to make the following recursive call with 
>> >> > no error:
>> >> > :set maxfuncdepth=1000
>> >> > :call Fun(500)
>> >> >
>> >> > But I get the following error after slightly less than 200 recursive 
>> >> > calls:
>> >> > E169: Command too recursive
>> >> >
>> >> > The documentation for E169 states the following:
>> >> >
>> >> > This happens when an Ex command executes an Ex command that executes an 
>> >> > Ex
>> >> > command, etc.  This is only allowed 200 times.  When it's more there 
>> >> > probably
>> >> > is an endless loop.  Probably a |:execute| or |:source| command is 
>> >> > involved.
>> >> >
>> >> > It's as though the :call (Ex command) is triggering the error long
>> >> > before the number of calls to the user function Fun() has reached
>> >> > 'maxfuncdepth'. But if this is the way it's supposed to work, what's
>> >> > the point of 'maxfuncdepth'? Don't all calls to user functions involve
>> >> > an Ex command (since both `call' and `let' are Ex commands)? Is there
>> >> > a way to permit more than 200 recursive calls to Fun() without
>> >> > triggering the error?
>> >>
>> >> I tried lambdas, but they also catch this error due to the way they
>> >> are implemented. Unlike (until you consider their internal
>> >> implementation) lambdas regular functions are lists of Ex commands, so
>> >> this is not surprising. Note that by default  is 100
>> >> which is lesser then 200.
>> >
>> > Hmm... Perhaps Bram will weigh in on this, but effectively limiting 
>> > 'maxfuncdepth' to 200 feels like an unintended consequence, rather than 
>> > design intent - especially since the help on 'maxfuncdepth' makes no 
>> > mention of the limit. The documentation on E169 suggests that the purpose 
>> > of the 200 limit is to detect certain types of recursion involving :source 
>> > and :execute commands. If it was meant to apply to function calls 
>> > generally, why even have a separate option for function calls, especially 
>> > if you can't increase its value to something that would permit meaningful 
>> > recursion?
>> >
>> > Since there's no option governing the E169 limit, perhaps it could be 
>> > changed to the maximum of 200 and 'maxfuncdepth'. Or perhaps it could take 
>> > into account the type of Ex command (i.e., source/execute vs call/let). Or 
>> > perhaps there could be a 'maxmemfunc' option (analogous to 
>> > 'maxmempattern'), which would limit function call recursion by stack space 
>> > consumed (or some rough approximation thereof) rather than # of calls.
>>
>> Limiting stack space consumed should be cleaner and more in line with
>> the purpose of the limit (recursive nature of VimL executor and a
>> number of different functions requires either imposing such limits or
>> catching stack overflows). I am not sure though whether it is possible
>> to get stack space consumption rate on any of the platforms Vim
>> supports: after some searching I found only a number of dirty hacks
>> like in 
>> http://stackoverflow.com/questions/53827/checking-available-stack-size-in-c.
>>  would be possible if VimL executor was not recursive and
>> reimplemented stack based on malloc() like some other interpreted
>> languages do, but it is recursive and uses system stack instead.
>
> I can definitely see advantages to a limit based on memory usage, but I 
> haven't looked at the VimL implementation to see what sort of added 
> complexity that would entail. In addition to the overhead of the function 
> calls themselves, there's also the memory allocated (dynamically) by each 
> function invocation to consider. I'm guessing that's stored on some sort of 
> Vim heap (not on the system stack).
>
> Example:
> fu! Func()
> let big_data = Build_big_data_structure()
> .
> .
> call Func()
> endfu
>
> Using 'maxfuncdepth' for E169 is probably the simplest approach, and the only 
> downside is that if the user does something stupid, he could exhaust process 
> memory. But he could already do that: consider that Build_big_data_structure 
> in the example above could build an arbitrarily large structure on each 
> recursive invocation, such 

Re: 'maxfuncdepth' ignored

[Nikolay Aleksandrovich Pavlov]

2017-01-01 0:40 GMT+03:00 Brett Stahlman :
> On Saturday, December 31, 2016 at 12:23:10 PM UTC-6, ZyX wrote:
>> 2016-12-30 20:09 GMT+03:00 Brett Stahlman :
>> > Consider the following recursive user function...
>> >
>> > fu! Fun(count)
>> > if a:count > 0
>> > call Fun(a:count - 1)
>> > endif
>> > endfu
>> >
>> > :h 'maxfuncdepth' describes the option's purpose as follows:
>> >
>> > Maximum depth of function calls for user functions.  This normally
>> > catches endless recursion.  When using a recursive function with
>> > more depth, set 'maxfuncdepth' to a bigger number.
>> >
>> > So I would expect to be able to make the following recursive call with no 
>> > error:
>> > :set maxfuncdepth=1000
>> > :call Fun(500)
>> >
>> > But I get the following error after slightly less than 200 recursive calls:
>> > E169: Command too recursive
>> >
>> > The documentation for E169 states the following:
>> >
>> > This happens when an Ex command executes an Ex command that executes an Ex
>> > command, etc.  This is only allowed 200 times.  When it's more there 
>> > probably
>> > is an endless loop.  Probably a |:execute| or |:source| command is 
>> > involved.
>> >
>> > It's as though the :call (Ex command) is triggering the error long
>> > before the number of calls to the user function Fun() has reached
>> > 'maxfuncdepth'. But if this is the way it's supposed to work, what's
>> > the point of 'maxfuncdepth'? Don't all calls to user functions involve
>> > an Ex command (since both `call' and `let' are Ex commands)? Is there
>> > a way to permit more than 200 recursive calls to Fun() without
>> > triggering the error?
>>
>> I tried lambdas, but they also catch this error due to the way they
>> are implemented. Unlike (until you consider their internal
>> implementation) lambdas regular functions are lists of Ex commands, so
>> this is not surprising. Note that by default  is 100
>> which is lesser then 200.
>
> Hmm... Perhaps Bram will weigh in on this, but effectively limiting 
> 'maxfuncdepth' to 200 feels like an unintended consequence, rather than 
> design intent - especially since the help on 'maxfuncdepth' makes no mention 
> of the limit. The documentation on E169 suggests that the purpose of the 200 
> limit is to detect certain types of recursion involving :source and :execute 
> commands. If it was meant to apply to function calls generally, why even have 
> a separate option for function calls, especially if you can't increase its 
> value to something that would permit meaningful recursion?
>
> Since there's no option governing the E169 limit, perhaps it could be changed 
> to the maximum of 200 and 'maxfuncdepth'. Or perhaps it could take into 
> account the type of Ex command (i.e., source/execute vs call/let). Or perhaps 
> there could be a 'maxmemfunc' option (analogous to 'maxmempattern'), which 
> would limit function call recursion by stack space consumed (or some rough 
> approximation thereof) rather than # of calls.

Limiting stack space consumed should be cleaner and more in line with
the purpose of the limit (recursive nature of VimL executor and a
number of different functions requires either imposing such limits or
catching stack overflows). I am not sure though whether it is possible
to get stack space consumption rate on any of the platforms Vim
supports: after some searching I found only a number of dirty hacks
like in 
http://stackoverflow.com/questions/53827/checking-available-stack-size-in-c.
 would be possible if VimL executor was not recursive and
reimplemented stack based on malloc() like some other interpreted
languages do, but it is recursive and uses system stack instead.

>
> I noticed this because I'm running a tree processing algorithm that is 
> inherently recursive. I had intended to compute 'maxfuncdepth' as a function 
> of another option, but discovered that my choice was silently ignored for 
> anything over 200. Although the depth of the trees can exceed 200 in extreme 
> cases, the depth is bounded and known, so it made sense simply to boost 
> 'maxfuncdepth' long enough to recurse the tree. If there's no way around the 
> 200 maximum, I'll probably have to rewrite the algorithm to use breadth-first 
> traversals, rather than the much more natural (and simple) tree recursion.
>
> Thanks,
> Brett Stahlman
>
>>
>> >
>> > Thanks,
>> > Brett Stahlman
>> >
>> > --
>> > --
>> > 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.
>
> --
> --
> You received 

Re: 'maxfuncdepth' ignored

[Nikolay Aleksandrovich Pavlov]

2016-12-30 20:09 GMT+03:00 Brett Stahlman :
> Consider the following recursive user function...
>
> fu! Fun(count)
> if a:count > 0
> call Fun(a:count - 1)
> endif
> endfu
>
> :h 'maxfuncdepth' describes the option's purpose as follows:
>
> Maximum depth of function calls for user functions.  This normally
> catches endless recursion.  When using a recursive function with
> more depth, set 'maxfuncdepth' to a bigger number.
>
> So I would expect to be able to make the following recursive call with no 
> error:
> :set maxfuncdepth=1000
> :call Fun(500)
>
> But I get the following error after slightly less than 200 recursive calls:
> E169: Command too recursive
>
> The documentation for E169 states the following:
>
> This happens when an Ex command executes an Ex command that executes an Ex
> command, etc.  This is only allowed 200 times.  When it's more there probably
> is an endless loop.  Probably a |:execute| or |:source| command is involved.
>
> It's as though the :call (Ex command) is triggering the error long
> before the number of calls to the user function Fun() has reached
> 'maxfuncdepth'. But if this is the way it's supposed to work, what's
> the point of 'maxfuncdepth'? Don't all calls to user functions involve
> an Ex command (since both `call' and `let' are Ex commands)? Is there
> a way to permit more than 200 recursive calls to Fun() without
> triggering the error?

I tried lambdas, but they also catch this error due to the way they
are implemented. Unlike (until you consider their internal
implementation) lambdas regular functions are lists of Ex commands, so
this is not surprising. Note that by default  is 100
which is lesser then 200.

>
> Thanks,
> Brett Stahlman
>
> --
> --
> 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.

-- 
-- 
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: Inconsistent json_encode() behaviors regarding empty (sub)strings

[Nikolay Aleksandrovich Pavlov]

2016-12-22 9:20 GMT+03:00 Kay Zheng :
> Hi folks,
>
> I was trying out the new channel APIs, and found a little glitch in
> the built-in function json_encode():
>
> call assert_equal('', 'a'[1:0]) " pass
> call assert_equal('""', json_encode('')) "pass
> call assert_equal('""', json_encode('a'[1:0])) " fail,
> json_encode(...) returns 'null'
>
> I failed to see any content about the sub-string syntax str[a:b] in
> the documents, but it seems legit for sub-lists, so I've been using it
> all over my code, until encode_json('a'[1:0]) gave me 'null' as a
> result.
>
> I was running Vim version 8.0.134. Is this a bug?

This kind of failure is observed for NULL strings (e.g. like returned
by test_null_string()). Given that NULL strings are an optimization
for empty strings I consider this a bug. Neovim does not have it:
https://github.com/neovim/neovim/blob/aa4ef8966c12a6bd51d31ce32618e9844053aa04/test/functional/eval/json_functions_spec.lua#L763-L765,
https://github.com/neovim/neovim/blob/aa4ef8966c12a6bd51d31ce32618e9844053aa04/test/unit/eval/tricks_spec.lua#L21-L34.

>
> Regards,
> Kay. Z
>
> --
> --
> 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.

-- 
-- 
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: How to fold or hide the comment in vimrc file?

[Nikolay Aleksandrovich Pavlov]

2016-12-16 17:43 GMT+03:00 Gary Johnson <garyj...@spocom.com>:
> On 2016-12-16, Nikolay Aleksandrovich Pavlov wrote:
>> 2016-12-16 5:41 GMT+03:00 Zhe Lee
>> > I want to fold or hide the comment in the vimrc file.
>> > I Google it and find mainly the 2 solution below but none of them worked.
>> >
>> >
>> > syn match comment "\v(^\s*\".*\n)+" fold
>> >
>> > set foldmethod=expr foldexpr=getline(v:lnum)=~'^\s*"'
>> >
>> >
>> > My Vimrc file is like this, when I enter the 2 commands above nothing 
>> > happens.
>>
>> First solution is incomplete (and probably will work only if you
>> disable syntax highlighting or modify syntax/vim.vim file, not sure),
>> second solution is incorrect: while it clearly was supposed to set
>> `` to `getline(v:lnum)=~'^\s*"'`, it really sets it to
>> `getline(v:lnum)=~'^s`: missing proper escaping results in `\s`
>> transformed into `s` (backslash needs to be escaped) and `"` starting
>> a comment (needs to be escaped too). In addition to this it is using
>> :set setting global values alongside with local while it should use
>> :setlocal to set only local values. Proper second variant is
>>
>> let :foldexpr='getline(v:lnum)=~#'.string('^\s*"')
>
> Setting 'foldexpr' doesn't have to be that complicated.  Simply
> fixing the escaping of the backslash and the double-quote will fix
> the problem.
>
> setlocal foldmethod=expr foldexpr=getline(v:lnum)=~'^\\s*\"'

Do not use :set* for more or less complex string options, it is too
easy to make a mistake. It is more complicated then using :let: when
you use :let you simply create a string with necessary contents,
without caring about escaping specifically used for :set. Knowing how
to write a string literal is useful in many places, including `:let
:…`, and you also may employ your knowledge of YAML, JSON, C, etc
string escapes here (string literals of different languages have lots
of things in common). Knowing how to escape a string for :set* is
useful only for escaping strings for :set, and I hardly need this
knowledge even for writing modelines (the only place where you can’t
use :let syntax).

>
> Regards,
> Gary
>
> --
> --
> 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.

-- 
-- 
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.