Re: [Bulk] [patch] getcmdwintype()

['Andy Wokula' via vim_dev]

Am 25.07.2014 21:04, schrieb Jacob Niehus:

I think this is a useful function to allow different mappings
depending on the type of command window (ex, search, input, etc.). I
can add documentation if people agree.

-Jake


You can already check expand(afile) on CmdWinEnter.

Seems to be buggy for `q/', for me it returns `\' then.

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: {func} of sort()

['Andy Wokula' via vim_dev]

Am 19.08.2014 um 11:17 schrieb mattn:

Keys?  v:key is list index, it cannot contain spaces.
Spaces in values shouldn't matter.
Not sure what you mean.


I wonder this won't works correctly.

[{a: b}, {a b: }]


Guessing you want to sort by dict key:
:echo MapSort([{a: b}, {a b: }], 'keys(v:val)[0]')
[{'a': 'b'}, {'a b': ''}]

the following list is given to the sort() function:
:echo map([{a: b}, {a b: }], 'keys(v:val)[0]')
['a', 'a b']

actually within MapSort(), the index is appended:
['a 0', 'a b 1']

(not so nice, but) shouldn't make a difference for sort().

Sorting by dict value:
:echo MapSort([{a: b}, {a b: }], 'values(v:val)[0]')
[{'a b': ''}, {'a': 'b'}]

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: Add count to :close and :hide commands

['Andy Wokula' via vim_dev]

Am 10.08.2014 20:33, schrieb Marcin Szamotulski:

On 15:51 Sun 10 Aug , Bram Moolenaar wrote:


I wrote:


Marcin Szamotulski wrote:


I wrote a patch which adds [count] to :colse, :hide and ^Wc normal
command.  When given the window with window number [count] will be
closed/hidden.  Sometimes I want to close not the current window but
another one, this command let to do that without switching windows
without ^Ww normal command.


Nice idea.  I would find :1close and :9close the most useful,
closing the first and last window.  Looks like the code does take the
last window when the count is more than the number of windows.  This
isn't obvious in the documentation, adding these two as an example will
make them found quicker.  And perhaps :hide docs should refer to the
explanation of [count] in :close.

How about a test?


Thinking about this, it would also be very nice to be able to close the
next or previous window:

:+1close
:-1close

And there is this entry in the todo list:

Can't easily close the help window, like :pc closes the
preview window and :ccl closes the quickfix window.  Add
:hclose. (Chris Gaal)
Patch for :helpclose, Christian Brabandt, 2010 Sep 6.

Looks like I'm a bit behind including patches...


Here is the patch.  As a bonus:
 :$close  will close the last window
 :$-close  will close the penultimate window
 :.close   the same as :close
 :%close, :/pattern/close, :*close, ...  will emit E16 error

There are probably a few other commands that could benefit with
a similar approach.

Best regards,
Marcin Szamotulski


Some people expect  :1,$bd  or :%bd  to delete all buffers.

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: [patch] :undorecover command

['Andy Wokula' via vim_dev]

Am 16.08.2014 21:25, schrieb Christian Brabandt:

The command is named :undorecover?
Some places use :undorecovery (help, EMSG).

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: {func} of sort()

['Andy Wokula' via vim_dev]

Am 21.08.2014 um 03:50 schrieb mattn:

About making list sorted by string of one of value.

echo 3  3 0

This is TRUE, then:

echo MapSort([{foo:{bar: 3}}, {foo:{bar: 3 0}}],
'v:val[foo][bar]')

We expecet it should be kept:

[{foo:{bar: 3}}, {foo:{bar: 3 0}}]

But results are:

[{'foo': {'bar': '3 0'}}, {'foo': {'bar': '3'}}]

We need to escape string to avoid to handle index as value.


I don't think so.


I don't want to need to provide this function in all plugins. Just
want to get it in official sort function.


The reason is:
   :echo sort(['3 0', '3 0 1'])
   ['3 0 1', '3 0']

I'd expect ['3 0', '3 0 1'].
   :echo '3 0'  '3 0 1'
   1

Bug in sort() function?

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: [Bulk] Re: Add count to :close and :hide commands

['Andy Wokula' via vim_dev]

Am 21.08.2014 um 07:49 schrieb Christian Brabandt:

Am 2014-08-20 19:03, schrieb 'Andy Wokula' via vim_dev:

Some people expect  :1,$bd  or :%bd  to delete all buffers.


That only works by accident, because your current buffer has more
lines than you have open buffers.

Or saying it differently, this does not work in an empty buffer.

So this expectation is not really valid.

Best, Christian


Er, what you cited implies that it doesn't work at the moment
(as expected (by some people (for a long time))).

The idea is to make it become valid ...


Marcin Szamotulski wrote:

There are probably a few other commands that could benefit with a
similar approach.


Got it?

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: {func} of sort()

['Andy Wokula' via vim_dev]

Am 22.08.2014 um 02:05 schrieb mattn:

It need to do like below with MapSort()

echo MapSort([{foo:{bar: 3}}, {foo:{bar: 3 0}}], '0 + 
v:val[foo][bar]')

If using my patch, it is possible easy to avoid this.

:echo sort([3 0, 3 0 1], a:lhs  a:rhs)


I suppose your examples should read as follows (?):
:echo MapSort([{foo:{bar: 3}}, {foo:{bar: 3 0}}], 
'v:val.foo.bar')
:echosort([{foo:{bar: 3}}, {foo:{bar: 3 0}}], 'v:lhs.foo.bar 
 v:rhs.foo.bar')

With MapSort(), you have to derive strings from you list items, as plain sort() 
can only compare strings.

It's easy to turn positive integers into strings for comparison.
(It's hard to turn floats into strings for comparison.)


And MapSort() can't look local variable in the expression. For example, this 
doesn't work.



---
function! s:foo()
   let rank = {queen: 12, king: 13}
   return MapSort([queen, king], 'rank[v:val]')
endfunction
echo s:foo()


It can use local variables, with a little change to the func sig:
MapSort(list, selexpr, ...)
now you can place a:1, a:2, ... in your map expression:

function! s:foo()
let rank = {queen: 9, king: 10}
return MapSort([queen, king], 'NumStr(a:1[v:val])', rank)
endfunction
echo s:foo()

(where NumStr() turns 9 into 'A9' and 10 into 'B10')

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Performance improvement: skip applying of modelines if nothing was done in `:doautocmd`

['Andy Wokula' via vim_dev]

Am 20.10.2014 um 08:23 schrieb Daniel Hahler:

I have seen a noticeable performance problem when using the
`vim-oblique` plugin, which was caused by calls to `doautocmd User
...` - although the user events did not exist
(https://github.com/junegunn/vim-oblique/issues/30).

While there is the `nomodeline` option for `:doautocmd`, Vim could
always skip applying the modeline (again) in case no commands were
executed.


I want unconditional execution of modelines.

 :DoModelines
 manually execute the modelines (no matching autocmds is a good thing
 here, we only need the side effect of :doautocmd); added 2010 Sep 27

com! -bar DoModelines :silent doautocmd User DoModelines

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: [Bulk] Performance improvement: skip applying of modelines if nothing was done in `:doautocmd`

['Andy Wokula' via vim_dev]

Am 21.10.2014 um 16:51 schrieb Christian Brabandt:

On Mo, 20 Okt 2014, Daniel Hahler wrote:


Am Montag, 20. Oktober 2014 19:55:53 UTC+2 schrieb Andy Wokula:


I want unconditional execution of modelines.

 :DoModelines
 manually execute the modelines (no matching autocmds is a good thing
 here, we only need the side effect of :doautocmd); added 2010 Sep 27

com! -bar DoModelines :silent doautocmd User DoModelines


Ok. But this appears to be a candidate for a separate command then.


Attached patch does that.


Wouldn't `:e` work for you, too?


That loses your changes.


So far this patch works for me.
:domodelines executes modelines.
:doau only executes modelines when there are matching autocommands.

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: typo in tag for :help :si

['Andy Wokula' via vim_dev]

Am 19.12.2014 um 16:55 schrieb Bram Moolenaar:


Yukihiro Nakadaira wrote:


I think that short tag for :simalt should be :sim.

diff -r ab36689121ad runtime/doc/gui_w32.txt
--- a/runtime/doc/gui_w32.txtWed Dec 17 21:00:49 2014 +0100
+++ b/runtime/doc/gui_w32.txtThu Dec 18 19:31:16 2014 +0900
@@ -452,7 +452,7 @@
  You can drag and drop one or more files into the Vim window, where they
will
  be opened as normal.  See |drag-n-drop|.

-*:simalt* *:si*
+*:simalt* *:sim*
  :sim[alt] {key}simulate pressing {key} while holding Alt pressed.
  {not in Vi} {only for Win32 versions}


Actually, :simalt is the first command that starts with :si, thus that
works.  We might as well document it that way:  :si[malt]


:si  is  :s  with  `i' flag.

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Vim 2015 calendar available

['Andy Wokula' via vim_dev]

Am 19.12.2014 um 15:27 schrieb Bram Moolenaar:


Hello Vim users,

I have updated the handy desktop calendar for 2015.  It prints on one
sheet of paper and, after folding and applying a bit of glue, stands on
your desk.

It is available in English and Dutch.  You can find the PDF files on my
website: http://moolenaar.net/#Calendar

If you are doing your Christmas shopping on Amazon, please consider
using the links on this page: http://www.iccf.nl/click1.html
A percentage of the sales will go to Vim's charity, helping children in
Uganda, and it doesn't cost you anything.

Otherwise, consider making a donation: http://www.iccf.nl/donate.html
And for a very special Christmas present: Sponsor a child!
http://www.iccf.nl/sponsor.html

Happy Vimming!


What about a German (localized) version?

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

List of 2-letter and 3-letter substitute commands

['Andy Wokula' via vim_dev]

What about a help section for the following special commands?

2-letter and 3-letter :substitute commands
==

  List of :substitute commands
  |  cegiInplr
  | c  :sc  :sce :scg :sci :scI :scn :scp :scl  ---
  | e
  | g  :sgc :sge :sg  :sgi :sgI :sgn :sgp :sgl :sgr
  | i  :sic :sie  --- :si  :siI :sin :sip  --- :sir
  | I  :sIc :sIe :sIg :sIi :sI  :sIn :sIp :sIl :sIr
  | n
  | p
  | l
  | r  :src  --- :srg :sri :srI :srn :srp :srl :sr
  Exceptions:
  :scr  is  :scriptnames
  :se   is  :set
  :sig  is  :sign
  :sil  is  :silent
  :sn   is  :snext
  :sp   is  :split
  :sl   is  :sleep
  :sre  is  :srewind

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: typo in tag for :help :si

['Andy Wokula' via vim_dev]

Am 19.12.2014 um 16:55 schrieb Bram Moolenaar:


Yukihiro Nakadaira wrote:


I think that short tag for :simalt should be :sim.

diff -r ab36689121ad runtime/doc/gui_w32.txt
--- a/runtime/doc/gui_w32.txtWed Dec 17 21:00:49 2014 +0100
+++ b/runtime/doc/gui_w32.txtThu Dec 18 19:31:16 2014 +0900
@@ -452,7 +452,7 @@
  You can drag and drop one or more files into the Vim window, where they
will
  be opened as normal.  See |drag-n-drop|.

-*:simalt* *:si*
+*:simalt* *:sim*
  :sim[alt] {key}simulate pressing {key} while holding Alt pressed.
  {not in Vi} {only for Win32 versions}


Actually, :simalt is the first command that starts with :si, thus that
works.  We might as well document it that way:  :si[malt]


I'd rather wish for

*:scr* *:scriptnames*
:scr[iptnames]  List all sourced script names, in the order they were

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: [Bulk] Re: typo in tag for :help :si

['Andy Wokula' via vim_dev]

Am 20.12.2014 um 11:33 schrieb Bram Moolenaar:


Andy Wokula wrote:


Am 19.12.2014 um 16:55 schrieb Bram Moolenaar:


Yukihiro Nakadaira wrote:


I think that short tag for :simalt should be :sim.

diff -r ab36689121ad runtime/doc/gui_w32.txt
--- a/runtime/doc/gui_w32.txtWed Dec 17 21:00:49 2014 +0100
+++ b/runtime/doc/gui_w32.txtThu Dec 18 19:31:16 2014 +0900
@@ -452,7 +452,7 @@
   You can drag and drop one or more files into the Vim window, where they
will
   be opened as normal.  See |drag-n-drop|.

-*:simalt* *:si*
+*:simalt* *:sim*
   :sim[alt] {key}simulate pressing {key} while holding Alt pressed.
   {not in Vi} {only for Win32 versions}


Actually, :simalt is the first command that starts with :si, thus that
works.  We might as well document it that way:  :si[malt]


I'd rather wish for
*:scr* *:scriptnames*
:scr[iptnames]  List all sourced script names, in the order they were


What do you mean, wish for?  It appears :scr does work as
:scriptnames.  Although both c and r are flags for :s.


At the moment, according to help, only :scrip is reserved for :scriptnames.
It would be nice if :scr continues to work for :scriptnames and not for another 
command.

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: Implementing TabNew event

['Andy Wokula' via vim_dev]

Am 23.12.2014 um 03:32 schrieb Felipe Morales:

I've been working on the implementation of WinNew, and I have some doubts:

1) Should WinNew trigger when a new tab page is created?
2) Should TabNew/WinNew trigger right before/after VimEnter? After all, windows 
and tabs are created at that point.
3) These events, as currently implemented, are triggered before BufEnter 
events, and as such can't initialize t: and w: variables for the new tab and 
window page, which might perhaps be unexpected to users. Perhaps a couple of 
events that triggered after BufEnter but only on new windows and tab pages 
could be useful.

Regards,

Felipe Morales


You mention t: and w: variables.
Can't make use of such variables to emulate TabNew, WinNew?

(when entering and variable not set, this is tabnew or winnew situation, set 
the variable)

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.215, split modified

['Andy Wokula' via vim_dev]

Am 25.03.2014 um 13:05 schrieb Bram Moolenaar:

Patch 7.4.215
Problem:Inconsistency: :sp foo does not reload foo, unless foo is
the current buffer. (Liang Li)
Solution:   Do not reload the current buffer on a split command.
Files:  runtime/doc/windows.txt, src/ex_docmd.c


Added some keywords to find this again.  Looks like this also fixes

Subject: inconsistent :split behavior
https://groups.google.com/forum/#!topic/vim_dev/-24sxEcEfDc
(Ben Fritz, Jun 2008)

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: range('a', 'c') should be ['a', 'b', 'c']

['Andy Wokula' via vim_dev]

Am 13.01.2015 um 02:09 schrieb mattn:

I know what i want can do with map(range(char2nr('a'), char2nr('z')), 
'nr2char(v:val)').

But it's too long. I think.


If you want everything builtin, then what's the purpose of user functions?

--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: BUG: Unclosed regexp collection breaks :substitute

['Andy Wokula' via vim_dev]

Am 14.03.2015 um 20:14 schrieb Ingo Karkat:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-Mar-2015 15:34, Bram Moolenaar wrote:


Ingo Karkat wrote:


On 14-Mar-2015 02:11, James McCoy wrote:

On Fri, Mar 13, 2015 at 09:54:18PM +0100, Ingo Karkat wrote:

it's possible to avoid escaping a [ character:

,[ :help E769 ] | When the ']' is not there Vim will
not give an error message but | assume no collection is used.
Useful to search for '['. `

But when using that feature in a :substitute command, the
replacement part is mistakenly added to the pattern:

:s/[//g E486: Pattern not found: [//g


No, that's not what's happening.  You can leave off the entire
  replacement and the delimiter before it.  When this happens,
Vim treats it as deleting the matching strings.  To quote:

If the {string} is omitted the substitute is done as if it's
empty. Thus the matched pattern is deleted.  The separator
after {pattern} can also be left out then.  Example: 
:%s/TESTING This deletes TESTING from all lines, but only one
per line.


Right. My point is that because the / delimiters are not
actually left off (they are there, in the correct, unescaped
form), the :s command *mistakenly* runs into the case you've
quoted. Putting it yet another way, the [ consumes the
following characters (including the unescaped separators),
assuming they belong to the collection, and when at the end the
collection isn't closed, the parsing should backtrack and
reinterpret, but it currently doesn't.


I understand that this is confusing, but it's working as
documented.


I don't see this particular behavior documented. I would expect
something like this (highlighting the current inconsistencies):
An unclosed [ will do a literal search, but when such pattern is
directly included in a :substitute command (but not when such pattern
is reused from the last search via :s//...), the remainder is
interpreted as the pattern; i.e. you cannot add a replacement part and
:s_flags there.


The alternative, detecting the unclosed [ in some circumstances,
will make it less consistent and probably even more confusing.  So
let's just leave it as it is.


I've never argued for that. Of course, the unclosed [ would have to be
detected in _all_ circumstances. That shouldn't be too difficult; the
regexp engines already do that.


It's clear that if you type the wrong command things may go wrong.


I don't think :s/[/x/g is wrong. It simply parses as pattern=[,
replacement=x, flags=g. Unfortunately, Vim's implementation is buggy
and parses it as pattern=[/x/g replacement= flags= (because the [...]
collection parsing suspends the delimiter parsing until the closing ],
but this isn't a collection, so it shouldn't apply!)

If I had wanted that, I would rather type :s/[\/x\/g (or
:s/[\/x\/g//), i.e. properly escape the / delimiters.


I think the current behavior is ok (snafu ...).
If you use [ unescaped, you should know what you are doing.
Because: even with correct parsing, the pattern may still change, eg
what if ] occurs in the replacement part:
:s/[/x]/g

Now the original pattern [ becomes [/x] and the only fix is
:s/\[/x]/g


That's what we have undo for.


As I said, I'm mostly worried about plugins blindly putting @/ into
the :substitute (maybe with prepending / appending something else, and
then failing due to the inconsistency caused by the bug. That would be
hard to detect by the user; undo wouldn't help much.

I'm all for consistency, and fixing this bug would IMO increase that,
so that the special case of unclosed [ and the :s/// separators
interact in a benign way. I was motivated to report this because one
Vim user was struggling with just this, and went to Stack Overflow to
ask for help.

- -- regards, ingo


--
Andy

--
--
You received this message from the vim_dev 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_dev group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Bulk] Re: List of 2-letter and 3-letter substitute commands

['Andy Wokula' via vim_dev]

Am 20.12.2014 um 11:33 schrieb Bram Moolenaar:

Andy Wokula wrote:


What about a help section for the following special commands?

2-letter and 3-letter :substitute commands
==

List of :substitute commands
|  cegiInplr
| c  :sc  :sce :scg :sci :scI :scn :scp :scl  ---
| e
| g  :sgc :sge :sg  :sgi :sgI :sgn :sgp :sgl :sgr
| i  :sic :sie  --- :si  :siI :sin :sip  --- :sir
| I  :sIc :sIe :sIg :sIi :sI  :sIn :sIp :sIl :sIr
| n
| p
| l
| r  :src  --- :srg :sri :srI :srn :srp :srl :sr
Exceptions:
:scr  is  :scriptnames
:se   is  :set
:sig  is  :sign
:sil  is  :silent
:sn   is  :snext
:sp   is  :split
:sl   is  :sleep
:sre  is  :srewind


This would be useful, if we add help tags.


See attachment.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff -r 30042ddff503 runtime/doc/change.txt
--- a/runtime/doc/change.txtTue Oct 13 23:30:05 2015 +0200
+++ b/runtime/doc/change.txtSat Oct 17 13:48:50 2015 +0200
@@ -1,4 +1,4 @@
-*change.txt*For Vim version 7.4.  Last change: 2015 Sep 06
+*change.txt*For Vim version 7.4.  Last change: 2015 Oct 17
 
 
  VIM REFERENCE MANUALby Bram Moolenaar
@@ -637,6 +637,11 @@
The space between `:substitute` and the 'c', 'g',
'i', 'I' and 'r' flags isn't required, but in scripts
it's a good idea to keep it to avoid confusion.
+   *:sc* *:sce* *:scg* *:sci* *:scI* *:scl* *:scp* *:sg* *:sgc* 
*:sge* *:sgi* *:sgI* *:sgl*
+   *:sgn* *:sgp* *:sgr* *:sI* *:si* *:sic* *:sIc* *:sie* *:sIe* 
*:sIg* *:sIl* *:sin* *:sIn*
+   *:sIp* *:sip* *:sIr* *:sir* *:sr* *:src* *:srg* *:sri* *:srI* 
*:srl* *:srn* *:srp*
+   A :substitute command |:&| with one or two [flags].
+
 
 :[range]~[&][flags] [count]*:~*
Repeat last substitute with same substitute string
diff -r 30042ddff503 runtime/doc/tags
--- a/runtime/doc/tags  Tue Oct 13 23:30:05 2015 +0200
+++ b/runtime/doc/tags  Sat Oct 17 13:48:50 2015 +0200
@@ -2714,6 +2714,14 @@
 :rviminfo  starting.txt/*:rviminfo*
 :s change.txt  /*:s*
 :s%change.txt  /*:s%*
+:sIchange.txt  /*:sI*
+:sIc   change.txt  /*:sIc*
+:sIe   change.txt  /*:sIe*
+:sIg   change.txt  /*:sIg*
+:sIl   change.txt  /*:sIl*
+:sIn   change.txt  /*:sIn*
+:sIp   change.txt  /*:sIp*
+:sIr   change.txt  /*:sIr*
 :sNwindows.txt /*:sN*
 :sNext windows.txt /*:sNext*
 :s\=   change.txt  /*:s\\=*
@@ -2745,6 +2753,13 @@
 :sbr   windows.txt /*:sbr*
 :sbrewind  windows.txt /*:sbrewind*
 :sbuffer   windows.txt /*:sbuffer*
+:scchange.txt  /*:sc*
+:scI   change.txt  /*:scI*
+:sce   change.txt  /*:sce*
+:scg   change.txt  /*:scg*
+:sci   change.txt  /*:sci*
+:scl   change.txt  /*:scl*
+:scp   change.txt  /*:scp*
 :scr   repeat.txt  /*:scr*
 :scripte   repeat.txt  /*:scripte*
 :scriptencodingrepeat.txt  /*:scriptencoding*
@@ -2778,8 +2793,20 @@
 :sfind windows.txt /*:sfind*
 :sfir  windows.txt /*:sfir*
 :sfirstwindows.txt /*:sfirst*
+:sgchange.txt  /*:sg*
+:sgI   change.txt  /*:sgI*
+:sgc   change.txt  /*:sgc*
+:sge   change.txt  /*:sge*
+:sgi   change.txt  /*:sgi*
+:sgl   change.txt  /*:sgl*
+:sgn   change.txt  /*:sgn*
+:sgp   change.txt  /*:sgp*
+:sgr   change.txt  /*:sgr*
 :shvarious.txt /*:sh*
 :shell various.txt /*:shell*
+:sichange.txt  /*:si*
+:sic   change.txt  /*:sic*
+:sie   change.txt  /*:sie*
 :sig   sign.txt/*:sig*
 :sign  sign.txt/*:sign*
 :sign-define   sign.txt/*:sign-define*
@@ -2794,6 +2821,9 @@
 :silentvarious.txt /*:silent*
 :sim   gui_w32.txt /*:sim*
 :simaltgui_w32.txt /*:simalt*
+:sin   change.txt  /*:sin*
+:sip   change.txt  /*:sip*
+:sir   change.txt  /*:sir*
 :slvarious.txt /*:sl*
 :sla   windows.txt /*:sla*
 :slast windows.txt /*:slast*
@@ -2838,8 +2868,16 @@
 :split_f   windows.txt /*:split_f*
 :spr   windows.txt /*:spr*
 :sprevious windows.txt /*:sprevious*
+:srchange.txt  /*:sr*
+:srI   change.txt  /*:srI*
+:src   change.txt  /*:src*
 :sre   windows.txt /*:sre*
 :srewind   windows.txt /*:srewind*
+:srg   change.txt  

Re: [patch] Add Error autocmd event

['Andy Wokula' via vim_dev]

Am 09.02.2016 um 20:48 schrieb Anton Lindqvist:

Can you think of a command or situation where this patch provides a
nice, useful solution?


Other than the examples already provided, here's a couple of ideas:

- Opening a new file in a non existing directory and then write triggers a E212
   which could be caught and then before writing again try to create the
   directory (%:h) of the file.


You can already do something like (quoted from somewhere ...):

:au BufWrite * if v:cmdbang && !isdirectory(expand('%:h')) | cal 
mkdir(expand('%:h'), 'p')| endif

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim 8 pre-announcement

['Andy Wokula' via vim_dev]

Am 16.08.2016 um 18:43 schrieb Bram Moolenaar:

Hello Vim users,

Work on Vim 8.0 is coming close to an end.  I hope version 8.0 can be
released in about two weeks.

This is a last chance to modify new features in a way that is not
backwards compatible.  Once 8.0 is out we can't make changes that would
break plugins.


Can we have 'langnoremap' renamed to 'langremap' please?

Double negation is confusing.

And it's more consistent with 'remap' (although that option should be removed 
...).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: some improvements for feedkeys()

['Andy Wokula' via vim_dev]

Am 06.09.2016 um 20:42 schrieb Christian Brabandt:

Bram,
if in a test we do this:
 call feedkeys('d1', 'x!')
 call feedkeys('2l', 'x')

Vim will stay in the first feedkeys() call and wait for input.

I'd like to have feedkeys() return after CursorHold triggered,


You say Vim waits for input ... how does it trigger CursorHold then?


but have it not finished/aborted the first call, so that in the end
this command is executed:
d12l where a cursorhold command triggered after the 1


except you don't get a CursorHold ... (?)


Does that sound possible or should we not worry about those special case
(see normal.c:602)


--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Add columnspace option (#1011)

['Andy Wokula' via vim_dev]

Am 08.09.2016 um 16:41 schrieb Christian Brabandt (Vim Github Repository):

what problem does this solve?


Probably the same problem partly solved with 'linespace'.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: some improvements for feedkeys()

['Andy Wokula' via vim_dev]

Am 09.09.2016 um 09:22 schrieb Christian Brabandt:

Hi 'Andy!

On Do, 08 Sep 2016, 'Andy Wokula' via vim_dev wrote:


Am 06.09.2016 um 20:42 schrieb Christian Brabandt:

Bram,
if in a test we do this:
 call feedkeys('d1', 'x!')
 call feedkeys('2l', 'x')

Vim will stay in the first feedkeys() call and wait for input.

I'd like to have feedkeys() return after CursorHold triggered,


You say Vim waits for input ... how does it trigger CursorHold then?


CusorHold is only triggered, if Vim is waiting for input. The problem
however in the tests is, that the keyboard buffer is never empty, so we
can't really test the CursorHold autocommand.


Why do you want to "test" CursorHold in a situation where it is not supposed
to be triggered?

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 7.4.2259

['Andy Wokula' via vim_dev]

Am 27.08.2016 um 13:35 schrieb Bram Moolenaar:


Urtica Dioica wrote:


I do like the idea for the feature. I tried it, it has some bugs, but
they'll get ironed out eventually.

But I've gotta ask, does no one else use search command line history?
The new bindings override the old forward/backward command history
bindings (and that are still used by the other command lines). The
only way to access search history now is with the command line window
().

Is that the plan? I won't fight the decision, but I will say I'm not
happy losing the old (useful) bindings.


Hmm, I thought that the keys were unused in this mode.  But you are
right, they were used for command line history.

Looking for other keys, there are not so many available:
CTRL-@
CTRL-G
CTRL-O
CTRL-T
CTRL-X

Note that CTRL-T already has a meaning of going to an older tag stack
entry.  So using it for "previous" makes some sense.
On the other hand, CTRL-O hints at Older.

Note that while searching for this the new CTRL-N and CTRL-P were
actually useful.

Taking up two more characters for this means there is hardly any left.
But there isn't much choice.  Adding an option to change the behavior is
not nice either.

So how about this:  Use CTRL-T for going up, like what CTRL-P did, and
use CTRL-G for going down, what CTRL-N did.  On a regular keyboard the T
is above the G, so that's the hint for the user.


What about a sub-mode started with CTRL-X where you can use `n' and `N'?

In Insert mode there is already such a mode for scrolling:
   i_CTRL-X_CTRL-E
then, CTRL-E / CTRL-Y can be used to scroll down/up.

This could even be used (later) to scroll the window while in Cmdline mode.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

(bug) :sil!, :try and :echoerr

['Andy Wokula' via vim_dev]

gVim 7.4.2239

:sil! throw 'foo'
" throws exception (ok)
" :h :sil  only talks about error messages, not exceptions

:sil! try|echoerr 'foo'|endtry
" nothing, should probably throw an exception, given
" error message is turned into an exception according to :h :echoerr
" worse: this command confuses Vim

:sil! throw 'foo'
" nothing (bug)

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Variable nested too deep for displaying

['Andy Wokula' via vim_dev]

Am 13.03.2017 um 23:03 schrieb Bram Moolenaar:

Andy Wokula wrote:


(I'm using a pre-Vim 8.0 version).

Still: can somebody confirm the following bug:

" script.vim
let s:f = {}

func! s:f.Foo()
endfunc

let s:f.Bar = s:f.Foo

let s:f

finish

Error detected while processing script.vim:
line   15:
E724: variable nested too deep for displaying
s:f   {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74',
  ... more nesting removed ...
)})})})})})})})})})})})})})})})}


That is normal.  Use this instead:


But why is s:f.Bar different from s:f.Foo ?


echo s:f

Then recursive references are shortened.


Older Vim versions did not output a dictionary at all.
I'd prefer the old behavior then.
... which anyway looked better (less garbage in the output!).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

['Andy Wokula' via vim_dev]

Am 14.03.2017 um 09:57 schrieb Nikolay Aleksandrovich Pavlov:

2017-03-14 0:29 GMT+03:00 Bram Moolenaar :


Andy Wokula wrote:


Am 13.03.2017 um 21:00 schrieb Ben Fritz:

On Sunday, March 12, 2017 at 10:33:06 AM UTC-5, Bram Moolenaar
wrote:

Someone noticed that although $ takes a count to go down (count -
1) lines, the ^ does not.  Since currently the count is ignored, we
could make it used to go (count - 1) lines up.

Would this break anything?



We currently have _ and g_ that are similar to ^ and $, except that ^
doesn't take a count.

_ goes downward or stays on the same line. To move up, you can use -,
which always goes up, it won't stay on the same line.

It would make more sense for me if ^ went downward rather than upward
when given a count. This would be consistent with existing commands.
But I won't be extremely disappointed if it goes upward instead, it
would just be one more oddity in an editor full of such quirks. :-)


I'd vote for  [count]^  going to the [count]th character in the line.
(We can easily go to the [count]th screen column and to the [count]th
byte, but not yet to the [count]th character, unless I'm missing
something).


You can already use 3| to go to the third screen position.  Only with
double-wide characters you would see a difference with character count.


Also with tabs. And, possibly, with combining characters: depends on
the definition of the “character”. Though I do not know why one would
want to go to the N’th character in first place.

@Andy Wokula define a “character”. This term is neither obvious nor
non-controversal. This looks like Vim documentation is mostly taking
it as “unicode codepoint” given statements like “composing characters
are considered separate characters here”, but yet it is clear that
“character” may mean something different (or such statements would not
be needed).


This sounds like a secondary question.
And if there is no clear definition => one more Vim option.

For now I use the `l' motion in my mapping to get to the target character
(with default 'virtualedit' and 'whichwrap').

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

['Andy Wokula' via vim_dev]

Am 13.03.2017 um 22:29 schrieb Bram Moolenaar:


Andy Wokula wrote:


Am 13.03.2017 um 21:00 schrieb Ben Fritz:

On Sunday, March 12, 2017 at 10:33:06 AM UTC-5, Bram Moolenaar
wrote:

Someone noticed that although $ takes a count to go down (count -
1) lines, the ^ does not.  Since currently the count is ignored, we
could make it used to go (count - 1) lines up.

Would this break anything?



We currently have _ and g_ that are similar to ^ and $, except that ^
doesn't take a count.

_ goes downward or stays on the same line. To move up, you can use -,
which always goes up, it won't stay on the same line.

It would make more sense for me if ^ went downward rather than upward
when given a count. This would be consistent with existing commands.
But I won't be extremely disappointed if it goes upward instead, it
would just be one more oddity in an editor full of such quirks. :-)


I'd vote for  [count]^  going to the [count]th character in the line.
(We can easily go to the [count]th screen column and to the [count]th
byte, but not yet to the [count]th character, unless I'm missing
something).


You can already use 3| to go to the third screen position.  Only with
double-wide characters you would see a difference with character count.


For me, because of tab characters.


Anyway, the most important aspect of ^ is that it goes to the first
non-blank character.  Adding a count, similar to what that does to $,
should move lines up or down.  Perhaps going down is better than going
up, but moving horizontally goes against logic.


How is `^' stricter related to `$' than `|'?
Because of the similar meaning in regexp-patterns?
But then it's odd that `^' moves to the first non-blank instead of
the very first character.
(or `$' should move to the last non-blank in the line).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

['Andy Wokula' via vim_dev]

Am 13.03.2017 um 21:00 schrieb Ben Fritz:

On Sunday, March 12, 2017 at 10:33:06 AM UTC-5, Bram Moolenaar
wrote:

Someone noticed that although $ takes a count to go down (count -
1) lines, the ^ does not.  Since currently the count is ignored, we
could make it used to go (count - 1) lines up.

Would this break anything?



We currently have _ and g_ that are similar to ^ and $, except that ^
doesn't take a count.

_ goes downward or stays on the same line. To move up, you can use -,
which always goes up, it won't stay on the same line.

It would make more sense for me if ^ went downward rather than upward
when given a count. This would be consistent with existing commands.
But I won't be extremely disappointed if it goes upward instead, it
would just be one more oddity in an editor full of such quirks. :-)


I'd vote for  [count]^  going to the [count]th character in the line.
(We can easily go to the [count]th screen column and to the [count]th
byte, but not yet to the [count]th character, unless I'm missing
something).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Variable nested too deep for displaying

['Andy Wokula' via vim_dev]

(I'm using a pre-Vim 8.0 version).

Still: can somebody confirm the following bug:

" script.vim
let s:f = {}

func! s:f.Foo()
endfunc

let s:f.Bar = s:f.Foo

let s:f

finish

Error detected while processing script.vim:
line   15:
E724: variable nested too deep for displaying
s:f   {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74', {'Foo': function('74'), 'Bar': function('74', {'Foo': 
function('74'), 'Bar': function('74', {'Foo': function('74'), 'Bar': 
function('74',
... more nesting removed ...
)})})})})})})})})})})})})})})})}

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add a count to the ^ command?

['Andy Wokula' via vim_dev]

Am 13.03.2017 um 21:18 schrieb Ben Fritz:

On Monday, March 13, 2017 at 3:11:04 PM UTC-5, Ben Fritz wrote:

On Monday, March 13, 2017 at 3:04:51 PM UTC-5, Andy Wokula wrote:


I'd vote for  [count]^  going to the [count]th character in the
line. (We can easily go to the [count]th screen column and to the
[count]th byte, but not yet to the [count]th character, unless
I'm missing something).



While useful, "[count]th character" doesn't seem to fit well with
"1st non-blank character" to me.


It's just a default position.
It's clear that "non-blank" does not necessarily have a meaning with
count.


Maybe "[count]th non-blank
character" would make more sense but I'm not sure how useful that
would be.


..actually on further thought, "[count]th non-blank" could be useful
for editing text in comments where ^ by itself is less useful.
Consider:

//this is
//a multiline comment
//which has been indented

One could then use 3^ to jump to the beginning of the comment text.



Of course right now one can simply ^W to accomplish the same thing.
But although the same number of keystrokes, it's 2 commands instead
of just one. This could make a difference in operator-pending mode,
for example.


Going to the first non-blank after a comment leader deserves yet
another motion, right?
(and with count, it would go to another line)

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regression: Patch 7.4.709

['Andy Wokula' via vim_dev]

Am 19.07.2017 um 22:22 schrieb Bram Moolenaar:


Andy Wokula wrote:


Looks like Patch 7.4.709 isn't ok yet, even the test is wrong:

" starting at first tab page (see link):
tabmove 5
call assert_equal(5, tabpagenr())

should be
call assert_equal(6, tabpagenr())

because it's supposed to move the tab page to *after* tab page number 5;

when starting at a higher tab page (e.g. 9) it works ok (as it used to be in 
older Vims),
but the test is missing, something like:

 normal! 9gt
 tabmove 5
 call assert_equal(6, tabpagenr())

https://github.com/vim/vim/blob/master/src/testdir/test_tabpage.vim#L83
(at v8.0.0734)


In my idea it's OK.  Say you start with these tab pages:

1  one
2  two
3  three
4  four
5  five

Now you do ":tabmove 3", so it move to after "three".  Result:

1  two
2  three
3  one
4  four
5  five

So the current tab is now 3.  It moves to after "three", and since all
the tab pages move left one place you end up at tab page 3.


To me, that interpretation feels weird.
I think the changed behavior was just an undesired side effect of the patch
which just nobody noticed so far.

It was different before, and more logical IMHO,
because one could use a formula for the target tab page that
didn't depend on the number of the current tab page.

And: if there are two possible interpretations, we should prefer
the backwards compatible one, right?
(I mean backwards compatible to before 7.4.709)

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regression: Patch 7.4.709

['Andy Wokula' via vim_dev]

Am 20.07.2017 um 15:35 schrieb 'Andy Wokula' via vim_dev:

Am 19.07.2017 um 22:22 schrieb Bram Moolenaar:

In my idea it's OK.


It's not important actually, and if nobody else cares,
I'll just throw in some Vimscript, it's an easy workaround.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Regression: Patch 7.4.709

['Andy Wokula' via vim_dev]

Looks like Patch 7.4.709 isn't ok yet, even the test is wrong:

  " starting at first tab page (see link):
  tabmove 5
  call assert_equal(5, tabpagenr())

should be
  call assert_equal(6, tabpagenr())

because it's supposed to move the tab page to *after* tab page number 5;

when starting at a higher tab page (e.g. 9) it works ok (as it used to be in 
older Vims),
but the test is missing, something like:

   normal! 9gt
   tabmove 5
   call assert_equal(6, tabpagenr())

https://github.com/vim/vim/blob/master/src/testdir/test_tabpage.vim#L83
(at v8.0.0734)

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Regression: Patch 7.4.709

['Andy Wokula' via vim_dev]

Am 20.07.2017 um 20:24 schrieb Tony Mechelynck:

FWIW, I also think that :tabmove 5 should move the current tab after
what is now tab 5.

Andy: when you do ":1,5move 10", where would you expect the present
first 5 lines to go? After the present line 10 (becoming lines 5-10
after the move) or after the present line 15 (becoming lines 10-15
after the move)? I would expect the former.

Best regards,
Tony.


I see what we have now makes a lot of sense when people put tab page
numbers (like line numbers) on their tab labels. And that's why there
will probably no change.

But otherwise your analogy also suggests that
:1,5 tabmove 10
should move the first 5 tab pages to after tab page number 10
(which it doesn't (yet)).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.0794

['Andy Wokula' via vim_dev]

Am 28.07.2017 um 16:47 schrieb Bram Moolenaar:

Make count() accept a string.


Looks like count() eventually becomes useful.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

['Andy Wokula' via vim_dev]

Am 08.05.2017 um 22:28 schrieb Gary Johnson:

On 2017-05-08, 'Andy Wokula' via vim_dev wrote:

Am 08.05.2017 um 12:53 schrieb Bram Moolenaar:

For flexibility this needs to work recursively.  We could do something
like:

let saved_options = options_save()
... do your stuff ...
call options_restore(saved_options)

The options being saved should be small to keep this efficient.  We need
to make a list of the ones that are useful, such as 'ignorecase' and
'gdefault'.


What about a different approach:

Have a mode (for debugging only) in which builtin commands and
functions complain when options they use are not at the default
value.  This way the script writer learns which options need to be
set and restored.


Problems usually occur not with the options the script writer has
set to non-default values, but with options the script user has set
to non-default values.  This mode is not going to tell the writer
which options users may have set.


I hit the Send button, then it hit me ... right.


The safest approach, and the one most considerate of the user, is
for the plugin to save and restore the current value of any option
it depends on and sets.


But the question remains how to most easily and certainly find out
*which* options to set.  It should be more transparent which commands
(and functions) are affected by which options.

When everybody knows that for sure (maybe via dedicated help page?)
:commandaffected by  'option', ...
...
function()  affected by  'option', ...
...
h   affected by 'whichwrap', ...

then there could be a helper which traces executed (builtin) commands
and functions along a given way of execution, eg within the scope of a
modifier command, and fills a v:variable ... something like that.
Sounds like a lot of work ... each builtin command and function would
need to support it.
And :normal commands (e.g. `h' affected by 'whichwrap') are probably not
included.  Maybe `:normal h' is included, but not `feedkeys("h")' (out of
modifier command scope).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

['Andy Wokula' via vim_dev]

Am 08.05.2017 um 13:04 schrieb Christian Brabandt:


On Mo, 08 Mai 2017, Bram Moolenaar wrote:




Besides that, plugin writers also have a problem with very common
options, such as 'wrapscan' and 'ignorecase'.  We are nog going to
remove these.  Having an easy way to set these to their default, and
restore them later (without side effects), would be very useful.

For flexibility this needs to work recursively.  We could do something
like:

let saved_options = options_save()
... do your stuff ...
call options_restore(saved_options)

The options being saved should be small to keep this efficient.  We need
to make a list of the ones that are useful, such as 'ignorecase' and
'gdefault'.


Would those then also be set to a default by options_save? Or does every
plugin write have to set them as well?

Also worth containing: 'magic', 'cpo' and 'cp' options.


Setting 'cp' is too invasive.
Anyway, most plugins finish early if 'cp' is set.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

['Andy Wokula' via vim_dev]

Am 08.05.2017 um 12:53 schrieb Bram Moolenaar:

For flexibility this needs to work recursively.  We could do something
like:

let saved_options = options_save()
... do your stuff ...
call options_restore(saved_options)

The options being saved should be small to keep this efficient.  We need
to make a list of the ones that are useful, such as 'ignorecase' and
'gdefault'.


What about a different approach:

Have a mode (for debugging only) in which builtin commands and functions 
complain when options they use are not at the default value.
This way the script writer learns which options need to be set and restored.

(maybe: When used at toplevel (at the cmdline) there is no warning)

The advantage is that exactly the required options are set and restored.


And I'm not sure if the "last set from" info would work after options_save().

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [proposal][patch] Want to stop supporting troublesome options 'gdefault' and 'edcompatible'.

['Andy Wokula' via vim_dev]

Am 03.05.2017 um 11:11 schrieb Christian Brabandt:

Hi h_east!

On Mi, 03 Mai 2017, h_east wrote:


'gdefault' invertes the 'g' flag of `:substitute`.
In addition to 'edcompatible', it also inverts the 'c' flag.

When using `:substitute` with plugin, save and restore of the above options are 
necessary, it is a little weird.

I propose to stop supporting these options.
Please check the attached patch.


I made a little github code search for some vim settings. The results
are a bit surprising:

Search Term Results
---
set edcompatible6
set gdefault8,289
set langnoremap 718
set nolangremap 207
set termguicolors   3,425
set t_Co98,886
set laststatus  75,336
set nocompatible94,745
set incsearch   79,623

So gdefault seems to be popular to a certain degree. I wouldn't have
thought that, it is just such an obscure option.

By contrast the usage of edcompatible can be neglected, that option
seems to be in almost no use. Somewhat surprisingly, 'langnoremap' is
still somewhat widespread, also it is replaced by 'langremap' option.


I suppose one reason for the many gdefault hits is that quite a lot of script
writers are aware of the trouble with this option and take care of
saving and restoring it.  This is in turn is the case because gdefault is
somewhat popular (though not as popular as the number suggests ...).

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Substitutions in closed folds

['Andy Wokula' via vim_dev]

Am 13.12.2017 um 22:43 schrieb Gary Johnson:

To follow up, here is what I did to fix the problematic function in
my plugin.  I added code above and below this line, which had been
modifying every line in a closed fold instead of just l:lnum,

silent exe l:lnum.'s/:.*/:\t'.strftime("%Y-%m-%d %H:%M:%S").'/'

to open any closed fold at that line and, if necessary, re-close it.

let l:foldclosed = foldclosed(l:lnum) > 0 if l:foldclosed exe
l:lnum."foldopen" endif

silent exe l:lnum.'s/:.*/:\t'.strftime("%Y-%m-%d %H:%M:%S").'/'

if l:foldclosed exe l:lnum."foldclose" endif


Just :foldopen is not enough, it just opens one level of folds, the
cursor line might still end up in a closed fold.
And often it's unclear how the range is related to existing folds.
Mostly it's better to temporarily reset 'foldenable'.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Substitutions in closed folds

['Andy Wokula' via vim_dev]

Am 13.12.2017 um 18:57 schrieb Gary Johnson:

I've had a bug in one of my plugins that I finally traced to what
appears to be a bug in Vim (8.0.1257):  a substitution on one line
of a closed fold affects all lines in that fold.

Here's an example.  Create a file, fold_test, as shown.

 fold_test 
{{{1
line 2
line 3
line 4
line 5
}}}1
line 7
line 8
line 9
line 10
  vim: fdm=marker
---

Then edit that file as follows.

 $ vim -N -u NONE -i NONE fold_test

Note that lines 1 through 6 are folded.  Do the following.

 :3s/line/dog/
 zR

Note that "line" has been changed to "dog" in lines 2 through 5.
Then do the following.

 :3s/dog/cat/

Note that "dog" has been changed to "cat" in only line 3, as
expected.  The result looks like this.

 {{{1
 dog 2
 cat 3
 dog 4
 dog 5
 }}}1
 line 7
 line 8
 line 9
 line 10
  vim: fdm=marker

That an explicit substitution on one line affects all lines in the
closed fold looks like a bug to me.  It is certainly unexpected.

Regards,
Gary


Works as documented:
:h fold-behavior

For Ex commands that work on buffer lines the range is adjusted to always
start at the first line of a closed fold and end at the last line of a closed
fold.  Thus this command: >
:s/foo/bar/g
when used with the cursor on a closed fold, will replace "foo" with "bar" in
all lines of the fold.

Also try simpler commands like
:#
:.#
on a closed fold.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.1281

['Andy Wokula' via vim_dev]

Am 09.11.2017 um 20:46 schrieb Bram Moolenaar:

Patch 8.0.1281
Problem:Loading file type detection slows down startup.
Solution:   Move functions to an autoload script.
Files:  runtime/filetype.vim, runtime/autoload/filetype.vim,
 runtime/scripts.vim


Can we have a dedicated folder for autoload scripts shipped with Vim?
 for the sake of avoiding name clashes.
Eg autoload/vi/ is short and seems to be unused (more likely to be unused than 
autoload/vim/).

I think a missing dedicated folder is biggest impediment
for shipping more functionality in autoload scripts.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] `:unlet $FOOBAR` (#1116)

['Andy Wokula' via vim_dev]

Am 26.09.2016 um 00:10 schrieb Luc Hermitte (Vim Github Repository):

When an environment variable isn't set, `exists()` return false. We can assign 
a value to the variable with `:let`, after which point it exists. But we can't 
revert to an non-existent state (related to `unsetenv (3C)`)

```vim
call assert_false(exists('$FOOBAR'))
let $FOOBAR = 1
call assert_true(exists('$FOOBAR'))
unlet $FOOBAR
call assert_false(exists('$FOOBAR'))
```


At least on Windows, assigning the empty string "unlets" it.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.1837

['Andy Wokula' via vim_dev]

Am 13.05.2018 um 18:36 schrieb Bram Moolenaar:

Patch 8.0.1837
Problem:One character cmdline abbreviation not triggered after '<,'>.
Solution:   Skip over the special range. (Christian Brabandt, closes #2320)
Files:  src/ex_getln.c, src/testdir/test_mapping.vim


Do you have a good feeling when adding such inconsistencies?
I'd rather keep such a "bug".

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] general check for range in command-line (#2912)

['Andy Wokula' via vim_dev]

Am 14.05.2018 um 17:00 schrieb Enno (Vim Github Repository):

Perhaps permitting all marks, |.|, |$| and |%| is a speedy compromise. (Maybe 
line numbers as well?!).


Is it so hard to stick with abbrevs of two or more characters
or to type a space?  I think no.

For me it's much more annoying to always type  when I don't want the 
automatically inserted
'<,'>  marks.  But they have their use, so it should be ok.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] general check for range in command-line (#2912)

['Andy Wokula' via vim_dev]

Am 14.05.2018 um 17:00 schrieb Enno (Vim Github Repository):

Perhaps permitting all marks, |.|, |$| and |%| is a speedy compromise. (Maybe 
line numbers as well?!).


I vote for undoing that shitty patch.
You start with one inconsistency, and then there is no end.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Reproducible crash with matchadd, conceal cursor and submatches (#2910)

['Andy Wokula' via vim_dev]

Am 13.05.2018 um 20:53 schrieb Max Christian Pohle (Vim Github Repository):

In my .vimrc I do not want to have UTF-8 chars if possible, but
working with numeric representations of those isn't that comfortable
either. For that reason I tried to use Vims conceal feature to replace
nr2char(0xE0B4) and alike with a single character.

In an attempt I used a regex submatch:

|:call matchadd('Conceal', 'nr2char(\(0x[0-9A-Fa-f]*\))', 0, -1, {'conceal': 
nr2char("\1")})|


This cannot work, because `nr2char("\1")` (with backref) is evaluated
*now*, not when doing the match.

Help says the 'conceal' value should be a character.  It doesn't say you
can have an expression in there.

If it was possible, it would look like (akin :h sub-replace-\= )
{'conceal': '\=nr2char(submatch(1))'}

Pattern Hint: the shortcut for `[0-9A-Fa-f]' is `\x'.


This caused a SEGFAULT (and sometimes 'strange' results). I imagine
that 'matchadd' must share some code with substitute(), but that
should either not lead to crash and work as expected or the expression
for conceal cursors should be automatically escaped or something like
that.

Sorry for not creating a bugfix, but the conceal feature is relatively
new to me.



--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] general check for range in command-line (#2912)

['Andy Wokula' via vim_dev]

Am 14.05.2018 um 19:17 schrieb Christian Brabandt:

On Mo, 14 Mai 2018, 'Andy Wokula' via vim_dev wrote:


Am 14.05.2018 um 17:00 schrieb Enno (Vim Github Repository):

Perhaps permitting all marks, |.|, |$| and |%| is a speedy compromise. (Maybe 
line numbers as well?!).


I vote for undoing that shitty patch.


Ouch that hurts.


Sorry, I didn't want to hurt anyone, only the patch.


BTW: the corresponding github issue 2320 was there
laying around for 6 months and nobody bothered to comment.


For a good reason maybe.


You start with one inconsistency, and then there is no end.


Don't you feel the same here?


IBTD: It removes an inconsistency.


The abbreviation rules apply.
If you ignore these rules, it looks "inconsistent", but otherwise?

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.0.1206

['Andy Wokula' via vim_dev]

Am 19.10.2017 um 18:36 schrieb Bram Moolenaar:

Patch 8.0.1206
Problem:No autocmd for entering or leaving the command line.
Solution:   Add CmdlineEnter and CmdlineLeave.
Files:  runtime/doc/autocmd.txt, src/ex_getln.c, src/fileio.c, src/vim.h,
 src/testdir/test_autocmd.vim


+1 \{100,}

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Exception in context of :silent! and try-conditional suppresses all errors in future commands (#2531)

['Andy Wokula' via vim_dev]

Am 06.01.2018 um 00:00 schrieb ben-reilly (Vim Github Repository):

I imagine this may be related to #538 .


... and
https://groups.google.com/d/msg/vim_dev/GI0CYo-b4qg/9ABGgopVBgAJ

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Comments halfway continuation lines

['Andy Wokula' via vim_dev]

Am 19.08.2018 um 18:37 schrieb Bram Moolenaar:

Currently, when making a list with continuation lines, it is not
possible to add a comment somewhere:

let array = [
\ item,
\ item,
\ item,
\]


Maybe you can't put a comment, but you can put something that is (evaluated 
but) ignored
and serves as a comment:

let array = [
\ ['item', "my fancy comment for this item"][0],
\ ['item2', "I like this item much more than the first item"][0],
\ ['item3', "Is this a stupid way to comment items??"][0],
\ ['item4', "I don't think so"][0],
\ ['item5', "true: there is some unnecessary computation going on"][0],
\ ['item6', "but it's negligible, right?"][0],
\ ['item7', "right"][0],
\ ]

echo array
=> ['item', 'item2', 'item3', 'item4', 'item5', 'item6', 'item7']

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Wish:

['Andy Wokula' via vim_dev]

Am 23.03.2018 um 19:16 schrieb Ingo Karkat:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 23-Mar-2018 17:28 +0100, 'Andy Wokula' via vim_dev wrote:

Am 13.04.2011 um 17:07 schrieb Andy Wokula:

Am 09.04.2011 20:27, schrieb Ingo Karkat:

On 09-Apr-2011 14:54, Andy Wokula wrote:

For example, I have a command :InFunc .  It's quite a trivial
command, it takes an argument Ex-command and executes it within a
function.  Purpose is to automatically restore the highlighting state
and the last search pattern.
  :h function-search-undo

Thus, mostly the Ex-command will be :global or :substitute .

Problem: :global has the default range "1,$" whereas :substitute has
the default range ".".  For :InFunc, I'm urged to specify a default
range (e.g. either -range (current line) or -range=% (whole buffer)).
I don't want that, instead I want the default range of the argument
command to be in effect.  But at the moment, it's not possible to
check for an empty range.


" What I use now:
  :[range]InFunc {cmd}" execute :[range]{cmd}, for :subst
  :[range]InFunc! {cmd}   " execute :{cmd}, for :global

com! -bang -range -nargs=+  InFunc,call
InFunc(0,)

func! InFunc(bang, cmd) range
  if a:bang
  exec a:cmd
  else
  exec a:firstline.",".a:lastline. a:cmd
  endif
endfunc


" I'd like to write the above this way:

com! -range=NoDefault -nargs=+  InFunccall InFunc()

func! InFunc(cmd) range
  exec a:range. a:cmd
endfunc


Oops, we would also need a new variable  a:range !

Maybe, actually,  and a:range are not needed, I just want to
be able to check for an empty range:


com! -range -nargs=+  InFunc,call InFunc()

func! InFunc(cmd) range
  if range_is_empty()
  exec a:cmd
  else
  exec a:firstline.",".a:lastline. a:cmd
  endif
endfunc


This would just a require a new function range_is_empty().


Unless there are additional use cases where this could be useful, my
first hunch is that it's not worth the effort.


It's more about consistency:

When you define a mapping, you can check if a count was given or not
(check v:count >= 1).

When you define a command with -range, you cannot check if a range was
given or not.


TIL it is indeed possible to check if a range was given or not:

:com! -range Crwg :echo (==-1 ? 'No range was given' : 'The given
range is ,')

Works with Vim 7.0 onwards.


How did you dig up that old thread?! (But thanks for following up!)


Oops that old?  Feels like yesterday.


I've found out about that, too:

To distinguish between no given range (then defaulting to something like the
last modified range) and a range, use -range=-1 and check :
 :command! -range=-1 Test echomsg  == -1 ? "'[,']" :  . ',' . 

This emulates -range=% but allows :0Test (passed via first argument boolean
flag), too:
 :command! -range=-1 Test call Test(( == 0), ( == -1 &&  == 1 ? 
'1,' . line('$') : ','))


Amazing.

Right, it bothered me at the same time why a range "0" is always
turned into "1".

Best thing: I tried with gVim 5.7, it works there too.
A really old feature this is!


- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJatURcAAoJEA7ziXlAzQ/vsH4H/3mMbpNKoZJbgYEUmlIJAvv+
7zUphcl6TnyslZwrtz3BSDP4vcQpkFBvsMxwkjRd5z/i3+CtHC8w2v4AfgQr/SdH
fSdMipYM7JeqddWnaD37GlWyIm+gFoaPpuOuPdybnkXGYLs9A6YFZXX1+59OYXR8
QEuahc8/3M4ye9I6PVzqW/IHtMDYRSMPrxRQegZkn29F/mLjftmRh7u2W8c85zJ0
0QlaYpGvO3JqOxzMZSNOtvDWRGelscZPclE4wBuwdjtrCogtZy790ET6JJyUjFYw
Lj7/U2ydwa6UEr6RQRBSG0xmUbBiqLoQZYTLk6d9q/Ipvt9kplj3FqZlVJ9zoXc=
=e/Dn
-END PGP SIGNATURE-


--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Wish:

['Andy Wokula' via vim_dev]

Am 13.04.2011 um 17:07 schrieb Andy Wokula:

Am 09.04.2011 20:27, schrieb Ingo Karkat:

On 09-Apr-2011 14:54, Andy Wokula wrote:

For example, I have a command :InFunc .  It's quite a trivial
command, it takes an argument Ex-command and executes it within a
function.  Purpose is to automatically restore the highlighting state
and the last search pattern.
 :h function-search-undo

Thus, mostly the Ex-command will be :global or :substitute .

Problem: :global has the default range "1,$" whereas :substitute has
the default range ".".  For :InFunc, I'm urged to specify a default
range (e.g. either -range (current line) or -range=% (whole buffer)).
I don't want that, instead I want the default range of the argument
command to be in effect.  But at the moment, it's not possible to
check for an empty range.


" What I use now:
 :[range]InFunc {cmd}" execute :[range]{cmd}, for :subst
 :[range]InFunc! {cmd}   " execute :{cmd}, for :global

com! -bang -range -nargs=+  InFunc,call InFunc(0,)

func! InFunc(bang, cmd) range
 if a:bang
 exec a:cmd
 else
 exec a:firstline.",".a:lastline. a:cmd
 endif
endfunc


" I'd like to write the above this way:

com! -range=NoDefault -nargs=+  InFunccall InFunc()

func! InFunc(cmd) range
 exec a:range. a:cmd
endfunc


Oops, we would also need a new variable  a:range !

Maybe, actually,  and a:range are not needed, I just want to
be able to check for an empty range:


com! -range -nargs=+  InFunc,call InFunc()

func! InFunc(cmd) range
 if range_is_empty()
 exec a:cmd
 else
 exec a:firstline.",".a:lastline. a:cmd
 endif
endfunc


This would just a require a new function range_is_empty().


Unless there are additional use cases where this could be useful, my
first hunch is that it's not worth the effort.


It's more about consistency:

When you define a mapping, you can check if a count was given or not
(check v:count >= 1).

When you define a command with -range, you cannot check if a range was
given or not.


TIL it is indeed possible to check if a range was given or not:

:com! -range Crwg :echo (==-1 ? 'No range was given' : 'The given range is 
,')

Works with Vim 7.0 onwards.


Here is another example:

DrChip's AsNeeded script comes with an ANX command:
 :ANX {cmd}

ANX loads the script that defines the Ex-command {cmd} and immediately
executes {cmd}.  It would be nice if :ANX could execute {cmd} with a
range.  But this cannot be done at the moment, because it's unclear if
{cmd} accepts a range and what the default range of {cmd} will be.

Again, it would be nice if we could use  in place of ,:

 :com! -range -nargs=1 ANX  call LoadCmd()| 



My first idea to implement your use case (with current Vim
functionality) was a cabbr, and then get the range via
getcmdline(), extract and store it somewhere, and then replace the
InFunc cabbr with InFuncImpl, which would then simply prepend the
stored range to the passed command. The problem with this is that for
the cabbr to be expanded, there would need to be a whitespace before
it, so :2,4 InFunc instead of :2,4InFunc would need to be used. But
the cabbr could be replaced with a cmap, that wouldn't have that
problem.


For mappings I have a solution:

 " remove trailing whitespace (except for the "-- " line in mails):
 :no ss  :v/^-- $/s/\s\+$//eInFunc! 


Reflecting on it some more, I think that the :InFunc is cumbersome (to
type), anyway. I would solve this via a :cmap  which restores
the previous pattern from the search history. So instead of prepending
InFunc to the Ex command, I would just conclude the Ex command
with  instead of.


It's just that I want :InFunc to do this work.  For example, another
thing we can't check for is the highlighting state of the last search
pattern, InFunc restores it automatically.




--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Don't use function!

['Andy Wokula' via vim_dev]

Am 08.12.2018 um 16:03 schrieb Bram Moolenaar:

Yasuhiro Matsumoto wrote:


On Saturday, December 8, 2018 at 10:53:07 PM UTC+9, Bram Moolenaar
wrote:

I have recently changed the behavior of :function to allow for
redefining (overwriting) a function when that should normally be
fine. Therefore, using function! is hardly ever needed.

Previously, when sourcing a script a second time, one had to use
function! to redefine the functions.  This was very common, since
when developing a plugin once has to try several times before
getting it right.  A big problem with this is that when another
script uses the same function, or you had copy-pasted the
function and forgot to change the name, the function would be
errornously overwritten.

Vim now checks the script ID of where the function was defined,
and whether that same script is being sourced again.  This allows
for silently overwriting the function from the same script file,
once.

So, please stop using function!


Now wondering if the same should be done for user commands...


This seems to be good improvement but some plugin manager reload
plugins when update install plugins. ex: vim-plug So older version
of vim will occur errors if some plugins remove ! from their
codes.


Yeah, it may take a couple of years until this change gets to most
places.  I have been wondering about auto-updating Vim (like Chrome
does), but don't think that is feasible.

Anyway, I think I'll go ahead and also do this for :command.


So the next step is to add another 'cpoptions' flag which disables
the effect of `!' in `:function!' when used inside a script.

Ie you can continue writing `:function!' in a script, but the bang
will have no effect if the flag is set.

And the flag will be set by default in newer Vims.

Just a thought.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Patch 8.1.1083

['Andy Wokula' via vim_dev]

Am 30.03.2019 um 17:28 schrieb Bram Moolenaar:

Patch 8.1.1083
Problem:MS-Windows: hang when opening a file on network share.
Solution:   Avoid using FindFirstFile(), use GetLongPathNameW(). (Ken Takata,
 closes #3923)
Files:  src/os_win32.c


Thanks for this one, very much appreciated.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5CDAE81F.30807%40yahoo.de.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal for User methods

['Andy Wokula' via vim_dev]

Am 11.08.2019 um 18:27 schrieb Bram Moolenaar:

I'm not sure about methods for a specific type, e.g. only defined for a
list or dict.  I suppose in many cases you have very similar
functionality in both, and might as well define both.

It would be possible to make the type available to the autocommand.  But
it feels like this is getting more complicated than needed.  That is
also the main reason I asked: Do we want/need to select the function
based on the type?


If you ask me: no.
I want to be able to build these things using Vim script
because then it's backwards compatible.

I wish there was a *small* Vim script core (already too late).

I'm with JM Keyes there: we don't need more syntactic
(or syntoxic!!) sugar.


My Vim script experiments (just for the record):

CallOverloaded()
https://gist.github.com/Houl/d28f6b05f14956296fd9328e149d8751

Usage example: HasPatchExpr()
https://gist.github.com/Houl/151594d0089fee91e33ba6d676f5092c

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D50477C.9090607%40yahoo.de.

Re: Proposal for User methods

['Andy Wokula' via vim_dev]

Am 11.08.2019 um 00:11 schrieb Bram Moolenaar:

So if you intentionally want to define a function to both be used
without a context and as a method, but still want to specify the type,
we should allow for:
function Total(arg: list)
function Total(arg: dict)

This basically means we have function overloading based on argument
types.

Opinions?


I'd prefer when a Vim expression in "chained notation" has an equivalent
representation as "ordinary" Vim expression.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D506E98.5020208%40yahoo.de.

Re: Patch 8.1.1952

['Andy Wokula' via vim_dev]

Am 31.08.2019 um 19:14 schrieb Bram Moolenaar:

! <  *globpath()*
   globpath({path}, {expr} [, {nosuf} [, {list} [, {alllinks}]]])
Perform glob() on all directories in {path} and concatenate
the results.  Example: >
***
*** 5696,5701 
--- 5722,5731 
   < Upwards search and limiting the depth of "**" is not
supported, thus using 'path' will not always work properly.

+   Can also be used as a|method|, the base is passed as the
+   second argument: >
+   GetExpr()->globpath()


You think, to be consistent with glob(), the base must be passed as the *second*
argument?  I wonder what your reason is here, it's quite unexpected.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D6AB369.5020204%40yahoo.de.

Re: Patch 8.1.1952

['Andy Wokula' via vim_dev]

Am 31.08.2019 um 21:07 schrieb Bram Moolenaar:


Andy Wokula wrote:


Am 31.08.2019 um 19:14 schrieb Bram Moolenaar:

! <  *globpath()*
globpath({path}, {expr} [, {nosuf} [, {list} [, {alllinks}]]])
Perform glob() on all directories in {path} and concatenate
the results.  Example: >
***
*** 5696,5701 
--- 5722,5731 

+   GetExpr()->globpath()


You think, to be consistent with glob(), the base must be passed as
the *second* argument?  I wonder what your reason is here, it's quite
unexpected.


In a chain what gets passed is the object that is being processed.
In this case I would say the expression is processed, while the path is
a parameter indicating how to process the expression.

eval GetPattern()->glob()->ListResults()
eval GetPattern()->globpath()->ListResults()

Did you expect that with -> the base is always passed as the first
argument?  That doesn't work well for some existing functions.


It works well with globpath(), that's why it's unexpected.
Is there some other rule which prevents users from looking up :help for every 
function?
Or are there just a few exceptions?

Rules for example
- base is passed as first argument
- doesn't work well for: printf(), setline(), strftime(), append(), ... other 
easy to guess functions
- "exceptions", base anyway passed as second argument: globpath(), ...

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D6B7E28.6010907%40yahoo.de.

Re: Patch 8.1.2035

['Andy Wokula' via vim_dev]

Am 15.09.2019 um 21:13 schrieb Bram Moolenaar:

Andy Wokula wrote:


Am 15.09.2019 um 14:33 schrieb Bram Moolenaar:

Patch 8.1.2035
Problem:Recognizing octal numbers is confusing.
Solution:   Introduce scriptversion 4: do not use octal and allow for single
  quote inside numbers.
Files:  runtime/doc/eval.txt, src/vim.h, src/eval.c, src/scriptfile.c,
  src/evalfunc.c, src/testdir/test_eval_stuff.vim,
  src/testdir/test_functions.vim


Single quotes could be a pitfall for scripts that attempt to skip string
literals in Vim script code.


It's not difficult to handle this syntax.


Is 0x80 the intended value or 0x08 ?


Doesn't matter, just wanted to make sure it's further away from the
BIN/OCT/HEX values.


What happens with
  :echo 1''234

Should add a test for that.


Ok ok ok ^^.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D7FA4EF.10701%40yahoo.de.

Re: Patch 8.1.2044

['Andy Wokula' via vim_dev]

Am 15.09.2019 um 23:02 schrieb Bram Moolenaar:

Patch 8.1.2044
Problem:No easy way to process postponed work. (Paul Jolly)
Solution:   Add the SafeState autocommand event.
Files:  runtime/doc/autocmd.txt, src/main.c, src/proto/main.pro,
 src/vim.h, src/autocmd.c, src/channel.c, src/edit.c,
 src/ex_getln.c


*** ../vim-8.1.2043/runtime/doc/autocmd.txt 2019-09-09 18:35:28.119252725 
+0200
--- runtime/doc/autocmd.txt 2019-09-15 21:50:17.266633152 +0200
***
*** 355,360 
--- 355,363 
when popup menu visible
   |TextYankPost|   after text has been yanked or deleted

+ |SafeState|   nothing pending, going to wait for the user to type a
+   character
+
   |ColorSchemePre| before loading a color scheme
   |ColorScheme|after loading a color scheme

***
*** 956,961 
--- 958,984 
Note that even if an autocommand is defined,
the reply should be read with |remote_read()|
to consume it.
+   *SafeState*
+ SafeState When nothing is pending, going to wait for the
+   user to type a character.
+   This will not be triggered when:
+   - an operator is pending
+   - a register was entered with "r
+   - halfway executing a command
+   - executing a mapping
+   - there is typeahead
+   - Insert mode completion is active
+   - Command line completion is active
+   You can use `mode()` to find out what state
+   Vim is in.  That may be:
+   - VIsual mode
+   - Normal mode
+   - Insert mode
+   - Command-line mode
+   Depending on what you want to do, you may also
+   check more with `state()`, e.g. whether the
+   screen was scrolled for messages.
+


What about CursorHold?  Is this before or after (in case CursorHold is about to 
be triggered at all)?
From your description I guess it's before CursorHold.

(not sure if a CursorHold event is considered "pending")

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D7FA3DE.2030700%40yahoo.de.

Re: RFC: Function to get the list of marks (getmarks)

['Andy Wokula' via vim_dev]

Am 18.09.2019 um 17:18 schrieb Yegappan Lakshmanan:

Hi all,

Currently the following Vim built-in functions are available to get
information about individual marks: getpos(), line() and col().

But we don't have a function to get the list of marks placed in a
buffer or the list of global marks (similar to the list displayed by
the :marks command).

What do you think about adding a getmarks() function that returns
the list of global marks or the list of marks placed in a buffer?


What do you mean by "a buffer" -- "the current buffer" or "any given buffer"?

Getting global marks or marks of the current buffer is trivial

:echo filter(split('ABCDEFGHIJKLMNOPQRSTUVWXYZ', '\m'), 'line("''". v:val) >= 
1')
:echo filter(split('abcdefghijklmnopqrstuvwxyz', '\m'), 'line("''". v:val) >= 
1')
" (some other special marks omitted)

but I wouldn't know how to get marks from any given buffer without
making that buffer current.  Anyway I'm not sure if I ever asked for
the local marks of a non-current buffer.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D825175.9000602%40yahoo.de.

Re: Patch 8.1.2052

['Andy Wokula' via vim_dev]

Am 17.09.2019 um 22:45 schrieb Bram Moolenaar:

Patch 8.1.2052
Problem:Using "x" before a closed fold may delete that fold.
Solution:   Do not translate 'x' do "dl". (Christian Brabandt, closes #4927)
Files:  src/normal.c, src/testdir/test_fold.vim


So it's ok when `dl' deletes that fold?

And `x' is documented to behave like `dl'.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D824D21.9000509%40yahoo.de.

Re: Patch 8.1.2052

['Andy Wokula' via vim_dev]

Am 18.09.2019 um 17:42 schrieb Christian Brabandt:


On Mi, 18 Sep 2019, 'Andy Wokula' via vim_dev wrote:


Am 17.09.2019 um 22:45 schrieb Bram Moolenaar:

Patch 8.1.2052
Problem:Using "x" before a closed fold may delete that fold.
Solution:   Do not translate 'x' do "dl". (Christian Brabandt, closes #4927)
Files:  src/normal.c, src/testdir/test_fold.vim


So it's ok when `dl' deletes that fold?

And `x' is documented to behave like `dl'.


No the patch fixes it and deletes only the line on which the cursor is.

But I think it creates another problem.

Take a file like this:

,[ file.txt ]
| abc
| def
| ghi
`

Now start Vim like this:

vim --clean -c ':set ww+=l virtualedit=onemore' -c 'norm! 1ggl'  file

The cursor is now after the content of line 1 ('_' being the cursor, ga
returns 'NUL' on that position):

,[ file.txt ]
| abc_
| def
| ghi
`

Now press 'x' and you are left with:

,[ file.txt ]
| def
| ghi
`

And I think it is wrong in that 'x' deleted the first line (e.g.
characters before the cursor position).

I think it should probably be:

,
| abcdef
| ghi
`

That is what this patch would do:

diff --git a/src/normal.c b/src/normal.c
index e83c4c0be..6afebd1ab 100644
--- a/src/normal.c
+++ b/src/normal.c
@@ -7404,7 +7404,7 @@ nv_optrans(cmdarg_T *cap)
 // whichwrap option, do not delete the next line.
 if (cap->cmdchar == 'x' && vim_strchr(p_ww, 'l') != NULL
   && gchar_cursor() == NUL)
-   stuffReadbuff((char_u *)"dd");
+   stuffReadbuff((char_u *)"gJ");
 else
 stuffReadbuff(ar[(int)(vim_strchr(str, cap->cmdchar) - str)]);
 }


So it's ok when `dl' deletes that fold?

And `x' is documented to behave like `dl'.  So it's ok to add a special case 
for `x'?

Why not fix `dl'?

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D8255F2.1060806%40yahoo.de.

Re: [vim/vim] :! {cmd} quoting issues on windows 10 when using bash as shell (#4950)

['Andy Wokula' via vim_dev]

Am 18.09.2019 um 00:09 schrieb CrispyDrone (Vim Github Repository):

*Describe the bug*
I've exhausted all options and followed the documentation but am unable to get 
|:! {cmd}| to work with the following shell configuration:

|set shell=\"$PROGRAMW6432\Git\bin\bash.exe\"
|

I've also the tried the following and more:

|set shell=$PROGRAMW6432\Git\bin\bash.exe
set shell=$PROGRAMW6432/Git/bin/bash.exe
set shell=\"\"$PROGRAMW6432/Git/bin/bash.exe\"\"
set shell=\'\"$PROGRAMW6432/Git/bin/bash.exe\"\'
set shell=\"\'$PROGRAMW6432/Git/bin/bash.exe\'\"
set shell=\'$PROGRAMW6432/Git/bin/bash.exe\'
set shell=\"C:\Program Files\Git\bin\bash.exe\"
set shell=\"C:\Program\ Files\Git\bin\bash.exe\"
set shell=\"C:\Program\\ Files\Git\bin\bash.exe\"
set shell=\"C:\Program\\\ Files\Git\bin\bash.exe\"
set shell=C:\Program\\\ Files\Git\bin\bash.exe
..
|

*To Reproduce*

 1. Run |vim -u .vimrc| where .vimrc contains the single |set shell| line of 
configuration.
 2. Execute for example |:!ls|
 3. Receive the error message as shown in the screenshot

*Expected behavior*
The |{cmd}| is executed in the configured shell.

*Screenshots*
'Program' is not recognized as an internal or external command: quoting issues... 


*Environment:*


Other things to try:
:let  = substitute(expand('$PROGRAMW6432\Git\bin\bash.exe'), ' ', '^ 
', 'g')
:let  = substitute('C:\Program Files\Git\bin\bash.exe', ' ', '^ ', 
'g')
:let  = 'C:\Program" "Files\Git\bin\bash.exe'

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D827D20.101%40yahoo.de.

Re: Patch 8.1.2035

['Andy Wokula' via vim_dev]

Am 15.09.2019 um 14:33 schrieb Bram Moolenaar:

Patch 8.1.2035
Problem:Recognizing octal numbers is confusing.
Solution:   Introduce scriptversion 4: do not use octal and allow for single
 quote inside numbers.
Files:  runtime/doc/eval.txt, src/vim.h, src/eval.c, src/scriptfile.c,
 src/evalfunc.c, src/testdir/test_eval_stuff.vim,
 src/testdir/test_functions.vim


Single quotes could be a pitfall for scripts that attempt to skip string
literals in Vim script code.


   // flags for vim_str2nr()
! #define STR2NR_BIN 0x01
! #define STR2NR_OCT 0x02
! #define STR2NR_HEX 0x04
   #define STR2NR_ALL (STR2NR_BIN + STR2NR_OCT + STR2NR_HEX)
! #define STR2NR_NO_OCT (STR2NR_BIN + STR2NR_HEX)
!
! #define STR2NR_FORCE 0x80   // only when ONE of the above is used


Is 0x80 the intended value or 0x08 ?


! #define STR2NR_QUOTE 0x10   // ignore embedded single quotes


What happens with
:echo 1''234
:echo 1'''234
?  Is it an error?

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D7E7BE6.2080801%40yahoo.de.

Re: [vim/vim] Support for "" in mappings (Neovim patch) (#4784)

['Andy Wokula' via vim_dev]

Am 07.08.2019 um 14:04 schrieb Daniel Hahler (Vim Github Repository):

Neovim has a nice feature where you can use || in a mapping to
stay in the current mode (a better alternative to |vnoremap x
:???|, where you then have to handle re-entering visual mode
etc).

(in the case at hand it allows for using |search| in a mapping for
both normal and visual mode, tpope/vim-unimpaired#187
)

The original patch was done in neovim/neovim#4419
 by @bfredl
.

Having it in Vim also would make life easier for plugin authors (in
general due to its usefulness, and with regard to Neovim
compatibility)


For older Vims, see
https://github.com/vim-scripts/motpat.vim/blob/master/autoload/gvmap.vim

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D4AECC5.20001%40yahoo.de.

Re: Patch 8.1.1510

['Andy Wokula' via vim_dev]

Am 09.06.2019 um 17:22 schrieb Bram Moolenaar:

Patch 8.1.1510
Problem:A plugin cannot easily expand a command like done internally.
Solution:   Add the expandcmd() function. (Yegappan Lakshmanan, closes #4514)
Files:  runtime/doc/eval.txt, runtime/doc/usr_41.txt, src/evalfunc.c,
 src/testdir/test_expand.vim


"cannot easily" is not true I think:


func! ExpandCmd(args)
exec 'NwoExpand '. a:args
endfunc

" Internal:
com! -nargs=? -complete=file NwoExpand return 


"cannot nicely" may hit it better because of the internal command.
This side effect of file completion was undocumented.
Works for Vim 7.0.

Not sure if it really does the same as expandcmd().

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D487B35.600%40yahoo.de.

map() and lambda

['Andy Wokula' via vim_dev]

:h expr-lambda

I think this is a design mistake:
:echo map([1, 2, 3], {idx, val -> val + 1})

It should be
:echo map([1, 2, 3], {val, idx -> val + 1})

95% of map() expressions do not need v:key (er, idx).

It annoys me whenever I use it.

Especially nice: dummy examples that are off-by-one without error:
:echo map([1,2,3], {x -> x+10})
=> [10, 11, 12]
Great stuff!

Please change this, backwards incompatibly.
Also for filter().

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D4C31B1.1030401%40yahoo.de.

Re: How about highlighting captured groups in regex?

['Andy Wokula' via vim_dev]

Am 07.10.2019 um 13:51 schrieb Dominique Pell??:

Hi

Vim now highlights matching text when
typing an Ex command like :%s/foobar/
I like it. But I wish that it would use
a different color for the regex captured group(s).

For example, if I do   :%s/foo\(bar\)/
I would like "bar" (the captured group) to
be highlighted with a different color than foo
in matching text, so it's easier to visually see
that my regexp matches and what \1 is
when I do  :%s/foo\(bar\)/\1/.  In this example
the regexp and captured group are obvious
of course, so a different color may not seem
useful. But it becomes more useful when the
the regex is more complex.

There are 10 possibly regexp groups.  Having 10
different colors might be overkill (not sure).
The same color for any group may good enough,
or perhaps alternative colors for \1 \2 \3...?

I wonder whether other vim users would also
find it useful.

Regards
Dominique


What about nesting / overlapping group matches (?):
/foo\(ba\(baz\)r\)

can be several levels deep.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D9E07AB.1040304%40yahoo.de.

Re: How about highlighting captured groups in regex?

['Andy Wokula' via vim_dev]

Am 09.10.2019 um 18:57 schrieb Dominique Pell??:

Andy Wokula wrote

 > Am 07.10.2019 um 13:51 schrieb Dominique Pell??:
 > > Hi
 > >
 > > Vim now highlights matching text when
 > > typing an Ex command like :%s/foobar/
 > > I like it. But I wish that it would use
 > > a different color for the regex captured group(s).
 > >
 > > For example, if I do   :%s/foo\(bar\)/
 > > I would like "bar" (the captured group) to
 > > be highlighted with a different color than foo
 > > in matching text, so it's easier to visually see
 > > that my regexp matches and what \1 is
 > > when I do  :%s/foo\(bar\)/\1/.  In this example
 > > the regexp and captured group are obvious
 > > of course, so a different color may not seem
 > > useful. But it becomes more useful when the
 > > the regex is more complex.
 > >
 > > There are 10 possibly regexp groups.  Having 10
 > > different colors might be overkill (not sure).
 > > The same color for any group may good enough,
 > > or perhaps alternative colors for \1 \2 \3...?
 > >
 > > I wonder whether other vim users would also
 > > find it useful.
 > >
 > > Regards
 > > Dominique
 >
 > What about nesting / overlapping group matches (?):
 >  /foo\(ba\(baz\)r\)
 >
 > can be several levels deep.

The outer group in your example is \1 and the
inner group is \(baz\) is \1.  Highlighting of inner group
should shadow highlighting of outer groups I would
say in the common portion of the matched text.

So matching text when searching for /foo\(ba\(baz\)r\)
could look like this for example if:
* Search group is yellow
* \1 is light brown
* \2 is darker brown
xxfoobabazr__xx
But multiple colors for \1, \2 (etc) is maybe overkill.
Personally I'd be happy enough with a single color for all
captured groups, i.e.:
xxfoobabazr__xx
Regards
Dominique


What about rainbow-highlighting of parens `\(', `\)'?
Ie instead of highlighting the text, just highlight
the grouping parens.

And then, `\1', `\2' ... using the same colors.

I'd prefer that, also because weird colors will not hide
my regexp text then.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5D9E2102.7000301%40yahoo.de.

Re: [vim/vim] In bash syntax you can't escape a backquote in a double-quoted string. (#5991)

['Andy Wokula' via vim_dev]

Am 26.04.2020 um 18:03 schrieb Charles Campbell:

John Little wrote:

This is a regression, the syntax/sh.vim from 2019-06-16 does not show
this problem.

The maintainer of this syntax script has his own version numbering,
and if you want to report problems he usually will first ask that you
try the latest script from his web site, which is version 190. It has
the problem.  The version on github is 189, dated 2019-10-16.
Version 188, which I have from the Ubuntu 20.04 repository, does not
show the problem. (Neither do versions 125, 133, or 179, which I had
lying around.)


I see the problem.  As you can easily check, putting a space right
before the backslash fixes the highlighting.  From syntax
highlighting's perspective:

* something preceded by an even number of backslashes should not be
  escaped (and thus be normally highlighted)
* something preceded by an odd number of backslashes should be escaped
  (and thus highlighted with special highlighting)

However, in this case the backslash is preceded by the double-quote
which starts a string region.  The attempt to check for an odd/even
number of backslashes fails,


maybe you just assumed this check is needed while it actually isn't?

You probably mean the following rule:

:syn match   shSpecialDQ "[^\\]\zs\%(\)*\\[\\"'`$()#]"


and thus the backquote is recognized incorrectly as beginning an
in-string command rather than being escaped.  Not checking for that
even/odd number of backslashes is obviously going to cause bad
highlighting.


At least for me it isn't obvious.


I need some way to check that a pattern is beginning with a backslash
in a region, and thus can do without the odd-even preceding context
checking.  I've asked Bram for something like a "startgroup=..."
expression (similar to nextgroup=...) wherein I could do just that.


Try this rule instead:

:syn match   shSpecialDQ "\\[\\"'`$()#]"


We'll see what happens...
Chip Campbell


Checking history ...

date:Thu May 10 17:35:54 2007 +
summary: updated for version 7.1b
-" Last Change:Sep 15, 2006
-" Version:88
+" Last Change:Dec 12, 2006
+" Version:89
-syn match   shSpecial  "\\[\\\"\'`$()#]"
+syn match   shStringSpecial"\%(\)*\\[\\"'`$()#]"
+syn match   shSpecial  "[^\\]\zs\%(\)*\\[\\"'`$()#]"
+syn match   shSpecial  "^\%(\)*\\[\\"'`$()#]"

Ok, old code already included what I'm about to suggest.
So there must have been a problem ... but I can't find
a problem report.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5EAB12F3.4030200%40yahoo.de.

Re: Patch 8.2.0762

['Andy Wokula' via vim_dev]

Am 15.05.2020 um 22:31 schrieb Bram Moolenaar:

Patch 8.2.0762
Problem:Buffer is not considered modified after setting crypt key.
Solution:   Set the modified flag. (Christian Brabandt, closes #6082)
Files:  src/optionstr.c, src/testdir/test_crypt.vim


*** ../vim-8.2.0761/src/optionstr.c 2020-04-17 19:41:16.100078313 +0200
--- src/optionstr.c 2020-05-15 22:28:34.399878939 +0200
***
*** 1157,1164 
--- 1157,1167 

if (STRCMP(curbuf->b_p_key, oldval) != 0)
// Need to update the swapfile.
+   {
ml_set_crypt_key(curbuf, oldval,
  *curbuf->b_p_cm == NUL ? p_cm : curbuf->b_p_cm);
+   changed_internal();
+   }
   }


Does it really do a before-after comparison of the key?
If so ... maybe ... will this make it easier to guess a key?
Ie, just guess a key and then check 'modified'?

I would have expected that any :X command sets the modified flag.

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5EC27203.6060301%40yahoo.de.

Re: Patch 8.2.0762

['Andy Wokula' via vim_dev]

Am 18.05.2020 um 15:18 schrieb Bram Moolenaar:

Am 15.05.2020 um 22:31 schrieb Bram Moolenaar:

Patch 8.2.0762
Problem:Buffer is not considered modified after setting crypt key.
Solution:   Set the modified flag. (Christian Brabandt, closes #6082)
Files:  src/optionstr.c, src/testdir/test_crypt.vim


*** ../vim-8.2.0761/src/optionstr.c 2020-04-17 19:41:16.100078313 +0200
--- src/optionstr.c 2020-05-15 22:28:34.399878939 +0200
***
*** 1157,1164 
--- 1157,1167 

if (STRCMP(curbuf->b_p_key, oldval) != 0)
// Need to update the swapfile.
+   {
ml_set_crypt_key(curbuf, oldval,
  *curbuf->b_p_cm == NUL ? p_cm : curbuf->b_p_cm);
+   changed_internal();
+   }
}


Does it really do a before-after comparison of the key?
If so ... maybe ... will this make it easier to guess a key?
Ie, just guess a key and then check 'modified'?


That only means the key is the same as before, not whether it's right or
wrong.  If someone would walk away from the keyboard then you can read
the text already, no need to guess the key, just do
":w !cat >/usr/me/public/secret.txt".
Or look at the sticky notes on the display for the password.
Yeah, encryption safety is not always related to the algorithm :-).


It just didn't seem right, but looks like the only thing to worry
about here are the sticky notes ^^

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5EC2C316.6060906%40yahoo.de.

Re: Vim9: rethinking conditions and boolean expressions

['Andy Wokula' via vim_dev]

Am 03.10.2020 um 17:44 schrieb Bram Moolenaar:

Therefore, I'm going to make && and || have a boolean result again.
I think that is the easiest to understand, and what most languages do.


+100

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5F78D00C.3010704%40yahoo.de.

Re: Clearing the contents of a dictionary

['Andy Wokula' via vim_dev]

Am 25.05.2020 um 22:35 schrieb Bram Moolenaar:

Yegappan wrote:


To clear the contents of a list named "abc", we can use "unlet abc[:]".
It looks like a similar method for clearing the contents of a dictionary
is not available. We can set the dictionary variable to another empty
dictionary (but it is not the same). Am I missing something?


The "unlet" command would be a weird way to clear a dict.
The suggestion to use filter() works well enough:

call filter(dict, 0)

Adding a new function isn't really needed, I would think clearing a
dictionary while keeping the identity is rare.


:h filter()
already mentions this method.

But for 0, a string should be used, similar to searchpair()'s {skip} expression
(which does not accept a number):
:call filter(dict, "0")

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5ECD5425.605%40yahoo.de.

Re: Patch 8.2.2071

['Andy Wokula' via vim_dev]

Am 30.11.2020 um 21:12 schrieb Bram Moolenaar:

Problem:Vim9: list assign doesn't except empty remainder list.


:s/except/accept/

--
Andy

--
--
You received this message from the "vim_dev" 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_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5FC67971.2050601%40yahoo.de.