Re: E1208 after compiling vim from git

[Ingo Karkat]

On 23/01/2022 08:43, Thomas Köhler wrote:
> [...]
> So I type ENTER and ":help E1208" and get this:
> E149: Sorry, no help for E1208
> [...]

I had recently experienced the same, with the error in one of my
plugins, after upgrading to the latest Vim.

> Apart from that, I fail to see what's wrong with line 289 of my
> .vimrc:
> /tmp/vim> cat -n ~/.vimrc | grep 289
>289  :com! -nargs=0 -complete=command  Tmake call Tmake(expand("%"))
> [...]

The -nargs=0 states that no arguments will be taken. -complete
configures a completion for arguments. It doesn't do any harm (and
therefore wasn't flagged as a problem in the past), but is somewhat
inconsistent.

According to the code (function ex_command() in src/usercmd.c), this is
supposed to be a warning in legacy Vimscript:

// Some plugins rely on silently ignoring the mistake, only make this
// an error in Vim9 script.
if (in_vim9script())
emsg(_(e_complete_used_without_allowing_arguments));
else
give_warning_with_source(
   (char_u *)_(e_complete_used_without_allowing_arguments),
   TRUE, TRUE);

However, I also experienced this as an error during Vim startup (and
fixed it by removing that superfluous -complete=...)

-- regards, ingo

-- 
-- 
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/943149bf-083f-c766-3647-a33c0f823900%40ingo-karkat.de.

Re: Patch 8.2.2439

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 31/01/2021 18:11, Bram Moolenaar wrote:
>
> James McCoy wrote:
>
>> On Sun, Jan 31, 2021 at 04:46:51PM +0100, Bram Moolenaar wrote:
>>>
>>> [...] + Add GUI support (ignore compiler warnings): +   % sudo
>>> apt install libgtk2.0-dev
>>
>> This should really be libgtk-3-dev.  GTK+2 has been unsupported
>> for years and GTK+3 is already going to maintenance mode as work
>> transitions to GTK+4.
>
> Well, the GTK 2 version works well, while GTK 3 still has a few
> drawbacks, I believe it's slower.

One drawback of GTK3 is that Vim doesn't support a vertical button
layout for dialogs (:set guioptions+=v); I recently discovered and
reported that (https://github.com/vim/vim/issues/7746). That's why I
switched back to GTK2. Regarding the slowness, I noticed visibly
slower screen redraw in GTK2 (e.g. after GVIM becomes the active
foreground application again), but only on my Ubuntu 20.04 machine,
not on 16.04.

> Also, that one package does not appear to be sufficient.  If I
> remove the libgtk2.0-dev package and install libgtk-3-dev:
>
> configure:9420: checking for pkg-config configure:9438: found
> /usr/bin/pkg-config configure:9450: result: /usr/bin/pkg-config
> configure:9477: checking --disable-gtktest argument configure:9487:
> result: gtk test enabled configure:9533: checking for GTK -dev
> package configure:9611: result: no

Instead of explicitly installing the compiler and various dev
packages, I have been using
$ apt-get build-dep vim-gtk3
- From the apt-get man page: "build-dep causes apt-get to install/remove
packages in an attempt to satisfy the build dependencies for a source
package".

So if you want a Vim with similar build options as the distribution's
version, this seems to be a really convenient and future-proof
alternative command. (You still need "apt install git", as Ubuntu
doesn't know how you obtain the source code.)

(This is for Ubuntu 20.04, which ships the GTK3 variant by default. On
Ubuntu 16.04, it used to be build-dep vim-gnome, for the GTK2 variant.)

Interestingly, build-dep installs gcc as the compiler - I don't even
have clang installed; always compiled Vim with gcc.

> Hmm, pkg-config does list "gtk+-3.0", not sure what is wrong... It
> seems configure doesn't check for GTK 3 for some reason. Debugging
> shell scripts...

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

iQEcBAEBCAAGBQJgFu8OAAoJEA7ziXlAzQ/vBCkH+wczQLafXuuzDsuxsOMcasGx
49AenMfu1XpkDhDz9RTfh3ZzdX8XVYWNa5d4vL2ZgGIMtmC54GsCmAO68+hmutuF
IzSy5wva6boqxm3GsJU/B9bPDqHNCjTYDm57+0dlFT6L/RbeKDwgrv0KMuj5ydpX
oWzqBZIKP/cPoN/4dpC6eP05ag51FTTb5BurgK71Lj1JL/Piijg/PVHS/8ZxhVM8
NJw6lShM9j5tKRC1opX6Dr/nMGLuUax38Xr6GK9Nh2+2fqQvWHTTeIwiBDl61aDb
qwsoDX5gugeWXSY/yVwJP9s23mPE/zQeKylpk83Ra2XtGmMlkuglOkFCZu+SrmI=
=JvtC
-END PGP SIGNATURE-

-- 
-- 
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/3f5b7e05-5eb2-d61a-b8a4-5655764b311f%40ingo-karkat.de.

Re: Patch 8.2.2426

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/01/2021 12:47, Bram Moolenaar wrote:
>
> Ingo Karkat wrote:
>
>>>> On 29/01/2021 21:07, Bram Moolenaar wrote:
>>>>>
>>>>> Patch 8.2.2426 Problem:Allowing 'completefunc' to
>>>>> switch windows causes trouble. Solution:   use
>>>>> "textwinlock" instead of "textlock". Files:
>>>>> src/insexpand.c, src/testdir/test_ins_complete.vim,
>>>>> src/testdir/test_popup.vim
>>>>
>>>> I hope that use of win_execute() is still possible during
>>>> completion, right? You already had disabled window switching
>>>> once in 8.2.0614, and after I complained in
>>>> https://github.com/vim/vim/issues/6017 you again allowed
>>>> switching as long as it returned to the original window.
>>>
>>> I forgot about that.  And frankly, reading it again I don't
>>> quite understand why I allowed window switching.  If someone
>>> has autocommands setup, it an fail miserably.
>>
>> Of course the plugin uses :noautocmd. It's the often-discussed
>> tradeoff: Vim's commands primarily focus on easy interactive use
>> (and that's good!); unfortunately, that makes plugins harder to
>> write in a robust way (but it is possible, with some effort and
>> learning). But here I think all completefunc's are written for
>> plugins, never ad-hoc.
>>
>>> As I mentioned: "It's not trivial, I hope it will allow enough
>>> without allowing too much".  So now we found another case where
>>> it causes trouble.  I'm not sure if we can keep fixing every
>>> problem we find.
>>
>> It would just be nice from my perspective to detect the bad cases
>> and only then throw an error, instead of disallowing in general.
>> But I fully understand if that's not possible due to the
>> complexity.
>>
>>>> Many of my completion plugins use window switching, and I
>>>> never had any issues reported because of it, so it's sad that
>>>> you now decide it has to be disallowed in general, just
>>>> because _some_ code _can_ misbehave. As long as win_execute()
>>>> can be used (and that does offer some minor benefits over
>>>> :wincmd w), I can adapt the plugin code (but will then have
>>>> to either drop old Vim versions that don't have it, or keep
>>>> maintaining the existing implementation in parallel).
>>>
>>> I don't like existing plugins to fail, but I also don't want a
>>> misbehaving plugin to cause trouble.  In case a complete
>>> function bails out and doesn't restore the window, what to do?
>>> Restoring the window after the function returns might be best,
>>> but that might fail too (again, because of autocommands).
>>> Perhaps we should disable autocommands while in the complete
>>> function?  It's getting too complicated...
>>
>> I don't think you have to go so far. People will notice when
>> completion breaks and then learn about using :noautocmd,
>> try...finally, etc. Throwing an "E999: Must return to original
>> window" would be fine.
>>
>>> So, what functionality is missing to do what you want without
>>> actually switching windows?
>>
>> If I can still win_execute() within completefunc() to visit
>> other windows temporarily, do search() and cursor() in there,
>> that would be fine. As I hinted at, it would even have some minor
>> benefits, like not having to restore the previous window and
>> windows with a height of 0.
>
> As far as I can see win_execute() works.  So you are OK then?

Yes, I can replace the :wincmd w iteration with win_execute() then.
I'll try to adapt my plugin in the coming days. I'll report back
should I run into any problems :-) Thanks for considering my use case!

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

iQEcBAEBCAAGBQJgFUiZAAoJEA7ziXlAzQ/vCfMH/14KSQdG0lye2eIQ+FQeikon
Dcu/u9c1hP1PsrPAQ6P09QYXtQTsIX7OtySX23Vyow9luPvzeRFX3ZOxImgsux4c
MHndWSz/as8N58QGZO7TnbriWsTqOA1LKEWdKfI6hpITQB55bK8SaHjiapNc0oGN
jiK2Zuzuf3QfYuLM9dqPme5WcZ/SyECi6GGBsYUbPKZS5qgsZz0aku3V3NIjOHMo
SiTpVOQtxL4VCBTH0NOXDQ/kgR6rSsogLHVSh2ZbEjQRU6DvVpdQHoTQicYXVFAT
OYaoQYnhWoVK0mSPN7TN6IWBToASKki8J9LzzEIswQhqeMPfoTpiNWVslD1MR0I=
=lazK
-END PGP SIGNATURE-

-- 
-- 
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/7c6aec0b-442c-81b0-14da-9a9f94db8e44%40ingo-karkat.de.

Re: Patch 8.2.2426

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/01/2021 22:14, Bram Moolenaar wrote:
>
> Ingo Karkat wrote:
>
>> On 29/01/2021 21:07, Bram Moolenaar wrote:
>>>
>>> Patch 8.2.2426 Problem:Allowing 'completefunc' to switch
>>> windows causes trouble. Solution:   use "textwinlock" instead
>>> of "textlock". Files:  src/insexpand.c,
>>> src/testdir/test_ins_complete.vim, src/testdir/test_popup.vim
>>
>> I hope that use of win_execute() is still possible during
>> completion, right? You already had disabled window switching once
>> in 8.2.0614, and after I complained in
>> https://github.com/vim/vim/issues/6017 you again allowed
>> switching as long as it returned to the original window.
>
> I forgot about that.  And frankly, reading it again I don't quite
> understand why I allowed window switching.  If someone has
> autocommands setup, it an fail miserably.

Of course the plugin uses :noautocmd. It's the often-discussed tradeoff:
Vim's commands primarily focus on easy interactive use (and that's
good!); unfortunately, that makes plugins harder to write in a robust
way (but it is possible, with some effort and learning). But here I
think all completefunc's are written for plugins, never ad-hoc.

> As I mentioned: "It's not trivial, I hope it will allow enough
> without allowing too much".  So now we found another case where it
> causes trouble.  I'm not sure if we can keep fixing every problem
> we find.

It would just be nice from my perspective to detect the bad cases and
only then throw an error, instead of disallowing in general. But I fully
understand if that's not possible due to the complexity.

>> Many of my completion plugins use window switching, and I never
>> had any issues reported because of it, so it's sad that you now
>> decide it has to be disallowed in general, just because _some_
>> code _can_ misbehave. As long as win_execute() can be used (and
>> that does offer some minor benefits over :wincmd w), I can adapt
>> the plugin code (but will then have to either drop old Vim
>> versions that don't have it, or keep maintaining the existing
>> implementation in parallel).
>
> I don't like existing plugins to fail, but I also don't want a
> misbehaving plugin to cause trouble.  In case a complete function
> bails out and doesn't restore the window, what to do?  Restoring
> the window after the function returns might be best, but that might
> fail too (again, because of autocommands).  Perhaps we should
> disable autocommands while in the complete function?  It's getting
> too complicated...

I don't think you have to go so far. People will notice when completion
breaks and then learn about using :noautocmd, try...finally, etc.
Throwing an "E999: Must return to original window" would be fine.

> So, what functionality is missing to do what you want without
> actually switching windows?

If I can still win_execute() within completefunc() to visit other
windows temporarily, do search() and cursor() in there, that would be
fine. As I hinted at, it would even have some minor benefits, like not
having to restore the previous window and windows with a height of 0.

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

iQEcBAEBCAAGBQJgFH6RAAoJEA7ziXlAzQ/v12AH/3WtTP2o2pmOr0F3wX+X+Txv
Yzo2HNJ+eJ72SNMVxT1D6vtkOswY6Bp46O3n9J0Mf/+9qprCTjW3bPehPRNr/LpW
Loi5X2qjWL+YqfYr2OEevrRP6MomGGboJagl9fK94PJDf9hQzxD3OibmUCWZCi9K
tfRo0y4YAmtXeI/+/Nzj1m+30HTs894LaSc7h5rZbsXEw5XtQfhz/zXS9IO8jTG8
vc9swhIaQo0WE5CZroMgXh/GZDeY0K4Bi/6xGu+Ca7R9R+xPG1rJnLbQvF44+Ra9
nbaKsLwL6/O9j/UD1cn5yc7IxLngtQzH58Kp7H4OuAIQ7aHfWsUKhVSxpk3bDiQ=
=ub/4
-END PGP SIGNATURE-

-- 
-- 
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/319ba817-c090-b6fb-8582-cd590d046fb0%40ingo-karkat.de.

Re: Patch 8.2.2426

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 29/01/2021 21:07, Bram Moolenaar wrote:
>
> Patch 8.2.2426 Problem:Allowing 'completefunc' to switch
> windows causes trouble. Solution:   use "textwinlock" instead of
> "textlock". Files:  src/insexpand.c,
> src/testdir/test_ins_complete.vim, src/testdir/test_popup.vim

I hope that use of win_execute() is still possible during completion,
right? You already had disabled window switching once in 8.2.0614, and
after I complained in https://github.com/vim/vim/issues/6017 you again
allowed switching as long as it returned to the original window.

Many of my completion plugins use window switching, and I never had
any issues reported because of it, so it's sad that you now decide it
has to be disallowed in general, just because _some_ code _can_
misbehave. As long as win_execute() can be used (and that does offer
some minor benefits over :wincmd w), I can adapt the plugin code (but
will then have to either drop old Vim versions that don't have it, or
keep maintaining the existing implementation in parallel).

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

iQEcBAEBCAAGBQJgFHQKAAoJEA7ziXlAzQ/v6FwH/19yswATLqxjfaPcTmyFvfjb
q+87zXc1hM3Mb9kGPne1iuP/SeojuijJPRr4r4+ACgOI2QSq1sfoFkAk7nnMZ/rX
Idaub35QBY10iEdSo4T2//ttNrkMujCNHiopfQGCwdhofqiSuxK3zT3jvY52UfpF
CRKZ4a7N12ImTP3KjDCW1iWJeIyP4ZBQePVpURU4gyIcQWNQWmULSncfQ/IoLu59
zg5gS8FWENdsDB4ICiTIn9ZL5QTXVzQIUVJK6yz1t+IvvucfjJMXaDe7ekPawSpv
bZITYJss86cLOPMfB5sh8G9bedcFG67IMtZnbGnq5/WW1g04LQAdYaCG+t7vRVs=
=R0Vs
-END PGP SIGNATURE-

-- 
-- 
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/e3c632df-c91e-f706-78e4-d6224608d4f8%40ingo-karkat.de.

Re: [vim/vim] netrw: Fix gx command (#7188)

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24/10/2020 20:52, Charles Campbell wrote:
> Charles Campbell wrote:
>> James McCoy wrote:
>>> On Thu, Oct 22, 2020, 21:39 Charles Campbell
>>> mailto:campb...@drchip.org>> wrote:
>>>
>>> I confess that I'm not a git master.  It'd be a help if you
>>> could send me a patch instead of a commit which I don't use
>>>
>>>
>>> If you append ".diff" to a pull request URL, you get a diff you
>>> can download.  For example,
>>> https://github.com/vim/vim/pull/7188.diff
>>>
>>> Cheers, James
>>>
>>>
>>
>> Hello:
>>
>> Unfortunately:
>>
>> sphinx?   https://github.com/vim/vim/pull/7188.diff ksh:
>> https://github.com/vim/vim/pull/7188.diff: not found [No such
>> file or directory] sphinx?
>> https://github.com/vim/vim/pull/7188.patch ksh:
>> https://github.com/vim/vim/pull/7188.patch: not found [No such
>> file or directory]
>>
>> Regards, Chip Campbell
>>
> Well, that was dumb on my part.  Here's a new and updated problem:
>
> git pull  https://github.com/vim/vim/pull/7188.diff fatal: Not a
> git repository (or any parent up to mount point /home) Stopping at
> filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>
> Again, I want to pull the diff/patch and not have it bother what
> I've got. I need to check it over, run it through my test suite,
> merge it with the latest netrw (at v171b at the moment).

Charles, that URL gives you a plain diff; download it via

$ curl -L https://github.com/vim/vim/pull/7188.diff

or simply open the URL in the browser and save the page as a text file.

You can also stay within Git, but then would have to set up Vim's
GitHub repository as a remote, pull it (Vim's GitHub page has all the
details behind the "Clone or download" button), and then you can diff
it there, but it would be way more complex, and not so useful, anyway,
as you maintain your plugin separately from what gets included by
Bram. (So sooner or later you'd still need to produce a diff to move
the changes over to your copy.)

Like Vim, Git has a steep initial learning curve (I've been there as
well); take your time!

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

iQEcBAEBCAAGBQJflIlmAAoJEA7ziXlAzQ/vIWwH/Az1SjjjNbVwbp8+W7JE+t2J
tmEESsMPId38bO2qBe7jSXKXPZdvn/4twaW8JZuid35XxKVRUpC0RH44XiBYHlKB
XKe/3/h8HBPJuqUwPrnh7LiQzM3erkiDt0qo8QEovU3SueG5BGwAzWThcHamxoOn
DK2eTtz/f3ED91EU8RuZ5g6BvEYVVpLlSx5JQ42SyuuHi8HS4GoXIwE1CA2C0hUD
AMN+XBx8rVOQLKR+1rvfWb0UwgMgh4x7LEwf7Glonp0B3cvusoX05s0cT2xHtcrv
c7qCzjNB/99KgbRpsNahmre1JqUZ4b9Dd13ENhB9d9Dvmb6BpF8PzLU71jxqmt4=
=smqM
-END PGP SIGNATURE-

-- 
-- 
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/a024c195-767b-df85-cbb2-0efcd8f1a92a%40ingo-karkat.de.

Re: Vim9 script: first steps

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05-Jan-2020 01:22 +0100, Prabir Shrestha wrote:

> -1 for }. That is the most absurd syntax I have seen in any
> language that only uses it for closing.
> 
> So I went and re-read the poll
> https://github.com/vim/vim/issues/3573. And here is what I can
> think of reading it again in Jan 2020.
> 
> Can we get more info on what does make vim-script faster mean?
> 
> Screen Shot 2020-01-04 at 3.53.13 PM.png
> 
> Screen Shot 2020-01-04 at 4.04.27 PM.png
> 
> Screen Shot 2020-01-04 at 4.05.36 PM.png
> 
> 
> 
> Second comment there says about syntax highlighting. So making
> vimscript faster here won't help much because 
> [tree-sitter](https://tree-sitter.github.io/tree-sitter/) will be
> lot faster than vimscript, which means syntax highlighting in
> neovim will also be more accurate and faster then vim.
> 
> 
> Instead of picking up non real world examples to demonstrate perf
> gains can we pick some proper goals.
> 
> Here are some of the examples I can think of:
> 
> * Faster fuzzy finder. Currently there is 0 plugins that is fast in
> pure vimscript. I would like to see an example of FuzzyFinder in
> vim9 that is fast as https://github.com/liuchengxu/vim-clap and
> https://github.com/junegunn/fzf.vim. Few requirements here:
> Searching large number of nested directories and files,
> highlighting matches. Some of these I elaborated in this comment
> https://github.com/vim/vim/issues/3573#issuecomment-433730939.
> 
> * vim9 syntax highlighting vs neovim tree-sitter syntax
> highlighting. We should count speed as well as accuracy.
> 
> * Fuzzy search for auto complete popup menu.
> 
> 
> I still think WASM is the way to go and not vimscript 9. This way I
> can code in what ever language suits me and just ship the bytecode.
> 
> 
> For example: will vimscript 9 support generics/async,await/pattern 
> matching/threading or greenthreads/immutability? This list will
> keep going on. Making it fast is just one issue it solves. A
> language gets attractive not just for perf but many other features
> that come around it.
> 
> 
> Here is a new WASM runtime since I last mentioned which claims to
> be 15x faster then other c wasm runtimes.
> https://github.com/wasm3/wasm3.
> 
> 
> As a plugin author I can then code in any languages I want that
> suits the needed. For example a python dev might write in python, a
> JS dev might right in Javascript or Typescript if they need typing.
> And they can still write in go/rust/zig or even c if they need
> performance. And most languages these days already support
> compiling to WASM.

I agree; most performance issues I encounter are in syntax
highlighting with large, often deeply nested structures (like big XML
or JSON files). Poor Vimscript performance hardly is an issue for the
kind of plugins that I write; and it's always been possible to use a
language binding and reimplement the core parts, or call out to an
external program (now even easier with the jobs feature). If WASM is
the future (and you present enticing arguments here), deprecating the
many existing language bindings in favor of WASM as the single
go-forward integration would indeed contribute to a simplified code
base, avoid fragmented plugin requirements, and therefore reduce
compatibility issues in the diverse user base.

Still, if Bram has ideas about eliminating some inefficiencies of
Vimscript, so that Vimscript writers can easily opt-in (ideally, in a
backwards-compatible way and without rewriting entire functions or
plugins), why not? Vim, with its great backwards compatibility and
platform support, has been a pleasure to use and extend for many many
years; I'll happily let Bram indulge in such pet projects (and the
accompanying bike shedding about syntax details :-) if that's what
keeps him happy and committed to the project!

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --  https://www.vim.org/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJeEa+8AAoJEA7ziXlAzQ/vX3wH/35PUWts94SNz8IGT2PCG24V
Cs7x14Zj4774qjL6ZWi+rn/7pdzUAzTqapsBoLdBz8qZM3bjV/J0ydwg8D8xSYzo
tCS3LwHL6wGOYpYmg8KuB7+joAkn5TCfOH69f5aXwAje6fL0g91aigYGRmR35Bze
IX0sQwfLesH/zArL1qk7G8pqjrRmmSpG63zyABOeYaTPbKB6rwJ/Dy9vsRdjDAEM
Y/vzqnC6aGHCjGhD/kVzlBaFZTV4YD2TxDdHSXRd+47j5LRr0J4QKLYJj91wgzCE
je5vZn1OTETlAUXzI9+B1u12/XVYEFba4PFQr5EfAY81cZXoF0aWhJ6rwPj1Xj8=
=nFRe
-END PGP SIGNATURE-

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

Re: How about highlighting captured groups in regex?

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07-Oct-2019 13:51 +0200, Dominique Pellé wrote:

> Hi
> 
> Vim now highlights matching text when typing a 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.

I like this idea. It can help by visualizing a complex pattern (while
it's being composed), and it could also be (mis?)used to have multiple
patterns highlighted with different colors in parallel, e.g.
/\(foo\)\|\(bar\)/ would show "foo" in color 1 and "bar" in color 2.
There's definitely demand for that, currently implemented by plugins
(such as my own Mark.vim,
http://www.vim.org/scripts/script.php?script_id=2666) via matchadd().

Regarding the mechanics, I think the biggest challenge lies in the
association of capture group number to highlight group. As your
questions show, this mostly isn't static, but would depend on each
particular pattern. Of course, one could use an off-band mechanism
like separate :hi link Search1 ... | hi link Search2 ... Ex commands
to reconfigure the colors, but that would be cumbersome.

I would suggest to decouple the capture groups from the highlighting,
and instead extend the non-capturing group syntax (\%(...\)) to
optionally supply a color number: \%1(...\) uses Search1, \%2(...\)
uses Search2, and so on. (This is modeled after \%23l, \%23c, ..., and
would not break backwards compatibility.) This allows an in-band
group-to-color mapping, with the downside that captured groups would
have to be explicitly wrapped in a numbered non-capturing group; the
example from above would become a more verbose
/\%1(\(foo\)\)\|\%2(\(bar\)\)/; the benefit would be that another
capture group can be easily added that also uses color 1, or 2, or no
special color at all.

- -- regards, ingo

- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --  https://www.vim.org/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJdm6leAAoJEA7ziXlAzQ/vKIAH/3xpmi7MdaUIJYmbTQ5Xw7CH
cRJTWLFCR5LEQizS+ZKkGjWSuTifpGNBONOfMtsKWyFi4IMuHDIARCea0C1g+DXS
8S8WjQiaQrg2y9PaLiy9rsDmN4nG5Yh5tMaTiQ7eHYKieqq6wxUkzMOouMjtM0ER
TB9JEJDBzfD/Sm36IOfsAr4f8dycSOShZ19PuQSEziWetubTsQ8Csin9M1X+13NA
0oFfM794940huRIBWTGlfiUA+nNtFni6tdsI7B7Uc5WSjfgZc+7qP0Dm+aAdY+UM
+C8Id9eHDwNG1JdKTXrYK5jclnwBSh2cQM2ElU39Lid0JRLVlQIH8zvxXhVh77o=
=jzvb
-END PGP SIGNATURE-

-- 
-- 
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/54680419-6f54-d00e-7c80-b70b839d34b2%40ingo-karkat.de.

Re: Proposal for User methods

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11-Aug-2019 18:51 +0200, 'Andy Wokula' via vim_dev wrote:
> 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.

I agree with Andy and Justin. The vast majority of plugins are small
enough to be written in a procedural style, and any desire to do some
simple object orientation can be satisfied via Dictionary functions
alread. For anything larger or complex, I would use another embedded
language, of which Vim supports many (depending on the build, but both
Python and Perl have very fine and powerful object-orientation and are
commonly available).

The discussion about type annotation and how FuncUndefined would be
affected already shows how hard it is to retrofit these features into
the existing language. (Java did this with generics and closures - but
both still left many unsatisfied with the chosen design, and it took
several committees a long time.) I'd rather have the effort spent on
adding more low-level functions (like the recent chdir() and sign_*()
additions), and to work on the huge todo list; there are still so many
outstanding patches and bugs.

The addition of Lists, Dictionaries and many other things in Vim 7.0
was a good thing - it enabled effective plugin development, and people
desperate for these features were already emulating these poorly on
their own. With the recent addition of closures (which I still
hesitate to use - I still encounter Vim 7.4 on some Ubuntu 16.04 LTS
systems), I think we're now firmly in the area of diminishing returns
when it comes to language features.

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

iQEcBAEBCAAGBQJdUE56AAoJEA7ziXlAzQ/vgBgH/1GX7m7J+NFn56vVrIkiFy/e
hirGIQMdMDk9FiJeqx/EZsCwX61KlVJX5PVp+Kcsw7WL04xKKzEqa1wKIQZTWKPi
iXb2oUyWOtkDMaJG7SRLFXkFmLldVdZjLUaUl5HFoLJ5W+0gSSUNUTwa62NB5OlC
P63waSB0yVwCvhmaeKOl0BS0bLsvhHjUbOgj+kuCDJHiR7aikOL/39EJwfaWrkdx
VwJ7naTth9ZnzsLSG7HvUhrZAn+ozJkh6R94b/7PVOtdBL0VrFi+c9A+wQP/cykB
J55T7D7BaCQLnS12m63c5nSA6GQ7qSEp1NpUZ1jkSBGec2EMbjPLdXXWIs8A15w=
=puBU
-END PGP SIGNATURE-

-- 
-- 
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/4ece52e1-33c0-68fd-c7d9-002f20d094f1%40ingo-karkat.de.

Re: Setting buffer contents by byte offset

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11-Jul-2019 10:45 +0200, Paul Jolly wrote:

> Thanks, Tony.
> 
> Your response has helped me understand that my substitute solution 
> will not work here either.
> 
> Reason that neither solution will work is that it requires moving
> the cursor, and that's not at all desirable in this case.

I would not generally rule out cursor moves; within a function, Vim
doesn't update the screen, and you can save and restore the original
view via:

let l:save_view = winsaveview()
" Your moves here
call winrestview(l:save_view)

Many plugins use this.

> Effectively what I'm after here is a byte-offset based equivalents
> of bufsetline(), appendbufline() and deletebufline().

Given that Vim is a text editor, and text is organized in lines, I
don't think there's enough demand for such variants, especially since
workarounds should exist (see above).

- -- regards, ingo

> On Thu, 11 Jul 2019 at 09:32, Tony Mechelynck
>  wrote:
>> 
>> On Thu, Jul 11, 2019 at 9:55 AM Paul Jolly 
>> wrote:
>>> 
>>> Hi all,
>>> 
>>> I've tried various permutations of search terms, but so far
>>> turned up a blank.
>>> 
>>> Is there a function/similar that will allow me to set buffer
>>> contents between a start and end byte offset?
>>> 
>>> If there isn't, I have a "backup" in the form of a :substitute
>>> like:
>>> 
>>> %s/\%3l\%1c\_.*\%4l\%1c/hello\r/g
>>> 
>>> (because I'm also deriving the line and col whilst deriving the
>>> byte offset) but I suspect the byte-offset based approach will
>>> be considerable more efficient if available.
>> 
>> see :help go :help v_c
>> 
>> You could "go" to your starting point, set Visual mode, go to
>> your ending point, and then "c"hange or "s"ubstitute.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJdJxbFAAoJEA7ziXlAzQ/vg8gH/RkwflvA7kH7gXkteAsqVrez
Ar7o0i3NGHJCpIwuStII5fg3s+IGqDrbNsZYtSs9W1srzdC6TnkMuLza3cbeVoh0
SE/+oQyhTaWdcblDgfb/xAgRwW2nYGw8ag6OSIkEAkjgnW38pr7Tk4q3M1eRjdra
d1pVj0Fhd9OocRq/gq03NCE7ob19y1cCBMDvBXiu0BXT5b8G5M5AWZ6xsRt83mMv
NTFO9Rq9LwrvqHJk9u0FhFitXhe5n+FR1N8Ckg8YSS16WloiCIyMm3BLTcbxcYYG
rMcELFjOopUsziG+g09nEFf0Y/A/pl+oTqC2HbeqREb8Dfbw4yzUMuGEzkwCo+k=
=SrdA
-END PGP SIGNATURE-

-- 
-- 
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/ff85b092-f2f2-c37d-8547-c217215be216%40ingo-karkat.de.
For more options, visit https://groups.google.com/d/optout.

Re: CursorLineMoved

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 13-May-2019 21:20 +0200, Edward Peschko wrote:

> All,
> 
> I'd like to be able to write a macro that could be triggered each time
> the line changed - so that I could write an autocmd to say
> automatically split a logfile in vim that has stack traces to show the
> corresponding code for each line in that stack trace.
> 
> However, the closest thing that was brought to my attention was
> CursorMoved, which IMO is way too broad. After all I don't want a
> potentially expensive macro to be done *every* single time the cursor
> is moved, just when it moves lines.

I've encountered the same use case (also around logfile processing - the
conditional is here [1]); if you do a quick comparison with the stored
last line number at the beginning of the :autocmd and return early if
the line hasn't changed, the performance seems to be okay (for me, so
far).

> So I was thinking CursorLineMoved. Is there such a thing? If not, it
> looks fairly easy to add, but i'm not all that keen on supporting my
> own vim, so would a patch like this be welcomed?

This doesn't exist yet. To consider such an addition:
- - Is there a need? Now, we've already got at least two use cases (from
  you and me).
- - Is it easy to implement with few changes? You say it is.
- - Does it help improving performance? If the core C code essentially
  does the same as a Vimscript would do, all we'd save is a little
  interpretation overhead. But if there's a better place (e.g. the
  'cursorline' drawing code also has to consider the current line
  number), it could be more efficient.
- - Does it improve the Vimscript API? A dedicated CursorLineMoved event
  type provides precise semantics, and would avoid boilerplate code (if
  just a single conditional here).
- - Is this easy to emulate? Only future Vim versions will have the new
  event. Plugin writers still have to provide a fallback implementation
  for older versions. Here, I think this is not a problem, as this is
  just about efficiency gains.

- -- regards, ingo

[1] 
https://github.com/inkarkat/vim-LogViewer/blob/eb5f2601d3521b001612002d609386713d2ad707/autoload/LogViewer.vim#L200-L203
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJc3S1pAAoJEA7ziXlAzQ/vwXEH/1DJ5Gs/wv3/gSpnimVEa9SX
lEAtcaGgD3ko7J88rla1l4HoyQddOwRiLoqvKrlobC7QbizLHJsCXEHa1LL0/6Q0
ImduN5PQxUIml5J5EbH2pBvfLvSqjOWKLrIiLbnjuMLBMJXr3Ia4XbVyEPCgHMdu
cG0X0pqtlJw2+pozYxWUj5bYETmd4OgWqOajPRXZZzGUG37O7dJvlvIuDVctlZtF
OWRcaS2BGMy5yX0ZRTnmbXlv7wpEs3KhMo5G7GcXiid2o4yIZwRLgAXReiRT3lbH
gr1jKgxMFObUVTBnbYy+OHxOtIyfGS+aHyb9SazJxmpE0is7Wpy0zZ2tFvEyf/I=
=SLMR
-END PGP SIGNATURE-

-- 
-- 
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/0e53c6cb-1a8c-a347-96f8-cf0a04f2a4b2%40ingo-karkat.de.
For more options, visit https://groups.google.com/d/optout.

Re: netrw

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 22-Jan-2019 10:00 +0100, Charles E Campbell wrote:

> Hello:
> 
> I had two Windows machines; the big one's motherboard died and the
> other lost windows during an attempt to update (just the) linux
> partition (it had been a dual boot).
> 
> So, I'd appreciate some Windows developers help to improve netrw.
> I've got the latest development copy of netrw on my website 
> (http://www.drchip.org/astronaut/vim/index.html#NETRW v165a).

Hello Charles,

First, thank you for keeping up your plugin maintenance over the years
(it's probably been decades by now :-)

Assuming that you've just lost the Windows hardware, but still have
license(s), running Windows in a small VM on Linux can be a good
alternative. VirtualBox is free, and spinning up a small Windows
instance on demand doesn't take too many resources. (Even my 6
year-old laptop can do that.)

I suggest that because solely relying on co-developers for platform
support is hard, at least in my experience.

That notwithstanding, having other people join in is really helpful.
For that, I would recommend to move your plugin development to GitHub
(or alternatives, but as it's the top site and Vim and many plugins
are there, that's a compelling argument). It may initially create more
work (you need to adapt your workflow, people will start submitting
all sorts of issues and problems), but it's far superior a process
than putting a dev snapshot on a website and emailing around patches.

I hope you'll find a setup that suits you well. Keep up the good work!

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --  https://www.vim.org/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJcRuzGAAoJEA7ziXlAzQ/v2EYH/jOOUe2tQCTTjYvAa8qL0zEH
+R2GtmZm6gWRSHaU5JZufyFlPLDhG/hvwd92eEa6EyBNOnpdiCsb8rkVm4pe0MgH
E0TwSiiijsCNlB4sAWuyPS2OIGOoHf0pmY/5Es9NmMbfrayX4dgXSxCS2jWluW/C
lq9gOlrOgIns8rdhtWVl3mnNhTXqKQfG5wl7Z7LMH1kfsGnbgMe/gRwfpcDexDdY
hsRUhbJqHOjBcByuSpndjH8+Nr3/PPqQ8slTdzTvoRbCjVcgjYlCHQPyPUz31Qmh
C1I76i4yKxqUrsd1+ZYeTt3X0Q51ZCzIQ7/xolc+pScZoRrblW9+Yd0X7c5oJBM=
=lE94
-END PGP SIGNATURE-

-- 
-- 
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: C-c triggers InsertLeave event if used in an inoremap

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 01-Nov-2018 21:09 +0100, Bram Moolenaar wrote:

> Ingo Karkat wrote:
> 
>> On 30-Oct-2018 07:48 +0100, Christian Brabandt wrote:
>> 
>>> On Mo, 29 Okt 2018, Bok Woon Chua wrote:
>>> 
>>>> I have an autocmd that saves the current file on
>>>> InsertLeave. Using C-c in insert mode doesn't trigger this
>>>> save (as desired), but if I use it into an inoremap mapping
>>>> like so
>>>> 
>>>> inoremap  I
>>>> 
>>>> ,it triggers InsertLeave whenever I use C-a to jump to the
>>>> start of the line and hence saves the file.
>>>> 
>>>> Is this intentional behavior? Is C-c supposed to avoid 
>>>> InsertLeave only if used interactively, rather than in a
>>>> script?
>>> 
>>> I believe this is intentionally and expected.  does not
>>> work as "abort" key if it comes from a mapping (or has been
>>> mapped).
>> 
>> Yes, that is the current behavior, but I agree with Bok Woon Chua
>> that this is unexpected and inconsistent with how other mappings
>> behave (i.e. they transparently forward the original behavior
>> without changing it). The problem even occurs when mapping 
>> onto itself (:inoremap  ).
>> 
>> I know that relying on  not triggering InsertLeave is bad
>> form, and Vim's Todo list is very long, but especially in light
>> of the recent poll about what plugin writers want, fixing such
>> inconsistencies would be very welcome. In some situations,
>> details like this can make or break a plugin implementation.
> 
> Unfortunately this behavior has been documented and users may rely
> on the current behavior.

Do you mean with "this behavior" that  does not trigger
InsertLeave? I would want to keep it that way, as this indeed is
documented. What I would like to change is that when  is used in
the right-hand side of a mapping, it should also not trigger
InsertLeave, but right now it does. That's the complaint of the OP and
the inconsistency I meant.
Having keys to trigger () and not trigger () InsertLeave is
documented and can be helpful. But it's surprising that this special
property of  gets lost when it is part of a mapping. I haven't seen
that part documented anywhere yet, and I think it's a side effect of the
current implementation, not planned behavior.

> I was planning to add a more generic mode-change autocommand.
> There is a request for Visual mode enter/leave, for example. 
> Perhaps triggering whenever the return value of mode() would change
> is the most generic solution.  But that needs some more
> investigation.

That sounds really good. I also remember questions about hooking into
entering visual mode, and the current workaround (mapping all v / V /
CTRL-V variants) is not very nice. I don't think it would help with OP's
mapping problem, though.

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

iQEcBAEBCAAGBQJb22UEAAoJEA7ziXlAzQ/vfvMIAIFx5YspbuaISQAvL80E+UXW
x7cCFpWwjEOgstkKZie9iAlYDsYHoWU/UqFu9bfzSxN4qvDCs8hf5dV59DmQckqm
N14pIXyV7qRUsKJ1JQOiyRpx5T9es7Xmt+e6+xmO+T7ga79xSZnBDWDIT+onhqCz
DK9jYKXpQy1alR8V/sKeOrQrFT9eYqdmgdwL5KGSwbeDpGv5daU6lH28bSC2SKNt
bByISqoAl4kNVvFdOlz/jIrM3GSuwZHMrxuhn+CLvc27EF1EXcsWsXelVuV1a9eL
9jM5HMCM+xDmlhQkTmkTrYHrVqUf0dhByrxVwoVizn5gLdkw7bZzv4id7Qtm8Ss=
=kobq
-END PGP SIGNATURE-

-- 
-- 
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: C-c triggers InsertLeave event if used in an inoremap

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30-Oct-2018 07:48 +0100, Christian Brabandt wrote:

> On Mo, 29 Okt 2018, Bok Woon Chua wrote:
> 
>> I have an autocmd that saves the current file on InsertLeave.
>> Using C-c in insert mode doesn't trigger this save (as desired),
>> but if I use it into an inoremap mapping like so
>> 
>> inoremap  I
>> 
>> ,it triggers InsertLeave whenever I use C-a to jump to the start
>> of the line and hence saves the file.
>> 
>> Is this intentional behavior? Is C-c supposed to avoid
>> InsertLeave only if used interactively, rather than in a script?
> 
> I believe this is intentionally and expected.  does not work
> as "abort" key if it comes from a mapping (or has been mapped).

Yes, that is the current behavior, but I agree with Bok Woon Chua that
this is unexpected and inconsistent with how other mappings behave (i.e.
they transparently forward the original behavior without changing it).
The problem even occurs when mapping  onto itself (:inoremap 
).

I know that relying on  not triggering InsertLeave is bad form, and
Vim's Todo list is very long, but especially in light of the recent poll
about what plugin writers want, fixing such inconsistencies would be
very welcome. In some situations, details like this can make or break a
plugin implementation.

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

iQEcBAEBCAAGBQJb2yyoAAoJEA7ziXlAzQ/v5cwH/0gksasIkvlUHudUCtajggyA
hbbaHDO3BDm/dTdUt0pvu70LLo+srgW+MBvELcXWpWbIbaA/LmTMwXClUfUB8vgl
5myi2NZHy3n4rC9D5gO+dZ0ugmIt0+8dgVU4i1wZ+fyhSH3au9r8cecj+VaCnsLs
UIP+UzJ3vVpCI97xcvWHe4h6oAXPc+MRBAnPLCmTiztRE/vvab4PMHjA75QI1ZRi
K+FvOKS4Ixa13GWNuKwLeOtklyNgY3PvyFwI4eDqXT1q367/+g7IbM9y/+bIEpLp
2gg1islAFTvHJxv3INXJPWN2LNQJnHivxqDIhVH6YSStPGJGXjLLfCY7m3Pm+yw=
=95xU
-END PGP SIGNATURE-

-- 
-- 
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: Problematic doautocmd behavior

[Ingo Karkat]

On 14-Apr-2018 20:39 +0200, Christian Brabandt wrote: 

> 
> On Sa, 14 Apr 2018, Ivan Brennan wrote:
> 
>> When your plugin wants to provide an event the user can hook into, it could 
>> broadcast a User autocommand:
>>
>> function! foo#do_it()
>>   call s:do_thing()
>>   doautocmd User FooDidIt
>> endfunction
>>
>> If the user's vimrc contains,
>>
>> augroup MyGroup
>>   autocmd!
>>   autocmd User FooDidIt call MyHandler()
>> augroup END
>>
>> then MyHandler() will be called any time foo#do_it() runs.
>>
>> If the user *does not* set up any such autocommand, however, any time 
>> foo#do_it() runs, Vim displays "No matching autocommands".
>>
>> You could suppress these messages by prefixing doautocmd with "silent", but 
>> that would also suppress any messages a handler tries to display. So most 
>> plugins wrap doautocmd in a conditional:
>>
>> function! foo#do_it()
>>   call s:do_thing()
>>   if exists('#User#FooThing')
>> doautocmd User FooThing
>>   endif
>> endfunction
>>
>> When providing an event the user can hook into, I'd think it's better to 
>> decouple the plugin from any knowledge/concern about what, if anything, has 
>> been set up to listen for the event. But we're forced to run this check, 
>> given how doautocmd works.
>>
>> More importantly, the exists() check is inaccurate in some cases. For 
>> example, the following are two autocommand definitions are equivalent,
>>
>> autocmd User FooBar,FooBaz call MyHandler()
>> autocmd User Foo{Bar,Baz}  call MyHandler()
>>
>> but exists('#User#FooBar') will return true for the first and false for the 
>> second.
>>
>> I can see the usefulness of displaying No matching autocommands for 
>> debugging purposes, but beyond that it seems like bad behavior.
>>
>> Am I thinking about this the wrong way?
> 
> You are probably right. However most plugins I have seen usually do not 
> bother and use `:sil doautocmd User ...` So perhaps nothing to worry 
> about?

I agree to both of you. The behavior is unfortunate, and most plugins
(including my own) seem to use :silent doautocmd User. Usually, hooks do
not need to print any messages to users, and if they really need to,
they could use :unsilent, right? Too bad this wasn't better thought
through from the beginning, but I also wonder whether changing this now
would make a difference.

-- regards, ingo

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

[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!) 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('$') : ','))

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

-- 
-- 
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 compile's "make test" fails if 'diodon' manages x-clipboard

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05-Dec-2017 08:45 +0100, C v.St. wrote:
> 
> On 12/05/2017 at 06:41 AM Kazunobu Kuriyama wrote:
>>> 2017-12-05 8:58 GMT+09:00 C.v.St . 
>>> >:
> …
>>> Remembering a similar case, I killed 'diodon' ((...), and
>>> without it, tests pass. I reproduced this on both systems and
>>> remotely between them (ssh -X ...)
> …
>>> Stucki
>> 
> …
>> is the case, please try running `make test_gui` in the `src`
>> directory several times to make sure that the test gets passed
>> successfully at last.
> 
> It definitely fails, as long as 'diodon' is active. (tried in a few
> UBUNTUs and DEBIANs).
> 
>> Another is that the clipboard manager interferes with the test.
>> When this is the case, please turn it off while you run the test
>> suite.
> … Did that already, and on all tested systems test passes, but only
> if NO diodon is running.
> 
>> Of course, the best for me is that you send us a patch for fixing
>> it :)
> 
> Sorry, I'm a long time 'user' of vim, unable to work without it,
> but never learned programming real problems on it. So it would need
> weeks.

I can confirm this issue; have noticed it on my Ubuntu 16.04 LTS
systems and Diodon 1.3.0, too. Diodon does not actively modify the
clipboard; it just provides a clipboard history (and I have configured
it to also capture X selections for the history). Therefore, it
*should* be able to coexist peacefully with Vim's tests; maybe this is
a timing issue? Unfortunately, I don't know how to troubleshoot this;
best I could do is temporarily shut down Diodon during test runs with
this Bash function (that runs inside a wrapper script around "make test"):

#v+
diodonWorkaround()
{
# XXX: The diodon clipboard manager disrupts the test_gui.vim >
Test_quoteplus()
# We need to stop it during test execution.
diodonPid=$(pgrep diodon)
if [ "$diodonPid" ]; then
kill -9 "$diodonPid"

finally()
{
diodon %u
}
trap 'finally' EXIT
fi
}
#v-

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

iQEcBAEBCAAGBQJaJlxQAAoJEA7ziXlAzQ/vSPEH/ieXpdCWvvTNRlciohvCX6e4
SvOgIW+pV6OYIU0TLAasa0VpPaGhpLPS+VnBEBu3gzXmIjPpV2n6GdFwyOwmzy1F
nMrv+lFPRAUp7/ZDDrCUif7ASrYsqiH+96RAapACTRMDMp1s2zom0Q7eFd5PZ6LS
xnyc6FTf/Vbe/TpILhBCiyT22HRiqLBuoBEhPnPkwvE4x6H0HCQoUOJq4UTw7unJ
21wXYTWjWuXBCpzsCkUiosyGSB769ijhy+kmQAkB4B4+9ZrWKPpT45Ek0GNs1PB7
Y6lkHgNXkDxJLzuDBMn+k26Eez0MhfVcQLs7VWLPEEOUQWFdOmi8DVob/3b5lwI=
=Uzt7
-END PGP SIGNATURE-

-- 
-- 
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: difference between submatch(1) and \1 intended?

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 24-Nov-2017 15:13 +0100, Christian Brabandt wrote:
> 
> On Fr, 24 Nov 2017, Marius Gedminas wrote:
> 
>> On Fri, Nov 24, 2017 at 11:30:03AM +0100, Christian Brabandt
>> wrote:
>>> Hi, while writing the test for checking the URLs I stumbled on
>>> this difference between submatch(1) and \1: #v+ let a = '
>>> https://www.vim.org   ' let g:pat = '.\{-}\(http[^ ]*\).\{-}$' 
>>> echo substitute(a, g:pat, submatch(1), '') echo substitute(a,
>>> g:pat, '\1', '') #v-
>>> 
>>> If you execute this piece of script, the first map() returns an
>>> empty list, while the second map() returns the URL stripped by
>>> whitespace (which would be my expected behaviour for both map()
>>> calls).
>>> 
>>> Is this expected?
>> 
>> You're calling submatch(1) and then passing the returned value to
>> substitute(). Try
>> 
>> echo substitute(a, g:pat, '\=submatch(1)', '')
>> 
>> or
>> 
>> echo substitute(a, g:pat, {m->submatch(1)}, '')
>> 
>> or
>> 
>> echo substitute(a, g:pat, {m->m[1]}, '')
> 
> It is only valid in a expression context of the replace part in the
>  substitute() function? That is not how I read the help. That
> should be stressed some more (or generate an error, if this is
> generally invalid perhaps?)

:help submatch() mentions right at the beginning:
,
| Only for an expression in a |:substitute| command or
| substitute() function.
`

When you invoke substitute(a, g:pat, submatch(1), ''), you _first_
evaluate submatch() as an argument to be passed to the substitute()
function, so it's clearly outside of the substitution context. You
have to use a String expression or lambda, as Marius has shown. I'm
not sure whether an error is called for here; the programming error
should be pretty obvious when testing, anyway.

Have you been working in a different programming language recently? I
find these things (variable interpolation and :execute is another such
area) natural as long as I'm working in Vimscript; but then they
suddenly appear odd when coming from a different language.

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

iQEcBAEBCAAGBQJaGDmgAAoJEA7ziXlAzQ/vnQcH/3FkOVsJnN2dEX5GUAR0gqur
MiMvrmsBqdyVZ9x53drmiNnO6ak024A71ugrNoKZ5h+ivli7rW1KXrzNMfK2fhoJ
RhkWsMoeGi2qJ75uQp4azOS/5ekuwQRNr0eNFjWEmukKb7rBcXEXQ2LbJz1d65+r
BiIP8CiCknxO2v00+yhIMCd5Qhcm5s783M5VgPNefUC6yHx/p2+DIGpztkUPeXRL
rnYatuGxhhCalxTSrKpRBkLTKvolehQyv16zv/LnV3QbC3tBJrgkNopvlVfA4hCg
51X3M1rubqUf7DjUMXwhwXmoZr1M6V1/ehrLdbfLIQzNmPRblU5lMgU4S5XuxL0=
=nNPp
-END PGP SIGNATURE-

-- 
-- 
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: hlsearch and empty pattern branch

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12-Nov-2017 15:03 +0100, Nazri Ramliy wrote:
> On Sun, Nov 12, 2017 at 8:34 PM, Tony Mechelynck 
>  wrote:
>> The way I see it, there was a bug before (which you used as an 
>> undocumented feature), now the bug has been fixed, and you're 
>> complaining. The way your pattern is written, it _ought_ to
>> match everywhere, though in the case of its last branch it is a
>> zero-length match. There was a patch recently about search
>> highlighting… let me see… « 8.0.1250  'hlsearch' highlighting not
>> removed after incsearch ». Maybe that was what changed the
>> behaviour?
> 
> Perhaps. But I find it hard to accept the "undocumented feature"
> part. To compare the regular expression behavior of GNU grep:
> 
> $ echo foobar | grep --color=always -E 'foo|' foobar ^^^ only 'foo'
> is highlighted here, which is similar to how vim behaved before
> this, but not recently.
> 
> The current vim behavior now seems to say "empty pattern match 
> anything, so that's why everything gets highlighted" which feels 
> wrong. Empty pattern should not match anything, that's what the
> '.' atom is for, isn't it?.

No, 8.0.1250 was about incsearch artifacts in other windows. I think
the "undocumented feature" is that incsearch now highlights all
matches (8.0.1238: incremental search only shows one match), not just
the next one. Previously, an empty branch would just match a single
character under the cursor (so just one screen cell would be colored /
the cursor would re-appear with IncSearch color); now, _every_
character gets highlighted.

Though technically correct (an empty branch matches anywhere), this
indeed is irritating with the new incsearch behavior. Even when typing
the search pattern quickly, the whole buffer will suddenly "light up".
A special case would be nice: If a pattern matches anywhere (like the
empty branch), do not apply any incsearch highlighting at all.

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

iQEcBAEBCAAGBQJaCHu7AAoJEA7ziXlAzQ/vOZEH/2FybJkov3nImu7hgQaYtybf
jrKuYeInOqhN7oFIEE5/lCbPpFcYoTNln+x9U0hDJN5nbOQVC/SvRXW//QXmN4mL
IuhR5pnhhdxgTaIK9SHFXrzHmzhXp1SRu1j+VrPJjlC27MSrdkehuaUV+rjw32qB
J0W0rzA8Sd3pj4umqoaUvYKVjbmoDkoAgDCfMr1k/ty0GJ1TXKENaB5899siw7N1
K2w5HG17sHUuT72cfCRCOIpTvV+6rWT4Olf0H1Pj7V2EPSO7t94yFyAjFmqvI/rs
HU1b3WRdn+W0LtR+XP1KY2TL8suBWTXsi78FimOyhY3qn46ehfJtbsfdOuxBatc=
=ssw8
-END PGP SIGNATURE-

-- 
-- 
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: I want to contribute and chose right project for graduate thesis

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 21-Jul-2017 11:16 +0200, Mario Krajačić wrote:
> Hello, I am student of IT from Croatia on finishing year for my
> bachelor's degree.
> 
> For the graduate thesis I would like to contribute some open source
> project. For example it can be  some bug fix. Language in I work is
> C. My knowledge is shown in programs on git profile:
> https://github.com/mkrajaci
> 
> Project which I choose will be sent to my professor - mentor who
> will approve or not difficulty of project.
> 
> Please advice me about how to help you and choose right project.

Hello Mario,

Thank you for your willingness to support Vim. The source code (mostly
C code) can be found at [1], this includes instructions for compiling
on the various platforms.

There are many enhancement requests and bug fixes to choose from :-)
Have a look at the Todo list [2], and the issue tracker [3].

If you have any questions / need help, or want to get feedback before
embarking on a bigger task, feel free to ask on this mailing list.

[1] https://github.com/vim/vim
[2] https://github.com/vim/vim/blob/master/runtime/doc/todo.txt
[3] https://github.com/vim/vim/issues

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

iQEcBAEBCAAGBQJZcie0AAoJEA7ziXlAzQ/vqHIH/3FeouFptHQX5zXqMeUssYhC
fGQOeazDuFix/Pws4GX0HfjG5xaMMvhud0pxNz06X+cZmyC2wlQpyycczxis+1Jb
/of13w1RMOZZDLTbsustpvdsoO4bRnVTRdvKeJbn7Q4y6rRMjPTBsi+Nt20RuclD
9S3jnD9Pf0HACSMCmhDIKXCBVO/OcaaYcgX3/Jrw3swXsYng72D2ArtOuAUFXMLQ
wZyViAgL3+XfYjJ1tKsQxz0YeM0/HMdWfeIlDgwVsYbBsXrbLE0pBR7qxvGgUI9n
DDqZOSTW1ZCHTO+XFS4Q7qc4vduX4c6E4zaq/shGx2xP8syi7MLrHyOYqN8iOF4=
=k/w6
-END PGP SIGNATURE-

-- 
-- 
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: pack/*/start/*/plugin/*.vim loading twice

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27-Jun-2017 13:51 +0200, Bram Moolenaar wrote:
> 
> Ingo Karkat wrote:
> 
>> On 27-Jun-2017 00:01 +0200, mseplowitz wrote:
>> 
>>> A recent patch seems to have changed the behavior of how my 
>>> plugins load. In particular, it looks like plugin files in 
>>> pack/*/start/*/plugin/*.vim are loaded twice.
>>> 
>>> I'm fairly sure this is an effect of patch 8.0.0612 
>>> (https://github.com/vim/vim/commit/ce876aaa9a250a5a0d0e34b3a2625e51cf9
>>
>>>
>>> 
bf5bb).
>>> 
>>> 
>> [55 lines deleted]
>> 
>> You're right, and thank you for the great and detailed analysis!
>>  You've clearly succeeded in making the fixing as easy as
>> possible :-) That pack plugins are sourced twice is indeed a
>> regression and an oversight from my previous patch. I've just
>> submitted a pull request that corrects the problem (and adds a
>> test):
>> 
>> https://github.com/vim/vim/pull/1801
> 
> Thanks.  However, this still changes the order in which plugins are
> loaded.  We do want the plugins from "start" to be loaded after
> 'runtimepath' plugins.  I'll make another solution, but include
> your test.

Oh, right. Only the first entry is still in front now.

I was afraid that functions that were hard-wired to 'runtimepath' now
had to work with a saved / changed value. Your fix touches quite some
functions; very well done! It's always nice to learn from the master
:-) Thank you very much!

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

iQEcBAEBCAAGBQJZUmNOAAoJEA7ziXlAzQ/vXw0H/2kW58houTbvSfkClwRDxA+y
YjGUFhbslU5iMvSU6/63rdvm7FNlr/psCR8fYEUWoYYqCCyKGVZs8dZY6WeIBGZf
V2veD+xe7gFwa2ibyyF23uir84SaVe8lyrZeGy0fFPnqp41buhHQ8A39j3IBBKfn
7N8WD9K6eu6CsaB8yGKynQ+VNurTadYu6jJoBo82LlS94jTis7+QeD3miTaj/VHq
uQ+zSnN5c5ORwq9KzcD5WGZn+EKaDPE85IAcVxKwS27iCYSTj6T3TIEhzwGgMm5f
m8UTK63h5/xHMM1M2CNXJ1MruO6RDVXU/ldXfiE/lTM/5bmO3r0tkMXoRDyvg74=
=eSC5
-END PGP SIGNATURE-

-- 
-- 
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: pack/*/start/*/plugin/*.vim loading twice

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 27-Jun-2017 00:01 +0200, mseplowitz wrote:

> A recent patch seems to have changed the behavior of how my plugins
> load. In particular, it looks like plugin files in
> pack/*/start/*/plugin/*.vim are loaded twice.
> 
> I'm fairly sure this is an effect of patch 8.0.0612
> (https://github.com/vim/vim/commit/ce876aaa9a250a5a0d0e34b3a2625e51cf9
bf5bb).
>
> 
[55 lines deleted]

You're right, and thank you for the great and detailed analysis!
You've clearly succeeded in making the fixing as easy as possible :-)
That pack plugins are sourced twice is indeed a regression and an
oversight from my previous patch. I've just submitted a pull request
that corrects the problem (and adds a test):

https://github.com/vim/vim/pull/1801


> If this behavior is works-as-designed and/or I should be looking
> into making my plugin files resilient to being loaded a second
> time, please let me know.

Most plugins have a multiple-inclusion guard in the form

if exists('g:loaded_pluginname')
finish
endif

It's not required, but a good idea. Plugin reloads can happen for
multiple reasons (not just bugs), for example duplicate :packadd
commands, or having the same plugin installed twice under different
pack paths.

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

iQEcBAEBCAAGBQJZUjOzAAoJEA7ziXlAzQ/v9wwH/RQw/KM7bEPaXtRnJbe1ckdI
0uYVGDRGDmJN0JbjTjm/VNwNARayO1SbmIKhOeDLlusPJ5S0QHkDWH6algsmQxd+
cqvuQj21KkStkiR/B0rhLzW+pbydMfc+B1dEs9IwRxkh+m9hB6ZHxU886qErhSr/
2PGRxwKgY76SKdECcpFT1Qic3P2uUyQk/C+Uhvv4r8KHI/mVZeOH+q5iOvYwrtLv
uwzTBm4cnNCm023QGr8fTEblKAziuVt4fDbNAu+yugzpiQ0LXzkUAtHrtCNutfn7
prZZxpt74I3Ba6TLhkCkALXzv75CsZb0hdtGioumzNL0j59INK+0Pw4llnGF9xI=
=khY1
-END PGP SIGNATURE-

-- 
-- 
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 periodically trashes the start of a file

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11-Sep-2016 03:27 +0200, Sholto Douglas wrote:

> I have used VIM for many years and am an aficionado. However I
> find it has a VERY annoying habit of occasionally truncating the
> start of a file when I save it. Usually I can get back the missing
> bits by going to the backup file e.g. file.cpp~ But today I find
> that even the backup file has been trashed.  I have lost a heap of
> work, which will set me back hours on a tight timetable. Here is
> the start of the trashed file:
> 
> g`"& kDisableSkipFolders) == kDisableSkipFolders);
> 
> CloseCurrentKey(); return m_vecPath.size() > 0; }
> 
> As you can see, it doesn't look like the start of a C++ source 
> file. Has anyone else had this?  google didn't return any 
> references to it, but I can't imagine I am the only one to suffer 
> this given it has happened many times over the years. Is there a 
> fix for this blight on an otherwise excellent tool?

It looks like a plugin applied commands in the wrong mode, and so some
text got lost, and g`" (a non-jumplist jump to the position when last
exiting the buffer) inserted instead. Which plugins do you use?

Try searching for g`" (or maybe g`) in your ~/.vim directory (and
maybe your ~/.vimrc as well). That might give you the culprit, or at
least narrow it down to a few plugins. You can then try disabling the
plugin (set g:loaded_ in your .vimrc usually works).
Plugin bugs should be reported to its author, naturally.

I don't think this is an issue with Vim itself.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJX1aQXAAoJEA7ziXlAzQ/vpz0H/jCnFLoC37tUNGGaQ/L4PZKH
G8ZJ3zi0S++W1jNrpWBY7Fmx4A61o8Z2vGqF83cI5ebeB6j5R++w4X9JhG1Z/7HQ
tFGO+zZjEY1HLIUr6Bz4enTLobZBjodY3ZEiPdUE9uvZYCbRF3XGIOXYT+56Zze+
IRGCmyKsiEjHFAc7v4RHee732HiGRULtUwY9aHPY3ozKk+qI0z6rjD2KAsr4cSKZ
fRc2bd+3gqjIAUusWwlVLzjO9ek0XokP1sKPgBmcHfm7a+p6xA3Ev18utuGhiUa6
DZzVeR6dzKM6IJmyoz4WhwaHXvFJYzJzzlccF0BNDvMMAfMfGsSB4lXAavfqNZc=
=BlRQ
-END PGP SIGNATURE-

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

[Ingo Karkat]

On 09/02/2016 09:51 PM, LCD 47 wrote:
> On 1 September 2016, Bram Moolenaar  wrote:
>>
>> Patch 7.4.2299
>> Problem:QuickFixCmdPre and QuickFixCmdPost autocommands are not always
>> triggered.
>> Solution:   Also trigger on ":expr", ":cbuffer", etc. (Yegappan Lakshmanan)
>> Files:  src/quickfix.c, src/testdir/test_quickfix.vim
> [...]
> 
> Sadly, this breaks the interaction of "syntastic" with all plugins
> that hook to QuickFixCmdPre or QuickFixCmdPost.  An example of such
> plugin is "ferret".  These plugins now have to be fixed to be aware that
> they may be called from things like :lgetexpr.  I'd argue that running
> QuickFixCmd* for :lgetexpr makes little sense, since :lgetexpr is almost
> never called run interactively.  So, was there an actual reason for this
> change, right before the release of Vim 8?

I use the QuickFixCmdPre/Post to automatically open / adapt the size of
/ close the quickfix window, and therefore appreciate that all
quickfix-manipulating commands are covered.

The fix of Syntastic should be pretty easy, as one can use the autocmd
pattern to exclude [cl]getexpr, right?

-- regards, ingo

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


signature.asc
Description: OpenPGP digital signature

Re: Changing the defaults with Vim 8

[Ingo Karkat]

Manuel Ortega  wrote:
> On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar  wrote:
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78
> Please don't "setlocal" a  value for text files.  Don't mess
> with this at all, but if you do, don't make it "setlocal".  It is
> extremely annoying to have Vim sometimes hard-wrap lines and sometimes
> not, depending on which kind of file you're in---unless one specifically
> authorized this by purposely turning filetype plugins on or having a
> plugin/package that does this for certain 

Using :autocmd FileType sets a bad precedent: this doesn't scale (one
autocmd per filetype and setting is too much and bloats the .vimrc), and
Vim has a much better mechanism for filetype-specific settings:
ftplugins (with :filetype plugin on). This way, the change is also
undone (through b:undo_ftplugin), if the user manually changes the
filetype.

With regards to the 'textwidth' setting: I would recommend to leave this
out, as there's no generally accepted notion of a "text" file;
hard-wrapping may be desired or not, so it's best to leave this up to
the user.

-- regards, ingo

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


signature.asc
Description: OpenPGP digital signature

Re: Some changes to the github notification mirror script

[Ingo Karkat]

Hello Christian,

speaking of the github notification mirror script, I noticed a possible bug.

When I recently submitted an issue (https://github.com/vim/vim/issues/892), the 
mirrored email got cut off just before a line that only contained a period 
(".", with whitespace indent in a Markdown code block), as you can see here: 
http://article.gmane.org/gmane.editors.vim.devel/60253

Looks like a parsing / escaping error; it's taking the alternative "full stop" 
pronounciation too literal :-)

-- regards, ingo

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


signature.asc
Description: OpenPGP digital signature

Re: Value of 'v:register' updates too late

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11-Aug-2015 15:18, Bram Moolenaar wrote:
 
 Sampo Osmonen wrote:
 
 When you yank something into a named register the value of the
 internal variable 'v:register' doesn't change back to the default
 register after the yank. The next mapping using 'v:register'
 after such yank will see 'v:register' contain the register used
 by the initial yank operation, which contradicts the description
 in ':h v:register'. 'v:register' only gets updated when some
 operation like moving the cursor or changing the window is
 performed after the initial yank.
 
 Example - Vim 7.4 (Windows):
 
 Write some text in the buffer. Type the commands: _dl:echo
 'v:register'
 
 will show '_' as opposed to '', even though the current command
 (':echo') didn't use any register. Moving the cursor after the
 delete and then checking 'v:register' correctly yields ''
 
 This is obviously troublesome for plugins that rely on
 'v:register' to paste something, they end up pasting from the
 blackhole register for example.
 
 It's been like that forever.  I suspect some plugins actually rely
 on v:register to keep its value.  I don't see how a command can
 depend on v:register for a command that doesn't use a register.

This had been reported before:
https://groups.google.com/d/msg/vim_dev/GiIKJLzH-AM/8rvajv8YkMQJ

Many found the current behavior inconsistent and not helpful;
Christian proposed a simple patch, but there has been no follow-up
yet; I can't even find this in the TODO list.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVzd5PAAoJEA7ziXlAzQ/vt8gH/1te09U0mEwtXiyVYYoWN5Tp
hRZb0wu7J4hSAwv/GbtD9AVVTskpjr5ytRzfOm0SBm6RnSUqV8zv0/mWms8CAlnw
n32ICBREqyEEY/lf1mCMHtT8bubk3UpvO7RpgvKerAG4isHD9Nw1011IS7uKbZYy
bG18d9H78Cw2AF1hcHD8lNu0MkUnDd5bJyvyu8SDPhWUW943apPVX57QmVz0e2+0
w6OMvgRfcVKbeTDHH4yniiM1bH/A36dXorci4bWYZWJcV9wuCvArj358HmEzawG8
OK3rHOj51LBibryNDNiZ9M0lc9ktcSsDkdjm1KMjSlPOdNw90nCe50wb15WC3/w=
=+gcY
-END PGP SIGNATURE-

-- 
-- 
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 to add the :cdo and :ldo commands

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30-Jul-2015 08:21, Christian Brabandt wrote:
 Am 2015-07-29 22:34, schrieb Yegappan Lakshmanan:
 I haven't see any replies so far. I am not sure whether we are 
 agreeing to add both the commands or only the cfdo/lfdo commands?
 Do you guys think that only the cfdo/lfdo commands will be
 useful?
 
 I think, depending on the task, both options could be useful.

I agree; my ArgsAndMore plugin
(http://www.vim.org/scripts/script.php?script_id=4152) also provides
both :CDoEntry and :CDoFile commands.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVunY+AAoJEA7ziXlAzQ/vL6kIAJRbiSHCSL4JDT07ia8DRPwS
gaQGk7/tmngUs8vpwg8Qokx2KthS75eep69dS5KuzL2/f9c+Mdcs/sYbe7QJYE4Y
r3uZvYhxnnvSWyle6+5OCSurUrc4YqG6qozT4EaBTXS9HvuUS4wVO1COTfirUwsG
+IUYfg6X7esgBegTRyV1S2zliUv6y03de3r44L1zfUgU7/96/ODFFanGhb62Ehwc
ZCaSD1X3ElVDOiFN4ZI3g/I7C/WUH1ndp8dB6EkFEM4+VyJVJdwT6W3/scbrDv3P
eEnF5nJIQqgyN4JULRmFEaxYA8V2P0bzsaUvsxGP7g0nPlrtByxKEkxiWtCVa3E=
=jwPs
-END PGP SIGNATURE-

-- 
-- 
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: fixing Todo highlighting chaos

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22-Jul-2015 19:42, Charles E Campbell wrote:
 Ben Fritz wrote:
 Well, sure it's easy to override one file. But you would need to
 do that for literally every filetype you edit in Vim! That's a
 much taller order!
 
 I'm not so sure about that.
 
 * option 1: wait for approval of idea, then wait for many
 maintainers to change their syntax highlighting files to
 accommodate the new approach, then wait for it all to show up.
 Benefits available in indefinite future. * option 2: do it yourself
 as I outlined.  How many filetypes do you use?  I suspect its 10 or
 less, with only a very few often used. Benefits available
 immediately.

How about a combination of the two? Quickly approve the concept of
configurable TODOs (on this list, by Bram), mention this in :help 44.12
(Portable syntax file layout) with an appropriate example snippet, and
syntax plugin authors will pick this up. (Realistically, some sooner,
many later, a lot never).
Depending on which syntaxes you use, you'll like cover widespread
(updated) syntaxes ones with the new, single-place configuration, and
only have to implement special overrides for the (gradually shrinking)
remainder (and can encourage those authors to adopt the new config, best
with a simple patch).

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVr+68AAoJEA7ziXlAzQ/vpQQH/2GOPqeO/tpbmGuEixJ+cmF2
XoLZUgaaZmIpRI0f9oga7aBxKB0w1W+JUcvU6ljh3YaSNAnOJcoEjDHyUJ8emOfU
70tmam1pCo/OLxx8mH4NXAob+5ykx2UxfHSyvj2LXTEr0ruIspAqlKkIqLL4evLS
b7bBoA7RxvZNq/Qs8kjqfI+VA0Wje5+pOqGNt2JtwXZngphMsNRbBgYS9UFP3hvm
psYUnk49WvGcftHTUZhjBA2MbX59EzfvcaOAl+cion0SY2ODOf/OvJX1bv96rVOH
4diF/G/570fuifDgeCUPS5VpQG+aeVmlQ0tlBfnw/DIVWf/r0AjYExXaBfonb4Y=
=EoHo
-END PGP SIGNATURE-

-- 
-- 
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: Supporting multiple shells in system()?

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30-May-2015 05:08, Andy Russell wrote:
 While writing my own plugins, I wish to support users who have fish
 or cmd.exe set as their shell. However, this often leads to a
 tedious pattern of: if fnamemodify(shell, ':t') ==# 'fish'  Fish
 syntax let cmd = ... else if has('win32) || has('win64')  cmd.exe
 syntax let cmd = ... else  POSIX syntax let cmd = ... endif
 
 let output = system(cmd)
 
 I propose that the system() and systemlist() functions be extended
 to abstract these concerns away from plugin implementors. Before
 setting out on the implementation, I'd like to gather some feedback
 concerning the changes that I think would accomplish this in a
 backwards-compatible way.
 
 First, I'd like to allow the first argument to system() and
 systemlist() to be a List in addition to a String. If the argument
 is a List, then the user's shell's equivalent of '' will be
 inserted between each command. That is,
 
 `system(['command', 'echo success'])` would be semantically
 equivalent to `system('command  echo success')` if the user's
 shell is bash, or `system('command; and echo success')` if the
 user's shell is fish.
 
 Handling redirection syntax is slightly trickier, because I want to
 support redirecting stdout and stderr independently of each other
 to a file, as well as keeping the stdin functionality. One solution
 is to allow the second argument to the functions to be a Dictionary
 with the following format:
 
 { 'stdin': (lines to be used for stdin of the first command,
 defaults to nothing), 'stdout': (a file that stdout should be
 redirected to, defaults to being printed) 'stderr': (a file that
 stderr should be redirected to, defaults to being printed) }
 
 Therefore, system('command', { 'stdin': 'input', 'stdout':
 '/dev/null', 'stderr': '/dev/null' }) would be equivalent to
 system('command  /dev/null').
 
 I think that these options would be a huge boon to plugin authors
 and be great for people who use non-POSIX compliant shells. Are
 these changes acceptable? I'd love to hear some feedback.

So, you would need additional options for all these abstracted-away
elements (like :set shelljoiner=), and the user would have to
provide correct values for his shell? I see this as a downside; not
every user knows all those details about his shell.

As a plugin author, I would rather do one of the following:
- - temporarily switch the 'shell' option to the POSIX shell / Windows
cmd.exe, and only implement syntax for those two
- - as a variation of the above, extract the logic into a separate shell
script (with #!/bin/sh), and invoke this single script from Vim (for
which the default options should be sufficient)
- - offer a configuration (g:pluginname_shelltemplate = %s  %s 
%s) for the user to tweak (with a proper default for common shells,
so tweaking is only necessary for esoteric ones)

As a first step towards your proposed solution, you could implement a
Vimscript library that offers all of this; no changes to Vim would be
necessary (many such generic libraries already exist; see
http://www.vim.org/scripts/script.php?script_id=4433 for a list), and
it would work with existing (old) Vim versions. If this library indeed
proves to be very valuable to many plugin authors, it can later be
considered to include this (natively, or just out of the box as a
plugin like netrw) in Vim.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
Using Vim for 13 years now, mostly 'cos I can't figure out how to exit i
t.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVaWpLAAoJEA7ziXlAzQ/vZWEH/1fCPsLvYeWr+YvcfxpBoE+2
WRe7OAL9uN7T/4izUPDfStB4aJBpRNYjoplZvwXe/P5Kr99xaxahfVdx4bTleW7m
MM4v18QnGsnwl4Sd6ZmW6y6zxKwpsWIPQMfe8TeLvl90u5CGrn5aXqja3GaCFDXZ
lSymaaM/zmM/qrrMVjoZksTS9+tOq5p2p0fDHH0ZK10p0jPW5C424xC0NT81JGV4
7sO83NWRhmDOyTflVSBoSdi/hT8sWvzPsAZVxPc3nx2RCceYTpAjC3KF4yHYWwtV
y1S5yNUhivDIhVH7lZViZckR7WponHjyMy3vLmXGvAXkG0iUtyivPqJTXZpEG3g=
=RGIb
-END PGP SIGNATURE-

-- 
-- 
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: v_b_A inserts at start or middle of selection instead of end after 7.4.576

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28-May-2015 21:14, Christian Brabandt wrote:
 Hi Ingo!
 On Di, 26 Mai 2015, Ingo Karkat wrote:
 
 On 24-May-2015 13:15, Christian Brabandt wrote:
 On Mo, 18 Mai 2015, Ingo Karkat wrote:

 Hello Vim developers,

 appending to the end of a visual blockwise selection can be done with
 the A command. I just noticed that this doesn't work reliably any more
 when
 - lines are wrapped and the cursor is in a following screen line AND
 - :set linebreak
 This happens with real blocks as well as a corner case single-line
 blockwise selection.
 To reproduce:

 vim -N -u NONE
 :set linebreak
 :normal! 40afoo bar
 :normal! BB^VeAX
 Appending should be after the selected word (barfooX), but it occurs
 at the beginning instead (Xbarfoo).

 I've bisected this down to the following patch:

 ,[ bad change ]
 | 7.4.576  redrawing problem with 'relativenumber' and 'linebreak'
 `

 Attached is a test that verifies the correct behavior.

 I can reproduce this on Vim version 7.4.716 on Windows/x64 as well as on
 latest Vim 7.4.729 on Linux/x64.


 I can reproduce it. Thanks for the feedback. Looks like one needs to 
 recalculate the virtual column numbers after resetting the linebreak 
 option. This also happens for the OP_REPLACE part. Here is a patch, 
 including your testcase.

 Thank you Christian! Unfortunately, there's still an off-by-one error
 with :set selection=exclusive; the cursor is positioned one character
 left of the selection's end (resulting in barfoXo in the test).

 I hope that is easy to fix; it might also be worthwhile to test that
 variation, too.
 
 Updated patch and test attached.

Thank you very much! I can confirm that this indeed fixes the problem,
with both values of 'selection'. The test with a selection that ends in
a multibyte character is a good idea, too!

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVaBfgAAoJEA7ziXlAzQ/vWncH/RD1olqSK+ROsGLesaaB1+UV
L611Wwe/EOYXZ5Wmtvl2peP8DxXPfsJnz3kW09Jl/KmquMb7QqicqX9sflcJyAin
nA2m390mItXPHm1cCZIF9Q2oNcILSlEumjM0I0dRfD+ioNMYpTN6GFWa7XtOG1i2
9wcCDB7SWuh/nDqi5HOKJR+QFP91jSg4rWN+jn22ehTDC9BH5NFq7kf6MYNbQH/Y
aQo61fbEopnf1sc6JhGyKhYCxebSWNoolvK7Mq8UtVm+yeKLcBbIEFhLxh/2qKyZ
fPvP3Yjb69ZBmGkFBhmf6gbso7iVWeBPv9NJ9pY950b7NVkvEZmCryW2xZv8+k8=
=y9pv
-END PGP SIGNATURE-

-- 
-- 
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: v_b_A inserts at start or middle of selection instead of end after 7.4.576

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 24-May-2015 13:15, Christian Brabandt wrote:
 On Mo, 18 Mai 2015, Ingo Karkat wrote:
 
 Hello Vim developers,

 appending to the end of a visual blockwise selection can be done with
 the A command. I just noticed that this doesn't work reliably any more
 when
 - lines are wrapped and the cursor is in a following screen line AND
 - :set linebreak
 This happens with real blocks as well as a corner case single-line
 blockwise selection.
 To reproduce:

 vim -N -u NONE
 :set linebreak
 :normal! 40afoo bar
 :normal! BB^VeAX
 Appending should be after the selected word (barfooX), but it occurs
 at the beginning instead (Xbarfoo).

 I've bisected this down to the following patch:

 ,[ bad change ]
 | 7.4.576  redrawing problem with 'relativenumber' and 'linebreak'
 `

 Attached is a test that verifies the correct behavior.

 I can reproduce this on Vim version 7.4.716 on Windows/x64 as well as on
 latest Vim 7.4.729 on Linux/x64.

 
 I can reproduce it. Thanks for the feedback. Looks like one needs to 
 recalculate the virtual column numbers after resetting the linebreak 
 option. This also happens for the OP_REPLACE part. Here is a patch, 
 including your testcase.

Thank you Christian! Unfortunately, there's still an off-by-one error
with :set selection=exclusive; the cursor is positioned one character
left of the selection's end (resulting in barfoXo in the test).

I hope that is easy to fix; it might also be worthwhile to test that
variation, too.

- -- regards, ingo

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVZJrWAAoJEA7ziXlAzQ/vjNYH/3dBvD8VuYlIdUx8bLwYhPZ5
Iba4jI/sf63UQpRY2UsYU+TDiTIHF/odFv1Wc+5+YshuUQoEvB8n+SgpO/HCTBSu
UPscktn6K/f2cJ5l6d+VP2D/ZCiO+WLhnPAC4nTN5rAImtKfVxcEU3EhqpRt6745
l2/A6TQVlRbW6P7SE+PUsFVnBpUumdLMEJ/9fKYHBH31QqDPdSNyvhq4h+rGOWCC
I2KFbE24gykd3C3oKxId1GOSfsS077fzPFMjMaqd90KN68zYn7Y083UghmSWnxbm
DPOaydwWo5i6S5GxWxo17ydIFXAHjAZPsN/7SsyNNJbr57H7ktADvsMcdtjfvjI=
=mLDv
-END PGP SIGNATURE-

-- 
-- 
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: v_b_A inserts at start or middle of selection instead of end after 7.4.576

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

appending to the end of a visual blockwise selection can be done with
the A command. I just noticed that this doesn't work reliably any more
when
- - lines are wrapped and the cursor is in a following screen line AND
- - :set linebreak
This happens with real blocks as well as a corner case single-line
blockwise selection.
To reproduce:

vim -N -u NONE
:set linebreak
:normal! 40afoo bar
:normal! BB^VeAX
Appending should be after the selected word (barfooX), but it occurs
at the beginning instead (Xbarfoo).

I've bisected this down to the following patch:

,[ bad change ]
| 7.4.576  redrawing problem with 'relativenumber' and 'linebreak'
`

Attached is a test that verifies the correct behavior.

I can reproduce this on Vim version 7.4.716 on Windows/x64 as well as on
latest Vim 7.4.729 on Linux/x64.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
Using Vim for 13 years now, mostly 'cos I can't figure out how to exit it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVWgMvAAoJEA7ziXlAzQ/vfFcIAIJ1pWeK7OkasA1NZ2vfn+qw
C/XoykrtUeJe8tTkir16Uqx0pZpVhxgpiMXcyV+g6ul+F5YANZTrbgEsykJ7p1bm
4yFq8XT7ga5zGAHyRJ46sGBdIDlfNHposI6GhXqEj5dKl2JomMt0G2wA+F8nMBY7
15cDhv10pRJrd+KLl9TEnvjDY+IiBrTMv3xpqN5j0o8V0JRjtwDuodRi6TdVNkyN
Fi5o5eMA1cmx9S0nJW376P3XWMowimivRH8Hzrkby/gBaE1YBoE1zUtgFSojI1Pj
uqQ9qF9Lf4ciuLsf+SrsMP8pZ/q0oYL0rnwtOll4tnjXmt8CQF6a/bwpxqlQaus=
=TXsw
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/testdir/test39.in b/src/testdir/test39.in
--- a/src/testdir/test39.in
+++ b/src/testdir/test39.in
@@ -51,6 +51,12 @@ G$khhhhhkkcmno
 :exe :norm! 012l\C-vjjAx\Esc
 :set ve= enc=latin1
 :.,/^$/w  test.out
+: Test for single-line Visual block append at wrapped line with :set linebreak
+Golong line: 40afoobar aTARGET at end
+:set linebreak
+:exe :norm! $3B\C-veAx\Esc
+:set nolinebreak
+:.w  test.out
 : gUe must uppercase a whole word, also when ß changes to SS
 Gothe youtußeuu endYpk0wgUe
 : gUfx must uppercase until x, inclusive.
diff --git a/src/testdir/test39.ok b/src/testdir/test39.ok
--- a/src/testdir/test39.ok
+++ b/src/testdir/test39.ok
@@ -30,6 +30,7 @@
x x   line2
x x   line3
 
+long line: foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar foobar TARGETx at end
 the YOUTUSSEUU end
 - yOUSSTUSSEXu -
 THE YOUTUSSEUU END


test-v_b_A in wrapped line.patch.sig
Description: Binary data

Re: abbreviation no longer expand after insert mode remappings

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 06-May-2015 11:21, Enno wrote:
 Hitting a non-keyword character, cr or esc in insert mode with
 the cursor behind an abbreviation (:help abbreviation) expands the 
 abbreviation. However, a mapping to that character no longer
 expands the abbreviation in the same way.

 Is this a bug or on purpose?

At least, this behavior has been in Vim for a very long time, so it's
highly unlikely that Bram changes it, as people or plugins may rely on
that.

 The remedy by prepending C-] to the non-recursively mapped
 character is cumbersome, because now every non-recursive mapping
 must check if the remapped character is a non-keyword character and
 eventually preprend C-].

Do you have a concrete problem? In my opinion, discussing this on a
purely theoretical level rarely leads to something. If you post your
actual issue, I think we can find a solution.

I usually use :imap instead of :inoremap, and then the abbreviation gets
expanded. (I think you're aware of that and referred to it as
non-recursively mapped.) So far, I haven't had any problems with that;
you only have to be careful now that the {rhs} gets remapped, and that
can be controlled via subordinate :inoremap'ed SIDIntermediateMappings
(but not for the first inserted character).

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVSejNAAoJEA7ziXlAzQ/vTx0H/jeSElWRrYZY5jBgwtA0Ru7A
aXOtJpEx2YK4y/3FRjh6RSfuReU+Eg2dxCVE/LmIHsT8hoxLZntZsKHe/6T6r5pz
XQTc3JF/UbWElRi+k7sBuhPDzpoustt+LQgqDsFL9WP1a5xSchT369L3Sg+/rA8P
3DYDRsmtnR2KcjlnReAH0TYHqda9CH/ruhKnpYBZHkcPVF1yTEU6V7FXYglLS57K
svE43j7xh0yvBnFuDK4aX1sCmwESUlz6j1IndUyW1t5FwhwqdHvUdwmf4F6Sxo2q
ku9zIrERwGLGZYwJj+U50q/0EOIfb04l1/Usb8T01nWloqXrqFRwxFxJWjL9N/I=
=pIdj
-END PGP SIGNATURE-

-- 
-- 
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: BUG: :substitute answers (a)ll / (l)ast affect c / g flags on repetition with g and :

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03-May-2015 03:52, h_east wrote:
 Hello Ingo! 2015/5/3(Sun) 4:46:50 UTC+9 Ingo Karkat:
 Hello Vim developers,
 
 if you do a :substitute/foo/bar/c and then choose (a)ll as the
 answer, a repeat of the substitution via g or : does not
 confirm each substitution any more; i.e. the :s_c flag is *not*
 kept!
 
 The documentation of g and :s_ explicitly state that they Keep
 the flags from the previous substitute command.
 
 Likewise, answering (l)ast omits a given :s_g flag on
 repetition.
 
 
 The problem is that the static flags do_all and do_ask are
 modified by the answers, and the modified answers are then reused
 on repetition, whereas the original ones should be restored in
 that case. From do_sub() :
 
 static int   do_all = FALSE; /* do multiple substitutions per line
 */ static intdo_ask = FALSE; /* ask for confirmation */
 
 [...] if (typed == 'l') { /* last: replace and then stop */ 
 do_all = FALSE; line2 = lnum; break; } if (typed == 'a') { do_ask
 = FALSE; break; }
 
 Note: This was originally raised on Stack Overflow: 
 http://stackoverflow.com/questions/3450/why-vim-does-not-preserve
- -c-

 
flag-when-g-used
 
 I understand this problem. I think this should be corrected. So, I
 wrote a patch. Please confirm this.
 
 Thanks.

I can confirm that this fixes both reported problems. ?

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVRzhvAAoJEA7ziXlAzQ/vmQEH/Ax7zP3oTc+4YZxukNrgU0aB
F68V01Pn3+m2EFE5n+5jyAY3HXZG6wgzXqFga71+rE7HoqJMtPY6/WPoT8Wr0y0n
+82JwkV0v+9JBYiywEGliTohKWMdepYQc4EHOsEI+dosiP9YoKvREU+tumZVQ5KL
UdiKVUkZd3xXsyv7VX4bF+6/sS6KBZ+umnnsFagrNddPD1IsCXBQHoLxYWTHTo0z
iTg/B7yOFhPtQII4WjExWzPon8L17TVgrgi1BmWC/xudlP8yP/1BRxONCJzbDfdb
IaJedmceMxsO9/SjFcdXNK3a+DgnF/GqVBLpXSL2BUUNihhUOxeZr7FRk/gC/U4=
=Z94K
-END PGP SIGNATURE-

-- 
-- 
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: :substitute answers (a)ll / (l)ast affect c / g flags on repetition with g and :

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

if you do a :substitute/foo/bar/c and then choose (a)ll as the answer,
a repeat of the substitution via g or : does not confirm each
substitution any more; i.e. the :s_c flag is *not* kept!

The documentation of g and :s_ explicitly state that they Keep the
flags from the previous substitute command.

Likewise, answering (l)ast omits a given :s_g flag on repetition.


The problem is that the static flags do_all and do_ask are modified by
the answers, and the modified answers are then reused on repetition,
whereas the original ones should be restored in that case. From do_sub()
:

static int  do_all = FALSE; /* do multiple substitutions per line */
static int  do_ask = FALSE; /* ask for confirmation */

[...]
if (typed == 'l')
{
/* last: replace and then stop */
do_all = FALSE;
line2 = lnum;
break;
}
if (typed == 'a')
{
do_ask = FALSE;
break;
}

Note: This was originally raised on Stack Overflow:
http://stackoverflow.com/questions/3450/why-vim-does-not-preserve-c-
flag-when-g-used

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVRSmmAAoJEA7ziXlAzQ/vOfoH/jGlusMXE5qlURe1LxQemJmd
M+RyXnCLHOZFR2mBN0owhiPQx6512orde5IuC9+qF4cMyeKi4LfxY9Gq1SKyNs+t
B79uDUuq7JxGUhML2zpvk1xNxfnLrtf9AvvITRFJVj4kM3XC6Qhk3JQOE4mJhHLE
GVYyNZakrBtyoNG2IrpwHzljYuTgqI62INpebVRsoCIapNI6FUoqrTNTq7G0p7gS
wbX50gtsA0AGNnlK5GClCG5RZt1C7lnluup8BZFUDy4fzzuqyxk3xY8JKK/xbizu
XIFjlTYIYckQkKRzfSODXSV/BgwsH4sAv++PorrFJIyCqYEEM1pFEnU6ca60M1E=
=vFcA
-END PGP SIGNATURE-

-- 
-- 
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: Preparations for moving to github

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26-Mar-2015 17:25, Manuel Ortega wrote:
 On Thu, Mar 26, 2015 at 9:43 AM, Ingo Karkat sw...@ingo-karkat.de 
 mailto:sw...@ingo-karkat.de wrote:
 
 Bram already is a bottleneck in development; please don't make
 him
 
 work harder by adding yet more complexity in repo maintenance!
 
 It's quite obvious that almost nobody on this list cares about
 adding complexity for Bram; it they did, they would not be
 insisting that he switch over to git rather than just moving the
 repo to BB and beind done with it.

I've followed this entire thread; Bram explicitly asked for feedback,
and showed his openness about switching to GitHub (and thereby Git);
he's even considering using pull requests (which I'm quite fond of; it
could streamline the current process of posting patches (and
occasionally updates to them)). He could have simply said Mercurial
is set, and GitHub would have been out.

I was referring to continuous overhead (like pruning the repo);
whereas switching version control systems is a one-time effort only.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFEdJAAoJEA7ziXlAzQ/vxq4H/1fh5hKDSRq6tSZqXloQIW/I
KiIVRFSdsREWR2I5clB1tNpqHcS5p9R7TX5+gZnh6bayLzI8iSNtPNS+X80HUaaY
BDkJJcq2mRPI2+f43MVPHTaS6IboSQ6Sm1mWlBEZpehMpyFmCLyKWDB6XWwZAdni
G9n3ufBm/hxNxO/tpmvUuxo/SbCYfJPIh1fVFv1ipZfobFSUI8W72wZDVbrMUTMp
sF5xajeo7uW3R8lv18iP+5mteI2NyV7cVa/y0KdmhCD6bhahL+UsUmPS00sY/5dB
Lf6LfSDTjcYFaS79WOJ7AemJZZlnIu98Fd0JJMbP9Qz9c0sDiw9eMiBXuZuRbwY=
=b7ra
-END PGP SIGNATURE-

-- 
-- 
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: Preparations for moving to github

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26-Mar-2015 14:32, Manuel Ortega wrote:
 It's smaller than Linux, therefore it's not too big?  It's far too
 big for the kind of thing it is.  It's a plain text editor; a user
 shouldn't have 50MB worth of useless things (much from *eleven*
 years ago) hanging around.

With the broadband connections that most of us now fortunately have,
50 MB is nothing. People stream / download entire HD movies all the
time. Java projects using Maven routinely download half of the
Internet to get to a build :-)

 Surely nobody needs 7.0 or 7.1 for bisection anymore.  7.3, OK.
 *Maybe* 7.2.  And anyway, bisection doesn't require that it all be
 in one repo (unless one believes the ability to hg bisect is a
 requirement of bisecting, which it is not).

I find the information when something was last changed very valuable.

 Bram can (and should) put older parts under github.com/vim/70 
 http://github.com/vim/70 and github.com/vim/71 
 http://github.com/vim/71, and then anyone who wants to go
 spelunking back in time can still do so.
 
 It's time to weigh the benefits of keeping ancient code in the main
 repo against the benefits of a small repo.  Keeping the *whole*
 history benefits a very small number of people on very rare
 occasions.  Making a smaller repo benefits everyone on nearly all
 occasions, and at most mildly inconveniences the very few people on
 those very rare occasions.

I'd argue the other way: Most people don't care about the full
download (which needs to be done only once on initial checkout). There
may be some poor fellows with poor connections; if you or some other
volunteer would like to provide lighter repo versions, just do so.
Bram already is a bottleneck in development; please don't make him
work harder by adding yet more complexity in repo maintenance!

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVFAzlAAoJEA7ziXlAzQ/voX0H/24Ep5qaSKLGaXYl1GV9cdG1
PB1a+YbT93NxKes/9SrLt/N2yChauyUliY76c69MHyT4wBCTQ7PFul0tT69mJJYr
YyB7d81Js0vzJbba8/3b6lzxWgXZwfdMZhY/evjLAONWOz9kDZYURSif0O4uWm1T
pfZBqm/IeJuWPO2zglfVtlt8cjoHxvXtJ63DI//TJUkFX6wXV9VqucAXEstvHhar
q3oXCxWqrx/t4P0ZBRWNKH/bQKX2gmYgefAPsrZBg9VWqV//PgViG0DAQLFr2iAW
48nDkSg4EUahbLyFmWbjLjKP0m69+xlbP97hi7fNO0VVIlMnakrhK0q7bB23qFo=
=dMfm
-END PGP SIGNATURE-

-- 
-- 
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: BUG: Unclosed regexp collection breaks :substitute

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-Mar-2015 10:08, 'Andy Wokula' via vim_dev wrote:
 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 ...).

Yeah, realistically, the bug would only be included as a low-prio item
on the todo list, and probably not addressed within this decade :-(
Maybe the neovim project will write a different parser and avoid the
problem. I'm a bit sad about this state of affairs, but on the other
hand, Vim is still incredibly useful (even with this minor bug), so
I'm fine with it.

 If you use [ unescaped, you should know what you are doing.

Agreed. That's why I'm mostly afraid of plugins breaking due the
inconsistency.

 Because: even with correct parsing, the pattern may still change,
 eg what if ] occurs in the replacement part: :s/[/x]/g

No, that's not an unclosed [ followed by ] in the replacement part,
but a correct collection of / and x. The delimiter doesn't have to
escaped inside a collection (didn't find that documented, but it's how
the implementation works).

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

Right. You can't use unescaped unclosed [ when there's a ] in the
replacement part.

 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
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVBeE/AAoJEA7ziXlAzQ/vwHQH/joTf1L31UjJy+GkBZ2LQ3/O
NgV5IgtNj6XYEx32sGgRfN4D98giOqHddIcDeBgWD7nWVgnk9h9DD0U9AcVKTjWi
ubQgk/Uuup9xM0Gg3Q5Jt9zsYJgQKiEtzkGfWQL5sXt0KLEBRqEkQ9u3R1ESvl8S
0QyAevIh29m7K9BIhGv12G

Re: BUG: Unclosed regexp collection breaks :substitute

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

 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
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVBIifAAoJEA7ziXlAzQ/v4TsH+gPD7aPCR98auBnAzamL97QB
kewrhUxGy/VtL3sNq8gfjhK/hHx3TyFT+hmcxEhsKHpHw5XT2WnBnagUVadZ1t6l
JD4yxcdxf2z7Rj5RL5Is4hSP/dCJseYydByZcACaPwdeZJ3YJQz1buRFNTjNF4MU
vf0DBaNi6VIULfaQl2QnWiH3p7B2qcp/qPRkuT7Zt6V9SRRBmUx/GfpRCKMW9BWg
89uHCPV77GqRU8EUawdzq3WnxMEb4PJMZiZVwcxLvm6eBqi8WpCIw9+W/oPWqj+3
j2nwXmOzUybc8rp+Y4zojSLsUuhl/Kr9BVG9xo6h9NN1Eq7uUoMzdS8iBJPC2gE=
=AmaI
-END PGP SIGNATURE-

-- 
-- 
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: BUG: Unclosed regexp collection breaks :substitute

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVA/McAAoJEA7ziXlAzQ/vzY8H/iDaGOuDaf37RwtzzjInRVWO
U3pWmVO5JGkJb+CZTBNRPBEZmL+5NewPooyAf0vmh+AimXJFl53AQbwoX0sdtr2S
x2BqT39WlsTh9DGlDA3TNGGy2buDGEwkjDSDhFckgTWB+6O52H4WcKtIo7IXZlE2
UPbRKrghxzIUGPeNqW0KC+om70TodkoklBIuGawJo8em0ZRkqPXWQM8GRXKUnkr2
q+raryMcoo3LN3aqURC1Xa9YCdmfvAj0JY3H0YQL7cTdX1fKIwcewcVT6SeY1zWl
gXt+FVmHqBGyYttjyf8YzAJqM9e73bq5KKmzRkAiTun4v3HsuktbvxeFG+dw1t4=
=SoRY
-END PGP SIGNATURE-

-- 
-- 
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: Unclosed regexp collection breaks :substitute

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

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

I guess the command parser doesn't backtrack when the closing ]
isn't found, and instead uses the remainder as the pattern (even
though the / separators aren't escaped and therefore are valid
separators).

Though this came up in a (wrongly typed) command [1], it's unlikely
that this problem occurs during interactive use. I'm more worried
about plugins automatically inserting the last search pattern into a
generated command and then failing unexpectedly, e.g.:

execute 'substitute/' . @/ . '//g'

- -- regards, ingo

[1] http://vi.stackexchange.com/questions/2538/regex-how-to-replace
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
Using Vim for 13 years now, mostly 'cos I can't figure out how to exit it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVA056AAoJEA7ziXlAzQ/vhIAH/ij6W9Iz3GnkG0ReeB9c8AVf
2ILB+V/YgIPNvKWR4GHgPgcsaAS7tMFDpYwi0RLuLBVGQAR31rlcqnmPUDYxj8ip
ZjUh0y5nkUUPOuW41YD2Njy6eY0GWAB0PO3NRxJRYChhHPV650vV3M/zav412N6N
Tv9/0hE4ItxTl1V0MW85T60vuUv6M5cFgyHV4H0GJ6FHPdCjt5x/vwKej1yki4fa
LMLti7p0auinbcHItWimjHdRnwKToaR2g1hny9D19k6N0jpDapRp6rA3mMLTMUWW
4+GX6+9ZYi1WEHzqdTAJwWX1lbJhm1DR2vA/NLT3/xm0opIkH3i5FEyYesQqBf8=
=mxIh
-END PGP SIGNATURE-

-- 
-- 
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: --remote-tab + 'noautocd' = cwd clobbering

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01-Mar-2015 15:32, xaizek wrote:
 I don't know a way to check whether window is using local cwd or 
 global one.

haslocaldir()
The result is a Number, which is 1 when the current
window has set a local path via :lcd, and 0 otherwise.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU828jAAoJEA7ziXlAzQ/vYLYIAIHqjDgNbOK1AR6azRF511+D
SyqCBG3nnw33kgyRBBTD/JikkBDDn3kMI8EX+tIepX2IgyNDbBTtzKSj2GPxbKm7
wNHs5FfFCvdFRk+QZfhBMB3dJoyfs5yJAZl0o9EIgGPisDpj2Ww+a8S4ibnYfDCz
8JMBQw0sepcLUfP6zf3gNU/MD1PkePg1wOeG4aDWcdJwmKCYVs+M37+APLNthKR0
QrnjJe3+nNB0EngahCR8xx8YGDpKS7CDjAQytinnfu+ryIR5T0XkBIdzsbjjZqWU
aNkZ5PgS5G7jn3Jo95OEO9YCPVM/QhqEiN4yq0pPRxntRLw8ecqdJfhK64Zf7TQ=
=dQp1
-END PGP SIGNATURE-

-- 
-- 
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: iterated remapping

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19-Feb-2015 23:55, Alexey wrote:
 Hello, i wonder if the following is a bug or a feature.
 
 If execute the commands
 
 :imap 2 3 :inoremap 13 42
 
 and type 12 in Insert mode, i get 13, but i would naïvely
 expect to get 42.

No, that's correct. When you type 1, Vim recognizes that the 13
mapping may apply, and waits for the next key. As this is 2, that
mapping doesn't apply. (The :imap doesn't get in between, and no
potential right-hand side has been produced yet; it's all still in
limbo.) There are no other candidates, so the 1 is cleared for use,
and only the current 2 is of concern. That one is mapped to 3,
yielding 13.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU5v8pAAoJEA7ziXlAzQ/v0iEH/35Nv+vLypfqD7sP5nM0vW2B
nE8QnUUwow+8HUQ+GKjA5FpE/esDGeoGMZE1oDhCpdGoB73RNPnXRSe1S/jODpIS
fsijLJ0s5wYbVtBECrON1jd6evNAa0nsHtcqKLm12ehdO3tyAeEIdASw0TM1p/4E
GHy8IshGMh81LWco/jMcUykHeZjQgn/sGuC0srl8GARzAKoRz5s04MFt1SXAXaAJ
ozWezB1rRnu4PjqQiIW69ImTKskM/d3rfG4pLdO4aQ4j0C9KzpzW/9McSdRWxf9e
OEsDjSBWyDL/7cTI29P8YLfVJZvnpq/wTerpGUU/EDKlgI3MRiJN/FDfhOPNEcE=
=gJKS
-END PGP SIGNATURE-

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

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11-Feb-2015 22:19, Bram Moolenaar wrote:
 
 Lilydjwg wrote:
 
 On Tue, Jan 27, 2015 at 11:26:39AM +0100, Bram Moolenaar wrote:
 
 Patch 7.4.592 Problem:When doing :e foobar when already
 editing foobar and 'buftype' is nofile the buffer is
 cleared. (Xavier de Gaye) Solution:   Do no clear the buffer. 
 Files:  src/ex_cmds.c
 
 This patch breaks netrw scp:// handling for me. I've tried
 several versions of vim (git bisect actually, then run src/vim
 without installing) with the same runtime and configuration
 files. Before this patch, vim scp://host/file works, but after
 this patch, vim is editing an empty buffer.
 
 Charles is aware of the problem but didn't have time yet to look
 into the reason.
 
 I'm starting to think that it's better to roll back this change. It
 was applied mainly for consistency.  Not breaking plugins is more 
 important.


Let's wait until Charles has analyzed the problem. If the resolution
is simple, and netrw is the only known trouble spot, we can just as
well keep it. Consistency is an important good!

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU3FssAAoJEA7ziXlAzQ/vZK8H/inSR5qIXtVdC+mSaMjn8727
eYnAo93k+nr83JWgzExwS9Z0SnGvJS6J66hD/MvAsRgsgMJh1hTOP9g26rxDKxLZ
506frWugd0Rs/+PVH3tSTbdglktB6VAe0CD9tA7xv8Lsny7KAetaqsXQ0+9tNVYS
vNdJhZuhvx5i+62jf/7XDDorXEs9k+7z36cIrCcKc87sP/KTdry/yIUs52WQDuCS
Or7nvKQzawE+N0Qldgw+33bi/s6n0TTytL5FkQE+fD5y9KEYG/TtVJdWwbxGAr/+
nLtSIMPcb6LV66y08rGwZq+djcNIq95ofYX8yZcEeqpQa0umsHFqpqdX3MVSt/g=
=Lw/+
-END PGP SIGNATURE-

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

[PATCH] Documentation typo fixes

[Ingo Karkat]

 strchars() function is still referenced 
in the todo list:

diff --git a/runtime/doc/todo.txt b/runtime/doc/todo.txt
- --- a/runtime/doc/todo.txt
+++ b/runtime/doc/todo.txt
@@ -2108,8 +2108,6 @@ 8   Add functions:
Search in 'runtimepath'?
More docs needed about how to use this.
How to get the messages into the .po files?
- -strchars()   Like strlen() and strwidth() but counting 
characters
- - instead of bytes.
 confirm()  add flags argument, with 'v' for vertical
layout and 'c' for console dialog. (Haegg)
Flemming Madsen has a patch for the 'c' flag

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJU2OE6AAoJEA7ziXlAzQ/vIK0IAIS1j4+TCrpRzqIDJMPTJHis
yYRf2d2aOg+r4HkdxnSb4eLWUUz3ats5yC8NuNGsTmsqwj4IHnrL3kBg3airyJtk
fZyzO+4znuN96VEdNzRDTlbjvE8MxPqPB6gx/JfwHVSBUnQuD3LuK6I82u2hchis
rbqjVRZk7/VwBPRvcdQhTR8cE+eq+7T0Kh6CZp52FhgkCr2j5euVxrtqt2sYYbWh
B18zOVpEQ0WX0L1Rh/ZVXRc3scFNi7YzzK+T/PYXcF7Trzq9UusOVJSGYLOtcNeB
aiKYYDkpGB0X8NOB54wfqtweiYCl2xYhEc0YPWiVKEpwz8f6R9mXdErhtAqT4YA=
=WCv2
-END PGP SIGNATURE-

-- 
-- 
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: BUG: /foo/,/bar/argdo proceeds after E14: Invalid address

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 29-Jan-2015 22:05, Marcin Szamotulski wrote:
 On 17:13 Thu 29 Jan , Ingo Karkat wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Hello Vim developers,
 
 the new range handling on :argdo (and :bufdo, :windo) proceeds
 even if a silly (and invalid) range is passed to it:
 
 $ vim -N -u NONE :args *.txt :/foo/,/bar/argdo echo bufnr('') 
 E14: Invalid address 2 INSTALLmac.txt 67 lines, 1942
 characters 3 INSTALLpc.txt 513 lines, 19434 characters 4 
 INSTALLvms.txt 393 lines, 12432 characters 5 INSTALLx.txt 165
 lines, 5354 characters 6 README.txt 143 lines, 5178 characters 
 7
 
 In contrast, :1,999argdo echo bufnr('') correctly aborts with 
 E16: Invalid range
 
 - -- regards, ingo
 
 The attached patch fixes this and also fixes a typo in a comment.
 
 Regards, Marcin

Thanks Marcin for that very quick response. However, your patch didn't
fix the given problem; two very similar other places need to set cmd
to NULL, too. Please see the attached, revised patch (still including
the fixed typo).

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEbBAEBAgAGBQJUy5ZVAAoJEA7ziXlAzQ/vTuEH+MnYWHVNoxtenyyq7H9wOipY
+urClwSca9BRfXBWVBocGsQwgu4hs8cwSjtxud7RUx0oMWbiFj+T4YX9DUOPmkit
DT7EAZ8JuYvy0xjniqT6q/cB0IPmfj8x5OdYadA/sT7qMRQ+xDia7YdN8p5DdfVl
Fw9pYxxyVxoPxltaga34Z3pyKeDMQyZ0FQwDCZCbhWfbe9b/6vIpyZKe6I333e3j
0CZUTfobRLm4yeipHpEMmIBovqsMxa/NkjUofb/zNQZ6N2IXdEUikjkpNnwcVLGa
6nDfEnHEPxTOI7VA9HD07Ah1E0aS+ZTE0swsYHzI/7yxXvbNhoMiaNs2MyrsLg==
=vag4
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/ex_docmd.c b/src/ex_docmd.c
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -4405,6 +4405,7 @@ get_address(ptr, addr_type, skip, to_oth
 		if (addr_type != ADDR_LINES)
 		{
 		EMSG(_(e_invaddr));
+		cmd = NULL;
 		goto error;
 		}
 		if (skip)
@@ -4436,6 +4437,7 @@ get_address(ptr, addr_type, skip, to_oth
 		if (addr_type != ADDR_LINES)
 		{
 		EMSG(_(e_invaddr));
+		cmd = NULL;
 		goto error;
 		}
 		if (skip)	/* skip /pat/ */
@@ -4484,6 +4486,7 @@ get_address(ptr, addr_type, skip, to_oth
 		if (addr_type != ADDR_LINES)
 		{
 		EMSG(_(e_invaddr));
+		cmd = NULL;
 		goto error;
 		}
 		if (*cmd == '')
@@ -4662,7 +4665,7 @@ invalid_range(eap)
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_ARGUMENTS:
-		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARCOUNT is 0
+		if (eap-line2  ARGCOUNT + (!ARGCOUNT))// add 1 if ARGCOUNT is 0
 		return (char_u *)_(e_invrange);
 		break;
 	case ADDR_BUFFERS:


get_address.patch.sig
Description: Binary data

BUG: /foo/,/bar/argdo proceeds after E14: Invalid address

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

the new range handling on :argdo (and :bufdo, :windo) proceeds even if
a silly (and invalid) range is passed to it:

$ vim -N -u NONE
:args *.txt
:/foo/,/bar/argdo echo bufnr('')
E14: Invalid address
2
INSTALLmac.txt 67 lines, 1942 characters
3
INSTALLpc.txt 513 lines, 19434 characters
4
INSTALLvms.txt 393 lines, 12432 characters
5
INSTALLx.txt 165 lines, 5354 characters
6
README.txt 143 lines, 5178 characters
7

In contrast,
:1,999argdo echo bufnr('')
correctly aborts with
E16: Invalid range

- -- regards, ingo

- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUylwwAAoJEA7ziXlAzQ/v4doH/0G46VMP8lwUoWFHKBAelwm5
4bP+0I3n6SoBkyvZVfj03om8SSkWE56rqCNxXQn98GwhafL50Js+P387AzTnob+K
DlYdaVG12xaAXHaAtv+JFQoZj0a4C3qUghl4kUJk2YjrWk2SmPxHtBWonXopRBrW
8Mgg1Qv9qGqy4QVKSJebqSwETsITISFbDOAUIEMJ3PZlu3OBPn9gjiHglwW7VSWU
nv2DpASxvvm1OTtuUZg9ecaPXbGj7Vle7ibtz60JmvDKE1xJirUegsoOmYFMU15K
4Y/FkPKfCxW77T0X+ULuc9d8/vjk+GQvRejxI0e1+2aiW+grmTIBno1RUkPwDYs=
=TFhn
-END PGP SIGNATURE-

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

[PATCH] Windows Regression: parsing of quoted command-line changed by patch 7.4.432

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

I use the easytags.vim plugin, which invokes another Vim instance, its
arguments properly escaped via shellescape(). On Windows, this doubles 
into . Starting with
,[ Patch 7.4.432 ]
| MS-Windows: setting 'encoding' does not convert arguments
`
this causes startup errors in the launched Vim instance, breaking the
plugin, and causing stray vim.exe processes to accumulate. (This is with
a HUGE Vim on Windows/x64, compiled with Windows SDK 7.1 / cl.exe
version 16.00.40219.01 for x64, if it matters.)

,[ how to reproduce ]
| vim.exe -N -u NONE -c let test = 'a quoted string'
| Error detected while processing command line:
| E115: Missing quote: 'a quoted
| E15: Invalid expression: 'a quoted
`

I know that shell quoting on Windows is a hairy mess, and after reading
some relevant articles ([1] and [2] are very detailed), I feel like I
understand _less_ how it is supposed to work :-(

Fact is, that patch changed the command-line parsing, but I don't know
how it could possibly affect the quoting behavior. What I did find out
is that _tripling_ (instead of doubling) fixes the problem for me. Some
experiments with findstr.exe also showed equal or better results with
tripling [3].

So attached is a workaround that changes shellescape() to triple instead
of double  on Windows. With that, easytags is working again (also when
it invokes an older Vim), and in a week of use, I didn't notice any
problems.
Of course, I'd prefer to have Vim's command-line parsing corrected so
that doubled  do work again. If some Windows guru (or Matsumoto-san as
the author of the original patch) achieves this, that'd be great!

- -- regards, ingo

[1] http://www.daviddeley.com/autohotkey/parameters/parameters.htm
[2]
http://stackoverflow.com/questions/4094699/how-does-the-windows-command-interpreter-cmd-exe-parse-scripts
[3]  echo.afooin here | findstr /L afoo
afooin here

 echo.afooin here | findstr /L afoo
afooin here

 echo.afooin here | findstr /L afooin

 echo.afooin here | findstr /L afooin
afooin here

 echo.afooin here|findstr /X /C:afooin here

 echo.afooin here|findstr /X /C:afooin here
FINDSTR: Cannot open here

 echo.afooin here|findstr /X /C:afooin here
afooin here

 echo.afooin here|findstr /X /C:afooin here
afooin here

 echo.afooin here|findstr /X /C:a\foo\in here
afooin here
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUuSvbAAoJEA7ziXlAzQ/v2iUIAI71K54IE9zHj/dswjTGzcIK
+Fwi5dtLsUzQIhDvZ9ksdQOVC+1rScRmNm3l9XyKEx0jvfAifaQdhtgGhWLajZ21
ZF86oBmBdm4WqwL+gcEq+8cJMRpD67WCns4FWiTyxN6x5qhuvNA2wIoOxt5/jfI4
YyUw2hdwgGUUyl/MeRCYLqeh8+IxjyAltRvAlCC3pB/lonAPzBtEBbQpoVRf9t97
REVN+wZIaAf0r5WCSArd1EfBkNbKaK17oR2fPtxH9YB6oagyyAOzQzaOXLcLou0i
I/OObKW+biMToW/oqJAdmnr3fwa/nprOWS2luZCn+A2VQikV5v8RBfPsXhskBNw=
=7rlR
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/misc2.c b/src/misc2.c
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -1392,7 +1392,7 @@ vim_strsave_shellescape(string, do_speci
 	if (!p_ssl)
 	{
 	if (*p == '')
-		++length;		/*  -  */
+		length = length + 2;		/*  -  */
 	}
 	else
 # endif
@@ -1435,6 +1435,7 @@ vim_strsave_shellescape(string, do_speci
 		{
 		*d++ = '';
 		*d++ = '';
+		*d++ = '';
 		++p;
 		continue;
 		}


shellescape-Windows.patch.sig
Description: Binary data

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

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 15-Jan-2015 12:24, mattn wrote:
 
 Well, I don't want plugin. I want builtin function.

Can you demonstrate that this is needed frequently? Which common tasks
would benefit from this? (And why would a short library function not
suffice?)

The only use case I've encountered so far is generating a list of
a..z, which I do this way: split('abcdefghijklmnopqrstuvwxyz', '\zs')

I think we have to trade convenience vs. complexity; Vim's codebase is
large enough. And the (already raised) issue of how to handle
multi-char strings isn't nice (char2nr() has this problem, too, but
that's a truly essential function).

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUt6+TAAoJEA7ziXlAzQ/v820H/3zMK84+Ekro4g18xIk3Clvb
6KP7p+1IytcpJOgqVPQXx4hOZLr+2pmQNrfUkb5imshWGUWCx+686hFQFYBFDN4P
Tx8LBsRm+BCp2oOKxRcp2T7vPiVQNfB9QsqGcsI6scNvRuV2xYtxlvV/aYRTI0Hn
WAkPhgA1E8IYigWDJKFLe/gsw7p9/GISjAdKlC1DLpyMyDluPxiYPvlacb19fqVZ
9rxQOh/1OYtyDQwKZyTV9rUETzHZPUeLzG/30mIgVryoOi15jwxdCKYwvLrpU6MC
teUqeug/iota//NcEYpZvVZL5R8kWAy5g1tdfqEs8kL9CDFarvmkxSRjLNyekiw=
=TgHo
-END PGP SIGNATURE-

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

Inconsistencies of CTRL-C

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

1. In normal mode, an unmapped CTRL-C Interrupt[s] current (search)
   command. And it prints the Type :quitEnter to exit Vim message.
   So when I
:nnoremap C-c Nop
   The message is indeed gone, but commands like :sleep 30 are still
   interrupted?! I would have expected such for :nnoremap C-c C-c,
   but not for mapping to Nop.

2. In insert mode :h i_CTRL-C mentions Does not trigger the InsertLeave
   autocommand event. But with
:autocmd InsertLeave * echomsg localtime()
:inoremap C-c C-c
   I observe the event being fired.

Background of this is that with the fixes in 7.4.569, one actually has
to :map C-c C-c (i.e. to itself) in order to use mappings that
_include_ C-c in the {lhs}. (Otherwise, as :h CTRL-W_CTRL-C rightfully
notes, the mapping would be aborted.) But I would like to keep the
original interrupting of C-c intact (in all modes).

In summary, I see the following two inconsistencies as (minor) bugs:

1. With :nnoremap C-c Nop, normal mode commands like 20gs and slow
   searches should _not_ abort. But any mapping _to_ a {rhs} of C-c
   should abort (which it currently doesn't). I'm not sure how useful
   that would be, and it looks difficult to implement (as the CTRL-C
   handling is lower-level than the mapping layer, right?)

2. With :inoremap C-c C-c, the InsertLeave event should _not_ be
   fired. Could be just a simple condition that's missing there.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUtorEAAoJEA7ziXlAzQ/vLJYH/jGj7Mvbc/j6IHkWQszF35O1
syKvzikuA/NwsIpfHpbA1tcvoNff3Mji05jFxdPo/siH/JJZECya/vcXMj2cFYyR
ouRnP6WN1fZ309FSsWnAahC5MLncxNUdANxVATWHQUbB948JYIklt34B8TPxCzEB
8OrQbIBRCtX0NoltyZlLTSLrpC1Ika3U8pQypHhNTpm2BKbuU/fANWEnYMfhawxJ
IZ06S+RWMoiH3R+64CJ0NFnBXIZBXMQ2JDOjE7wkSuvAPxoc6C/5+tmCq9ALOYFW
6+vTVAQ82Ps9NL+n1NFHGJI5hvdE3WJLs610ppZo1ODnyqkd48S9s4w6QKM/z4M=
=HsdX
-END PGP SIGNATURE-

-- 
-- 
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.569 breaks vmap C-C

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14-Jan-2015 16:07, Bram Moolenaar wrote:
 
 The problem is with using State directly, should use
 get_real_state().
 
 I added a test, but it also passes without the fix.  Same problem
 that it works when using :normal or feedkeys().

Thanks, I can confirm that it's working now!

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUtpLUAAoJEA7ziXlAzQ/vSfkH/i3GZdncs2R0WJCW2LcUyGhM
OU7oC6vJJsOPgJSAU55jt/wPpjOL9wLGQuhdsGQjwBf0c6kCyhH9cP1Snt2n4N9V
5rtzxoga/7Dc/WkuAUN7OHOfYRvyww8NgFAtb19Hlway4fPPZjssym/Teoir1MRh
eWveK0LK3wDGuG2QisL8rj3LBR5vLkWtEeHPwiq7cfZVLvhDuuVMhXzIzOhnfZqM
nXXnbt5WbGUlNgBx1wb5fyLMH37x7CQbXn33DlsQmQBaNZXyCpX013s8HC5RGlIl
nQbCATttvzrxLBQFzUWv5Dx191rp707ZREHRczEcUo7yjmiCGTwIiUHJRRmPV8s=
=lnbE
-END PGP SIGNATURE-

-- 
-- 
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.569 breaks vmap C-C

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

First, thanks for fixing this issue with unmapping CTRL-C, Bram and
Christian! Unfortunately, after patch 7.4.569, I cannot map C-C in
visual or select mode any more. (I have mapped this to copy to
clipboard, similar to what's in mswin.vim.)

Steps to reproduce:

$ vim -N -u NONE
:vnoremap C-c :C-uquit!CR
:echo Press V CTRL-C now
 (stays inside Vim)

Interestingly, :normal or feedkeys() still work:

:execute normal V\C-c
 (quits as expected)

This happens with a HUGE Vim build, on both Windows/x64 and Linux/x64.
Other modes work fine, only :vmap, :xmap, and :smap are affected.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUtnm3AAoJEA7ziXlAzQ/vYvUH/3tE3jnFXvIq2ZFlmWjvcbo0
OYRn8sLQbOSHb2W7qOc8Q8A+U51ff1eruTZJbcCBabbLxNwUATgbELjicE8rQwOe
kKabat4Vxuakx+g/Qpt2+A9B8N5EYa6wgMT8d+mcDbLuBUboxgfyN32gWJvphdKQ
I2dLzgQxCn42Y1tXuJSm89dzWnokqnn7xGP7ck8M4W6kbvNhaNaE/0LotWbxs4FV
naYgXcGb2vRe+EyD6UboZ9X5SctvajYb3GO2+NjlI/NeoBNSS48Ow/yhq+whfxZ3
ic7UjfoOeiqFrAwYr/ibUBpbaw7al2qYZ8781fDPOJMKjpEhahdRc3ZqCMaXYNA=
=9Pfp
-END PGP SIGNATURE-

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

Segfault on widescreen GVIM with error in 'rulerformat'

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

my 'rulerformat' called a function that had been renamed, and didn't
exist any more. Because I was using :silent!, I never noticed, and it
took me a long time to figure out that this was causing crashes on
GVIM when it got maximized (or when the horizontal size got increased
to about the width of my monitor, e.g. via :set columns=999).

Here's a minimal scriptlet (also attached) to reproduce the segfault:

:set ruler rulerformat=%75(%{DoesNotExist()}%)
:set columns=999 If you have a small monitor, decrease font
size, too.

I see this in the latest GVIM 7.4.560 on Windows/x64 as well as in all
official Windows/x86 builds of GVIM down to version 7.0. The problem
also appears on Ubuntu 14.04 Linux/x64, Vim 7.4.560:

$ gvim -N -u NONE -S /host/segfault-widescreen-rulerformat.vim
$ Vim: Caught deadly signal SEGV
E138: Can't write viminfo file $HOME/.viminfo!Vim: Finished.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUqm9dAAoJEA7ziXlAzQ/vNEsH/22p+ajbhwt0po7yuM470O93
y1WAsZo/j2MnWYstAh7lYU8Rfnst+b/nRZkhDsSnCpLl5j97um8OVdGZCUpn9HVg
FpXVV2ByXmZWI6H4zfbecymKwlMbFpBcOkQ+aECYfdCPRg2zVHxVo/kI7xrAwHRg
p3r2hrJ6qiDbYdk/fz6IOXgVoiZlI1Q9rmxVMxCH4okx6o3BtisPvXbdtQsfxRlc
+GNZH2hpt1NhUD/k2NtorveALIcCIRjc0atTnpMmEktIaVGkU8S6MxFz2b8/WNSe
xt7mp8frM/grXgRNiobOK9KIhNyEzreGT47nFi/KLp1TlMe82p2K9aYrtCouOFk=
=gWcS
-END PGP SIGNATURE-

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


segfault-widescreen-rulerformat.vim
Description: application/octetstream


segfault-widescreen-rulerformat.vim.sig
Description: Binary data

[PATCH] Re: Regression: glob('dir/*/') also returns plain files with appended path separator, not just directories on Windows.

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 22-May-2014 13:32, Bram Moolenaar wrote:
 
 Ingo Karkat wrote:
 
 Hello Vim developers,
 
 I just noticed a regression when using a custom command's
 complete function that is file-based. When I do :echo
 glob('dir/*/'), I expect the result to only include directories,
 because of the trailing / path separator (same when using \
 btw.), but in recent Windows builds, it also includes *all
 files*. For example, from the Vim repository root dir, I get:
 
 ,[ bad ] | src\arabic.c\ | src\arabic.h\ | src\ascii.h\ |
 src\auto\ | src\bigvim.bat\ | ... `
 
 instead of
 
 ,[ good ] | src\auto\ | ... `
 
 With this command:
 
 src\vim.exe -N -u NONE -c if len(glob('src/*/',0,1))  20 |
 cquit | else | quit | endif
 
 I've bisected this problem to the following patch:
 
 ,[ bad change ] | 7.3.1182  'backupcopy' default on
 MS-Windows does not work for links `
 
 I still see this in the latest 7.4.295 (HUGE build, using
 Make_mvc.mak with the Windows SDK 7.1 compiler) on Windows/x64.
 No problems on Linux.
 
 Can you do some debugging to find out what part of that patch
 causes this?  Perhaps one of the ways to expand a file name removes
 the trailing slash?  Considering the output above, it looks like
 the slash is added back afterwards, also after normal files.

I've finally found the problem and a possible fix. The root cause is
that patch 7.3.1182 replaces the implementation of mch_getperm() in
os_win32.c that uses the native GetFileAttributes() with a call to
mch_stat(). That one (in vim_stat() from os_mswin.c) is documented to
remove a trailing path separator. dos_expandpath() just checks for a
successful stat() call, so it now accepts files just as well as
directories.

When reverting mch_getperm() to the previous implementation, the
problem is gone, but I guess the change was done for a reason :-)
While attempting to add filtering for actual directories, I happened
upon a related comment On Solaris stat() accepts file/ as if it was
file. in macros.h, and it appeared to me that applying the
illegal_slash() function (adapted for Windows by also checking for a
backslash) to the mch_stat() macro is the correct solution.

Attached is a patch and a test for the problem.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUmEK+AAoJEA7ziXlAzQ/vyZoH/iwBFvwCMHGD+xWvppCTT/Se
UaDBTYUQtmjFK3rIG/Dhw10YosBbMpw3RDzb/QZplPPn4DNIKBzlBgSdejbT5Iv4
tz9nwSe4irr6RCB1zlLJ4zMx0P4E84MAonoIAYUPgcWww6KbZk/PNOxEFVYbws89
Dn/4KB9H6GfSGN80SNg63y2xvxkCBpIMY72LEoYsINfeU9HJyLC3efGXLGfjB6Fc
q3Su/hR4DDZ0eWKqjON3p0P1GdifPiX21sNf9pgJOD46TQngtRcDJYY2yzzH1OZM
Vg6ei/NT0qMIK0tJiHsExuUHnb8D1Rtfleovc9gJynqYnw9OdTJZy6ro6mT0K5Y=
=jSNK
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/macros.h b/src/macros.h
--- a/src/macros.h
+++ b/src/macros.h
@@ -188,7 +188,9 @@
 # endif
 # define mch_fstat(n, p)	fstat((n), (p))
 # ifdef MSWIN	/* has it's own mch_stat() function */
-#  define mch_stat(n, p)	vim_stat((n), (p))
+/* The Windows vim_stat() accepts file/ as if it was file.  Return -1 if
+ * the name ends in / and it's not a directory. */
+#  define mch_stat(n, p)	(illegal_slash(n) ? -1 : vim_stat((n), (p)))
 # else
 #  ifdef STAT_IGNORES_SLASH
 /* On Solaris stat() accepts file/ as if it was file.  Return -1 if
diff --git a/src/misc2.c b/src/misc2.c
--- a/src/misc2.c
+++ b/src/misc2.c
@@ -3367,7 +3367,7 @@ vim_chdirfile(fname)
 }
 #endif
 
-#if defined(STAT_IGNORES_SLASH) || defined(PROTO)
+#if defined(STAT_IGNORES_SLASH) || defined(MSWIN) || defined(PROTO)
 /*
  * Check if name ends in a slash and is not a directory.
  * Used for systems where stat() ignores a trailing slash on a file name.
@@ -3379,7 +3379,11 @@ illegal_slash(name)
 {
 if (name[0] == NUL)
 	return FALSE;	/* no file name is not illegal */
+#if defined(MSWIN)
+if (name[strlen(name) - 1] != '/'  name[strlen(name) - 1] != '\\')
+#else
 if (name[strlen(name) - 1] != '/')
+#endif
 	return FALSE;	/* no trailing slash */
 if (mch_isdir((char_u *)name))
 	return FALSE;	/* trailing slash for a directory */
diff --git a/src/Makefile b/src/Makefile
--- a/src/Makefile
+++ b/src/Makefile
@@ -1898,6 +1898,7 @@ test1 \
 	test_close_count \
 	test_command_count \
 	test_eval \
+	test_glob_directories \
 	test_insertcount

Re: Find Bugs

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19-Dec-2014 08:07, Antonio Giovanni Colombo wrote:
 Hi Guilherme, have a look from inside a Vim session at:
 
 :help todo
 
 There is plenty of stuff listed there.

I also welcome your willingness to fix some bugs (and there's plenty
of them), thanks!

You'll find a more up-to-date version of the todo list at

https://vim.googlecode.com/hg/runtime/doc/todo.txt

or, once you've pulled the Mercurial repository containing Vim's
source code, in runtime/doc/todo.txt.

In addition, there's also an issues list at Vim's Google Code project:

https://code.google.com/p/vim/issues/list

Don't be afraid to post your patches and questions here, and again
thanks for your help!

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUk+oWAAoJEA7ziXlAzQ/vm/AH/jsxYqlvEahTTu/sPDZ1NSCQ
hK/wHkAYEtcucZlQQ6mzubzSZKkJNQ+91FT5gTQwlEQr27wiXumTEzPnutWgFNyq
YH3ajLHAG1kUwgXBAeIbJWMnhCnFGnftVfqZsyathu2uYpsdfHJbBs4rzQAfL+c2
NFQ6n8X6AyhPHHI9cqi5KZ9ftpGzJe6MxrFVURChzEW4yxZWrf+H1JKWOdmXlaSt
4aaglyp8DSkcR/YbEw/+IdyII8KxTPGshyXJwuq1fzzzSLYrTCwynRAogcvo3fot
3vkjTenDTtZ5x/w1MXKxT6lLHhbpZW670awOPSdxlY2BeY74l64cdageJq5y7VE=
=o1Ey
-END PGP SIGNATURE-

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

[PATCH] On Windows, GVIM's window size increases when changing menus while minimized

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

this has been bugging me for a long time; I finally found the root
cause. I use --remote {file} to open a file in an existing GVIM
instance. When that instance had been minimized (:suspend), GVIM would
come up with 'lines' increased by two when put to the foreground again.
So, the vertical window size of GVIM would grow with each file opened!

I found out that this is caused by plugins like MruMenu and the built-in
Buffers menu, which hook into BufNew / BufRead and then re-build their
menu. It can be reproduced via the following command sequence:

gvim -N -u NONE -c echomsg 'before:' lines -c suspend
gvim -N -u NONE --server GVIM --remote-send
:an testing.foo ltNopCR
gvim -N -u NONE --server GVIM --remote-send
:call foreground()Barechomsg 'after:' linesBarmessagesCR


When a top-level menu item is affected, Vim invokes
gui_mswin_get_menu_height(); when GVIM is minimized, the Win32 functions
cannot determine the current menu height, which bases the following
resizing on wrong sizes, and that increases the window height.

Attached patch adds a condition for minimized Vim and returns the
(already saved) previous menu height in that case. With that, the
problem is gone.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUlC9KAAoJEA7ziXlAzQ/vaMkH/2MsWE96R3TIXsJ3rR5r6Qs0
PMksdBxkc2MOlkKkz3pPvLBFNV+Y9jdi4E0wrUR2zap17Ltzw//xcCrURXyzCg3i
7tVW2RqDUg3Xhs9E9A8THRmE68yp/38M+s8nqopxefcWHn9+SwnL39gmjpmOEoWc
ryeVN938lH7OXLK/fKmOE3l2IM0elQDHNLc3aHKz3VIapR8ZzAwoJq0NzHKeoMdZ
jvVHp2f+HWK7ln4HsPqkYk/gplh2n15JYfAlZM3YwPABy6i90UNS3umG669ltDN4
Djb1acH5low07MSC38uubNR0uNELJsk2oVGVf+cwYr1aFApywuOn6mCybGyGZGQ=
=f6l6
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/gui_w32.c b/src/gui_w32.c
--- a/src/gui_w32.c
+++ b/src/gui_w32.c
@@ -598,6 +598,16 @@ gui_mswin_get_menu_height(
 
 if (num == 0)
 	menu_height = 0;
+else if (IsMinimized(s_hwnd))
+{
+	/*
+	 * The height of the menu cannot be determined while the window is
+	 * minimized.  Take the previous height if the menu is changed in that
+	 * state, to avoid that Vim's vertical window size accidentally
+	 * increases due to the unaccounted-for menu height.
+	 */
+	menu_height = old_menu_height == -1 ? 0 : old_menu_height;
+}
 else
 {
 	if (is_winnt_3())	/* for NT 3.xx */
@@ -644,9 +654,9 @@ gui_mswin_get_menu_height(
 
 if (fix_window  menu_height != old_menu_height)
 {
-	old_menu_height = menu_height;
 	gui_set_shellsize(FALSE, FALSE, RESIZE_VERT);
 }
+old_menu_height = menu_height;
 
 return menu_height;
 }


bug-lines-increased-amenu-minimized.patch.sig
Description: Binary data

[PATCH] :0argedit doesn't prepend like :0argadd does

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

:0argedit foo should insert a first argument like :0argadd foo does, but
it actually puts the argument *after* the first one, at position 2.

,[ :help :argedit ]
| [count] is used like with |:argadd|.
`

Attached patch fixes that, and adds a test for this.

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUlEH3AAoJEA7ziXlAzQ/vr8YH/Rp2/saQynpUTYI4YQY3nQnV
NvxtI4M1wWZHKAgbTPWGPvZtydNwJWo/8wG2iZ6lh3Hzz769OyZPndLqy+bqm8Ws
pb8GrucGcjEp7dCR/fBvW76xowkPtaIDw6NUkeugWWlrkJYQQft6OQU3pkfvjxu8
hTbE/RiDRGJuBfxCaU0/w42dX/kRQ4CeD6fquUWXNKFLFGaY/AsqIx/fvV6LpacI
Js1tNqtm0n5UNEsqrHbd+pJUdg7h5CSeRlynqnZwETYvqzgWoCeRzl8V5THOgGFZ
KWLYez1JsdtRep53zLRyKDGx64mrPFwbBMcy+ixvwL1c5Nnj9MghdjbxuSfwtwQ=
=Yuvq
-END PGP SIGNATURE-

-- 
-- 
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 --git a/src/ex_cmds.h b/src/ex_cmds.h
--- a/src/ex_cmds.h
+++ b/src/ex_cmds.h
@@ -136,7 +136,7 @@ EX(CMD_argdo,		argdo,	ex_listdo,
 			BANG|NEEDARG|EXTRA|NOTRLCOM,
 			ADDR_LINES),
 EX(CMD_argedit,		argedit,	ex_argedit,
-			BANG|NEEDARG|RANGE|NOTADR|FILE1|EDITCMD|ARGOPT|TRLBAR,
+			BANG|NEEDARG|RANGE|NOTADR|ZEROR|FILE1|EDITCMD|ARGOPT|TRLBAR,
 			ADDR_ARGUMENTS),
 EX(CMD_argglobal,	argglobal,	ex_args,
 			BANG|FILES|EDITCMD|ARGOPT|TRLBAR,
diff --git a/src/Makefile b/src/Makefile
--- a/src/Makefile
+++ b/src/Makefile
@@ -1891,6 +1891,7 @@ unittest unittests: $(UNITTEST_TARGETS)
 
 # Run individual test, assuming that Vim was already compiled.
 test1 \
+	test_argument_0count \
 	test_argument_count \
 	test_autoformat_join \
 	test_breakindent \
diff --git a/src/testdir/Make_amiga.mak b/src/testdir/Make_amiga.mak
--- a/src/testdir/Make_amiga.mak
+++ b/src/testdir/Make_amiga.mak
@@ -36,6 +36,7 @@ SCRIPTS = test1.out test3.out test4.out 
 		test94.out test95.out test96.out test97.out test98.out \
 		test99.out test100.out test101.out test102.out test103.out \
 		test104.out test105.out test106.out test107.out \
+		test_argument_0count.out \
 		test_argument_count.out \
 		test_autoformat_join.out \
 		test_breakindent.out \
@@ -175,6 +176,7 @@ test104.out: test104.in
 test105.out: test105.in
 test106.out: test106.in
 test107.out: test107.in
+test_argument_0count.out: test_argument_0count.in
 test_argument_count.out: test_argument_count.in
 test_autoformat_join.out: test_autoformat_join.in
 test_breakindent.out: test_breakindent.in
diff --git a/src/testdir/Make_dos.mak b/src/testdir/Make_dos.mak
--- a/src/testdir/Make_dos.mak
+++ b/src/testdir/Make_dos.mak
@@ -35,6 +35,7 @@ SCRIPTS =	test3.out test4.out test5.out 
 		test94.out test95.out test96.out test98.out test99.out \
 		test100.out test101.out test102.out test103.out test104.out \
 		test105.out test106.out  test107.out\
+		test_argument_0count.out \
 		test_argument_count.out \
 		test_autoformat_join.out \
 		test_breakindent.out \
diff --git a/src/testdir/Make_ming.mak b/src/testdir/Make_ming.mak
--- a/src/testdir/Make_ming.mak
+++ b/src/testdir/Make_ming.mak
@@ -57,6 +57,7 @@ SCRIPTS =	test3.out test4.out test5.out 
 		test94.out test95.out test96.out test98.out test99.out \
 		test100.out test101.out test102.out test103.out test104.out \
 		test105.out test106.out test107.out \
+		test_argument_0count.out \
 		test_argument_count.out \
 		test_autoformat_join.out \
 		test_breakindent.out \
diff --git a/src/testdir/Make_os2.mak b/src/testdir/Make_os2.mak
--- a/src/testdir/Make_os2.mak
+++ b/src/testdir/Make_os2.mak
@@ -37,6 +37,7 @@ SCRIPTS = test1.out test3.out test4.out 
 		test94.out test95.out test96.out test98.out test99.out \
 		test100.out test101.out test102.out test103.out test104.out \
 		test105.out test106.out test107.out \
+		test_argument_0count.out \
 		test_argument_count.out \
 		test_autoformat_join.out \
 		test_breakindent.out \
diff --git a/src/testdir/Make_vms.mms b/src/testdir/Make_vms.mms
--- a/src/testdir/Make_vms.mms
+++ b/src/testdir/Make_vms.mms
@@ -96,6 +96,7 @@ SCRIPT = test1.out  test2.out  test3.out
 	 test95.out test96.out test98.out test99.out \
 	 test100.out test101.out test103.out test104.out \
 	 test105.out test106.out test107.out \
+	 test_argument_0count.out \
 	 test_argument_count.out \
 	 test_autoformat_join.out \
 	 test_breakindent.out \
diff --git a/src/testdir/Makefile b/src/testdir/Makefile
--- a/src/testdir/Makefile
+++ b/src/testdir/Makefile
@@ -33,6 +33,7

Re: noautochdir plus --remote-silent

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 16-Dec-2014 14:30, Axel Bender wrote:
 Using autochdir in .vimrc together with the --remote-silent start
 option works fine: the first edited file's path is set correctly. 
 However, the manuals suggest not to use autochdir:
 
 This option is provided for backward compatibility with the Vim
 released with Sun ONE Studio 4 Enterprise Edition. Note: When this
 option is on some plugins may not work.

I think you interpret this a little bit too harsh. I use 100+ plugins,
and (now; I had to submit patches to very few) they work just fine
with :set autochdir.

 In order to avoid using autochdir I tried (a.o.) the following in
 .vimrc:
 
 set noautochdir autocmd BufEnter * lcd %:p:h

That simplistic implementation may cause errors when the path to a
(newly created) file does not exist yet (when adding BufNew, see
below), or when you use the netrw plugin to edit buffer names like
http://www.vim.org/. All of that can be handled, but I'd recommend to
rather give 'autochdir' another try.

 which works for all but the first file. Which event[s] do I have to
 use to make this work?

BufEnter should work. I'd add BufNew to handle new files and file
renames, too. Does this depend on --remote-silent? If so, what's the
full command to reproduce?

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUkFSNAAoJEA7ziXlAzQ/va18IAIx4sJDdeyuECmUkQiPPopME
HsTx0gca7wG3Sz0fpRBtNf28/Shf2nZcC750t9J3+JndPSUmY1tyKNqj44KR01Dl
7V1F3xt44X8VjD/07zftmN2kxYyAN621xpS7o3z3dqoRxhSy3cNA5hvd2utpKz1V
fYxGB8hJJ/x7QHvtivQ4beiSUsp2xMxQOVDCSqIZg046/Iawu0y/NAcIv50LOQy9
L8vI5IS7Qa+HVxl4/e5Xwvq/DfIppIrWBMAwbaDrL2+YkHpApGEbNTtJHiTU5Iir
MsWXpS9vBNL+ZDy5VCDxkAUIBV5d13zplIXchz0HXxwpRsZCAgR2N7a19BcX9HA=
=yKIc
-END PGP SIGNATURE-

-- 
-- 
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: CTRL-C mapping ignored after 7.4.468

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 13-Dec-2014 14:37, Christian Brabandt wrote:
 Hi Ingo! On Fr, 12 Dez 2014, Ingo Karkat wrote:
 
 Hello Vim developers,
 
 patch 7.4.468 (BTW it doesn't appear in the list on 
 ftp://ftp.vim.org/vol/2/vim/patches/7.4/README) addressed
 
 Issue 26: CTRL-C does not interrupt after it was mapped and
 then unmapped
 
 However, it apparently fails to consider the mapping _modes_ of 
 CTRL-C, so when I have such insert mode mapping, then do :cmap
 C-c ... | cunmap C-c, the insert mode mapping (though it
 still is listed by :imap) becomes ineffective! (Same for other
 mode combinations.) I have various mappings that include the
 C-c key (have I mentioned I'm running out of keys?), and all of
 these get broken because one of my plugins temporarily sets up a
 :cmap C-c.
 
 
 I've used the following scriptlet to bisect the problem:
 
 nnoremap C-c :quit!CR nnoremap C-x :cquit!CR cnoremap
 C-c dummy cunmap C-c echomsg Press C-cC-x now
 
 Interestingly, it requires actual typed keys, even :call 
 feedkeys(\C-c, 't') doesn't work.
 
 I can reproduce this both on Windows/x64 and Linux/x64, up to
 the current Vim 7.4.542.
 
 Christian (as the author of the original patch), I hope you'll be
 able to get a fix for that!
 
 The fix is easy. Simply increment the mapped_ctrl_c flag when
 mapping CTRL-C and decrement it when unmapping. Then Ctrl-C will
 work as interrupt only, when ctrl-c is never mapped.

Thank you Christian! Doesn't this have to consider the current mode?
So when I have an :imap C-c, that mapping is used in insert mode,
but when I press C-c in normal mode (or any other), it interrupts.
Also, I wonder whether this increment / decrement is robust when using
:map buffer C-c; the applicability is then dependent on the
current buffer, and one usually don't :unmap buffer, but just
discards the buffer.

Nonetheless, I think your patch is an improvement and allows to use my
mentioned plugins without any issue. I'll try it out on Monday and
report back any issue.

 diff --git a/src/getchar.c b/src/getchar.c --- a/src/getchar.c +++
 b/src/getchar.c @@ -3707,9 +3707,9 @@ do_map(maptype, arg, mode,
 abbrev) { if (!did_it) retval = 2; /* no match
 */ -   else if (*keys == Ctrl_C) +   else if (*keys ==
 Ctrl_C  mapped_ctrl_c) /* If CTRL-C has been unmapped, reuse it
 for Interrupting. */ -   mapped_ctrl_c = FALSE; +
 mapped_ctrl_c--; goto theend; }
 
 @@ -3744,7 +3744,7 @@ do_map(maptype, arg, mode, abbrev)
 
 /* If CTRL-C has been mapped, don't always use it for Interrupting.
 */ if (*keys == Ctrl_C) -   mapped_ctrl_c = TRUE; +
 mapped_ctrl_c++;
 
 mp-m_keys = vim_strsave(keys); mp-m_str = vim_strsave(rhs);
 
 
 For some reason, I can't come up with a test. Seems like ctrl-c is
  somehow special and whatever I do, it doesn't work as expected, so
 I leave this part out.

Yeah, that's probably why my scriptlet needed explicit user input,
too. I also couldn't reproduce the issue with :call feedkeys(\C-c,
't') somehow.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUjE94AAoJEA7ziXlAzQ/vQfoIAI8AOEYlMGK/237JjjUNTiU7
2XAQ+aEs8LpLz4f+bETwpfMtLa1hcaFwPHkEMJCXvhaYyWFZZghhNUG9OP0LGEAJ
5lRTz/JLKedpN2Itguizv2wOnRJ1s67vCWpQ/2VGMqc313dH/ewOFCuh7+NaNisE
Ih0qHGCtDPOZu0NnWArjKuax1H44JnMdVcdtxC06B73aPMFGfV6XwE3yVBDg2Xg8
mq+Ku/TeHAM6NvpOa3mhEUUasAr1vatYgswOOuMiDvLeUNBoXADBl9PyB1Rmticu
qoiYnIKFuLRjxV0EPdWpskoMBcZ2lcrpfauT7K9esXjdMB6f5KmtWNNZ60jm9ow=
=aoNI
-END PGP SIGNATURE-

-- 
-- 
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: CTRL-C mapping ignored after 7.4.468

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Vim developers,

patch 7.4.468 (BTW it doesn't appear in the list on
ftp://ftp.vim.org/vol/2/vim/patches/7.4/README) addressed

 Issue 26: CTRL-C does not interrupt after it was mapped and then 
 unmapped

However, it apparently fails to consider the mapping _modes_ of
CTRL-C, so when I have such insert mode mapping, then do :cmap C-c
... | cunmap C-c, the insert mode mapping (though it still is listed
by :imap) becomes ineffective! (Same for other mode combinations.) I
have various mappings that include the C-c key (have I mentioned I'm
running out of keys?), and all of these get broken because one of my
plugins temporarily sets up a :cmap C-c.


I've used the following scriptlet to bisect the problem:

nnoremap C-c :quit!CR
nnoremap C-x :cquit!CR
cnoremap C-c dummy
cunmap C-c
echomsg Press C-cC-x now

Interestingly, it requires actual typed keys, even :call
feedkeys(\C-c, 't') doesn't work.

I can reproduce this both on Windows/x64 and Linux/x64, up to the
current Vim 7.4.542.

Christian (as the author of the original patch), I hope you'll be able
to get a fix for that!

- -- regards, ingo
- -- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUiwmeAAoJEA7ziXlAzQ/vza8H/RS2xVIbOJuspyKGoLU3ZrR1
h/KWBUFuPs5vrp20EA5Ja6oQ+VesevcJ721bILWFqcimv6ZyxyRGe3F7boj5Inv5
zdfofLr80IASgGY3/+HDhqi+XH0VMBYy0HDa7EluZvkin1VXPqCrnnAbZXydobLC
oCQsoVf2s9ntIpa+XBpCLH4EBdsD2d9c0SKuLhd3yPbVhC0/t1wUcFRTILlsKR4J
IRzIpcXCAth/7HxoScbxX4sQL/yxTP5batDINiZWSHm3FFPDHj+wHz+pNNg1tkrc
RrMaaTf113XXQrDHM8MT/IVd838KbUteezrFWi4FLIX8U/PU2bm5RJ6aS+Qd5H0=
=wELI
-END PGP SIGNATURE-

-- 
-- 
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-ctrl-c.vim
Description: application/octetstream

Re: Unsilently sourcing a file, but ignore E122, E174, E227 etc

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 20-Nov-2014 15:03, Daniel Hahler wrote:
 Is it possible to source a file (without using `:silent!`), but
 ignore any of the following errors: - E122: Function Foo already
 exists, add ! to replace it - E174: Command already exists: add !
 to replace it - E227: mapping already exists for ...
 
 Using silent! also suppresses any output.
 
 I've tried to remove the silent! by using a try/catch block, but
 that aborts the sourcing -
 https://github.com/Shougo/neobundle.vim/pull/342/files (the
 revert).
 
 `:source!` (with a bang) has a different meaning already, and it
 would be nice to use an already existing mechanism.


I think the answer is already contained in your title: That's what the
:unsilent command was created for.

:silent! unsilent source {file}

This suppresses the mentioned errors (tested with E122), but keeps any
:echo output visible.

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUbf6/AAoJEA7ziXlAzQ/vId8H+wVS+4YEDomyyNZSdfbhaAMp
HY683DRyaXRvcEC21vvVdxmIVF3lPlOv0G2Ib4SjHrHrHGcdo7RG+mal+I1NtOpg
DErcUFnjmIijRvYYtUyauGBuJSBMhaCq3kjIxjicGhCEuwSj9Zxl0WLGBFt6GWB2
Lf6uArNIh//EElBZ3QE94wMPO5pfaJtwS4vl68goJyfIzXa4dev1V1TBrfV2taxG
DitcIJMZx0hNjjbdKOkiUR9dkTeyVyrK7A955BNWKVihpVEe4hEHPJbye1DPJzla
E/998YDCfWEL2tx+N8U5tnBcn2g0/xa8s4QJbFpj7VwYpVTd/Y1bcB0ON92be+E=
=/ORM
-END PGP SIGNATURE-

-- 
-- 
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: Put ~ markers into their own highlight group

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31-Oct-2014 13:03 +0100, Bram Moolenaar wrote:

 Marco Hinz wrote:
 
 this might be yet another controversial patch, but it's asked for
 on IRC all the time.
 
 The problem is that the ~ markers (end of buffer) and parts of 
 'listchars' both use the same highlight group: NonText.
 
 Now people wish to use different colors for this, thus this
 patch introduces a new highlight group, EndOfBuffer, which uses
 the same colors as NonText by default.
 
 The first patch contains the actual changes and the second one
 merely adds 'hi link EndOfBuffer NonText' to the default
 colorschemes.
 
 Opinions?
 
 I like the idea.  The only bit that I don't like is having to
 change all color schemes to add the highlight link.  Can't this be
 done by default? Instead of specifying colors that are initially
 equal to NonText, link EndOfBuffer to NonText when initializing the
 colors.

Doesn't the 'highlight' option provide the necessary indirection?
Currently, the @:NonText occasion stands for both. The patch adds
~:EndOfBuffer. If we default that to ~:NonText instead, supporting
colorschemes could do this:

  :set highlight-=~:NonText
  :set highlight+=~:EndOfBuffer

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUU/9LAAoJEA7ziXlAzQ/vqlQH/jMEnmT8YIZSWAG4mZbBsm9e
icFYbk7K55L4lTFsRDbaA1lknfmLw2PC1Zis/5spGNbO/CxlCpliAAeSmGpZgrln
QaLx5cCqkMG09R1A76+HVxQPpd03otlYS8JPVYioMu/LHJi/ZNsUFye5XdldpVVf
9wjUmt2f0ZXqWocePzzI+PDUgpArGozHFLfTyUZ+w/NA7sVX/Eof0gpv7KDVv5Gq
xBXq4EQmdibohKqZpvIKT7sJNo44+Q5MhgVMJrSz3PIrGuJo+v9Q8YBE/xHCKdqJ
CyfvvkMAqIlTEASf2O0jkPdR3Us2szvqw7g+jdiSQU1AC5Qk/L03VYHK7IGVvEY=
=+EzN
-END PGP SIGNATURE-

-- 
-- 
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: allow to vimgrep current buffer

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 31-Oct-2014 12:42 +0100, Bram Moolenaar wrote:

 Zyx wrote:
 
 On October 29, 2014 10:54:38 PM EAT, Bram Moolenaar
 b...@moolenaar.net wrote:
 
 Christian wrote:
 
 On Di, 28 Okt 2014, Ingo Karkat wrote:
 Well, then perhaps a separate :bvimgrep[add] set of
 commands would
 be
 better than overloading the existing commands:
 
 :bvimgrep[!] /{pattern}/[g][j] [bufname] :N,Mbvimgrep[!]
 /{pattern}/[g][j] :bvimgrep[!] /{pattern}/[g][j] N1 N2 ...
 
 Sounds useful. Bram, would you consider including this
 feature, if I write a patch for that?
 
 I think it can be done with a bit of Vim script, but it might
 be generally useful, thus nice to work without installing a
 plugin.
 
 It could also be a solution for something that doesn't work
 yet: Search within a Visual block.  Since this is going to be a
 new command, we can make :',' respect the Visual mode,
 including block.  So you could select a block and type
 :bvimgrep /pattern/, then move to matches with :cn.
 
 I think we can actually call it :bgrep.  It's very unlikely
 'grepprg' is useful to search in buffers and it's shorter to
 type.
 
 No. It is useful if you use something like ag (aka the silver 
 searcher), because VimL regexes lack full Unicode support. Also
 naming command like bgrep in place of bvimgrep is
 inconsistent.
 
 How would an external command access text in a buffer?  Would have
 to write them into a file.
 
 If regex is incomplete we could perhaps fix that.

I would also prefer :bvimgrep for consistency and to signify the
regexp dialect being used; it could be abbreviated as :bv. This keeps
the option of later implementing :bgrep that indeed writes the buffer
to a temp file (if necessary), and runs 'grepprg' over it. (Though the
biggest downside of :vimgrep for me isn't in the regexp dialect, but
its slowness due to loading all files into Vim, something that isn't
an issue when going over Vim's (already loaded) buffers.)

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUVACeAAoJEA7ziXlAzQ/vL9IH/10eE8ZNaFgtFPRXeqtwLcmG
grXbtdRtwt2CbpR0lmduOf91D8OVPu/d+8UgjusVydSLUgbVMPROxDAlsgsTP/1d
EMe9dFHcM/qEbNHt7QR0GQfPqpZ6+yavxPfcqHPeuwsAZTn+KBoc291UkF7G5wgf
pURu5F0lQ/VwjGJvXpSsYCwMjEYn4Cnqv2oMQ6gMDpvUFga62z7MwGuTnKlOjsya
7gdGjOrAKZ2fet2TLrb+JfjNwu7pLPqxJWWcW+hYmOszjhtIFzA2Qr4PJwK6oKVc
hra0TttUVNTr7K7Z/eUV/UBHv5OeQlWKUXDLEf6gqsKAm75lu2K0ppm5o7FlKdI=
=cLGD
-END PGP SIGNATURE-

-- 
-- 
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: allow to vimgrep current buffer

[Ingo Karkat]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28-Oct-2014 15:55 +0100, Павлов Николай  Александрович wrote:

On 28-Oct-2014 15:55, Павлов Николай Александрович wrote: On October
28, 2014 3:22:58 PM EAT, Christian Brabandt cbli...@256bit.org wrote:
 Am 2014-10-28 12:04, schrieb James McCoy:
 On Oct 28, 2014 2:40 AM, Christian Brabandt 
 cbli...@256bit.org wrote:
 
 Am 2014-10-27 23:08, schrieb Bee:
 Just curious...
 
 How is that different from simply using `/` ?
 
 Is this a `just in case` scenario?
 
 
 I find it convenient to have all search results in the 
 quickfix
 buffer.
 
 It'd be even more convenient to allow searching more than just 
 the current buffer (says someone that wrote a buffer grep 
 plugin).
 
 Sure, but I am not sure how to specify it: Something like this 
 (vimgrep buffers 1-4)?
 
 :vimgrep /foobar/ 1,2,3,4 which would not work, if there is a 
 file 1,2,3,4
 
 We don't have commands, that accept several buffer numbers, 
 right?
 
 Wrong. :bw and similar commands accept more then one buffer.
 
 But perhaps an argdo/bufdo :vimgrep would suffice?
 
 No. This will result in either having a hack for catching the 
 situation vimgrep called from :*do or having a quickfix list
 with the results for the last buffer only.  There is :vimgrepadd,
 but this is not going to empty quickfix list before proceeding.
 And :bufdo is a) non-selective and b) switches current buffer.

Well, then perhaps a separate :bvimgrep[add] set of commands would be
better than overloading the existing commands:

:bvimgrep[!] /{pattern}/[g][j] [bufname]
:N,Mbvimgrep[!] /{pattern}/[g][j]
:bvimgrep[!] /{pattern}/[g][j] N1 N2 ...

- -- regards, ingo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJUT7hAAAoJEA7ziXlAzQ/vj20H/j7Vng7ns2UVsWpT2nHHAjHw
CMxs8H5eTzwUOK6UxZ7CXKZvkeaoamm8fjIIqdk1kGzzRoTiylS3C6Iti7XsYnJH
1id/gzbDWuAc5h0MmBxmyLrRaErmlK2LsjKfjvH5tsJMzXZoaIj35kgvVdR0ZDmd
dPwSEfDwUnxUu14rNnE1LaKi/cSSmzMvqvLfiCwIrQfUrfQcRWXd3W2Pw8D7x33Z
MDTCSBVF9bCxbNEiUjOmun/rWGajyFfdhuzXcmciwkSSAUVJkq1sJleC7IES5QIg
Q1j0rf6RrfL3aHuVHlySDjQQCuqxqSbZnVYdBDg8aIbwg0iBJShhNLcYkcFNNfg=
=vlIz
-END PGP SIGNATURE-

-- 
-- 
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: Dear Bram

[Ingo Karkat]

On 06-Oct-2014 12:41 +0200, Paul \leonerd\ Evans wrote:

 On Sat, 4 Oct 2014 12:37:45 -0700
 /#!/JoePea trus...@gmail.com wrote:
 
 Hmmm, yep. I just tested. gvim and MacVim both don't differentiate
 tab and ctrl_i!

 */#!/*JoePea

 On Sat, Oct 4, 2014 at 12:34 PM, Ingo Karkat sw...@ingo-karkat.de
 wrote:

 On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote:

 Not sure what your problem is.  This works just fine:

 imap C-I Up

 It does require gvim, since a terminal doesn't make a difference
 between Tab and CTRL-I.
 
 This, Bram, is exactly the thing I have been arguing at you for years
 now. You keep deflecting this down to make it sound like the terminal's
 fault, when we both know it isn't.
 
 You and I both know full well that terminals don't distinguish them; I
 accept that. That's why I designed a better system, in cooperation with
 Thomas Dickey (the current xterm author). I have a terminal now that
 distinguishes any and all possible combinations of keypresses, and
 programs that understand it. Most of the programs I run regularly now
 do understand this - I can type Ctrl-I and Ctrl-Shift-A and so on
 absolutely fine. Vim is one of the few programs remaining that doesn't.
 (see attached screenshot-1).
 
 Vim - I am talking specifically about vim here - conflates the possible
 keypresses of Ctrl-I vs Tab, of Ctrl-M(or is it Ctrl-J I forget) and
 Enter, of Ctrl-H and Backspace. It further conflates Ctrl-S and
 Ctrl-Shift-S, etc etc... And lets not get started on Unicode vs.
 Alt-letters.
 
 Blaming terminals for this is just deflecting from the fact that vim's
 internals aren't sufficiently generic to represent the possible
 keypresses, regardless of how they arrive. That 1980s-style terminals
 couldn't do it is one thing but that is no excuse that a 2014-style
 GTK/Win32-driven GUI program cannot.
 
 You cannot reply to the original poster of this email and claim that it
 works, until you can perform the following test IN GVIM to demonstrate
 it so.
 
   :imap Tab You typed tab
   :imap C-i You typed Ctrl-I
   :imap C-S-I You typed Ctrl-Shift-I
 
 Then press all three keypresses and show it inserting different text.
 Do this in gvim, so as to avoid any reason to blame the terminal. For
 me, right now in GTK2-driven gvim, I get the Ctrl-Shift-I version all
 three times. (see attached screenshot-2)
 
 Only when that works can you reply to the OP and say this works.
 

To provide evidence that this issue indeed troubles many people
(especially newcomers to Vim), here's an updated tally of related
questions that regularly come up on Stack Overflow and related sites:

https://www.google.com/search?q=site%3Astackoverflow.com%20%2B%22Ingo%20Karkat%22%20%22foremost%20Paul%20LeoNerd%20Evans%22
(about 32 results)

https://www.google.com/search?q=site%3Asuperuser.com+%2B%22Ingo+Karkat%22+%22foremost+Paul+LeoNerd+Evans%22
(6 results)

I'm happy to see that Paul is still pursuing this issue; Bram, why don't
you get him and other developers finally started on designing and
implementing a solution by briefly signaling a willingness to consider
this for a future Vim 8.0?!

-- regards, ingo

-- 
-- 
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: Dear Bram

[Ingo Karkat]

On 04-Oct-2014 15:43 +0200, Bram Moolenaar wrote:

 Not sure what your problem is.  This works just fine:
 
 imap C-I Up
 
 It does require gvim, since a terminal doesn't make a difference between
 Tab and CTRL-I.

No, even GVIM does not differentiate between C-I and Tab; that's
what's causing so many people grief, and is the motivation for
redesigning Vim's input handling.

,[ demo ]
| :imap C-I C-I
| :imap Tab Tab
| :imap C-I
| i  Tab Tab
`

-- regards, ingo

-- 
-- 
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: Windows incorrect rendering of international characters

[Ingo Karkat]

On 31-Jul-2014 15:43 +0200, Ben Fritz wrote:

 On Thursday, July 31, 2014 8:30:36 AM UTC-5, Paul  Moore wrote:
 On Thursday, 31 July 2014 14:08:16 UTC+1, Ben Fritz  wrote:
 I don't see this problem.
 [...]
 I entered unicode characters 5000, 5001, and 5002 which you say are Chinese
 characters, by pressing C-Vu5000 in insert mode, and the same for the 
 other
 two. When I set my font to BatangChe, they look like they could be Chinese
 characters to me, so I assume they are, but I do not know Chinese.

 Do they show if you use a non-Chinese font like Lucida Console or Courier 
 New? They don't for me, but they do in Notepad using those fonts. I don't 
 have BatangChe or any other Chinese-specific fonts.

 I originally hit this issue in a source code file that had a short Chinese 
 string embedded. My apologies for not being sufficiently clear that the 
 issue was when you *didn't* use a special font.

 
 I'm confused. You want Vim to show Chinese characters, in a font that doesn't 
 have any glyphs for Chinese characters?
 

The difference between Vim and Notepad (and many other programs) is that
Vim (on Windows!) does not fall back to glyphs from another font (that
has these), but other programs do. (This may or may not be related to
the proposed removal of the flag; I don't know.)

-- regards, ingo

-- 
-- 
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: Inconsistent regex behaviour in 7.4.383

[Ingo Karkat]

On 30-Jul-2014 12:53 +0200, Bram Moolenaar wrote:

 Tim Brosnan wrote:
 
 I initially send a version of this message through the google groups 
 interface, but it seems to have disappeared. Apologies if there is 
 duplication.

 When going through some regex examples from 
 VimRegexTutor(https://github.com/dahu/VimRegexTutor) I found that one of 
 the examples did not match the provided text when run in 7.4.383. Here 
 is the regex and the sample text:

   *30* : Find Text between HTML tags 

   /\%(\1\)\@=.*\%(\/\(\w\+\)\)\@=

   OR

   /\v%(\\1\)@=.*%(\\/(\w+)\)@=
 
   levelCan I play, daddy?/level

 Neither of the provided regexs would watch the sample text (it should 
 match the text between html tags). However, when I tried 7.1.42 (only 
 other version at hand) I found that the text between tags was matched 
 correctly. Both versions were fun as -u NONE and set nocompatible to 
 try to rule out option or plugin clashes.

 Is this is a bug or has regex behaviour changed between 7.1.42 and 7.4.383?
 
 I don't think the pattern is supposed to work.  The backreference is
 before the capturing group.

Well, it does work in the old engine.

 It's a suprise it works at all.  Probably because in the old regex
 engine the \@= part is used only after finding a match for the
 rest.
 
 It's a very inefficient pattern too, better use:
 
/\(\w\+\).\{-}\zs.*\ze\/\1

You cannot always use \zs in place of \@= (for example, with :syntax
match, or when already using a \zs elsewhere in the pattern).

Just changing the example in the help isn't going to solve the problem
of backwards compatibility. I think the new engine either has to support
it, or detect that special situation and then dynamically switch to the
old engine (like \%#=1 does).

-- regards, ingo

-- 
-- 
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: NFA-regexp discrepancy with \@= and \1 backreference

[Ingo Karkat]

Hello Vim developers,

there's yet another discrepancy between the regular expression engines:

for n in [1,2] | echo match(',abc in abc,abc', '\%#=' . n .
'\1\@=,\([a-z]\+\)') | endfor

I actually found this while checking out an example from the help
(trying to understand why a regexp I use in a plugin didn't work):

,[ :help /\@= ]
| The part of the pattern after \@= and \@! are checked for a
| match first, thus things like \1 don't work to reference \(\) inside
| the preceding atom.  It does work the other way around:
| Example   matches ~
| \1\@=,\([a-z]\+\),abc in abc,abc
`

The NFA engine somehow doesn't properly handle the backreference
assertion and finds a match where it shouldn't.

To reproduce, use above scriptlet or the identical attached script:

vim -N -u NONE -S bad-re5.vim
14
1

This is with a huge build of Vim 7.4.383, running in an Ubuntu 13.10 x64
VM.

-- regards, ingo

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


bad-re5.vim
Description: application/octetstream

Re: 'isfname' and 'isprint' don't allow to include ^@ = 0

[Ingo Karkat]

On 12-Jun-2014 13:07 +0200, Ingo Karkat wrote:

 On 12-Jun-2014 12:51 +0200, Bram Moolenaar wrote:
 
 Christian wrote:

 On Di, 10 Jun 2014, Ingo Karkat wrote:

 Hello Vim developers,

 a question on Super User
 (http://superuser.com/questions/766817/hide-non-printable-characters-in-vim/)
 asks to show all non-printable (control) characters with a single
 display cell. One (hacky, and arguably not perfect) way to do this is by
 including all ASCII characters in 'isprint':

 :set isprint=0-255

 However, this yields E474: Invalid argument. It only works by
 excluding ^@ = 0 (via :set isprint=1-255). Also, other variants such as
 :set isprint^=0 and :set isprint=0,1-255 and :set
 isprint=C-vC-@,1-255 do not work (verified up to current version
 7.4.316).

 The same applies to the similar 'isfname' setting, even though its
 documentation (and 'isprint' refers to that, too) explicitly mentions
 the number 0:

 ,[ :help 'isfname' excerpt ]
 | The format of this option is a list of parts, separated with commas.
 | Each part can be a single character number or a range.  A range is two
 | character numbers with '-' in between.  A character number can be a
 | decimal number between 0 and 255 or the ASCII character itself (does
 | not work for digits).
 `

 I see this as a bug in the :set command, or, if technical reasons
 prevent the use of ^@ in those option values, a bug in the
 documentation. (Preferably, to address the issue in the mentioned
 question, the first. :-)

 I don't know if it is a bug or it was done intentionally and I even 
 don't know what :set isprint=0-255 is supposed to be doing. But here is 
 a patch:

 diff --git a/src/charset.c b/src/charset.c
 --- a/src/charset.c
 +++ b/src/charset.c
 @@ -197,7 +197,7 @@ buf_init_chartab(buf, global)
  #endif
 c2 = *p++;
 }
 -   if (c = 0 || c = 256 || (c2  c  c2 != -1) || c2 = 256
 +   if (c  0 || c = 256 || (c2  c  c2 != -1) || c2 = 256
  || !(*p == NUL || *p == 
 ','))
 return FAIL;

 Well, this allows having a zero in the option value, but I very much
 doubt it actually works.  In C the zero is used to terminate a string,
 thus sending a zero to the terminal just won't work.
 
 Well, at least I can do this in a terminal:
 
 $ printf foo\0bar\n
 foobar
 
 Seems like Bash handles this somehow, and the NUL is skipped / prints as
 nothing.
 
 If you want to *display* control characters you need to do something
 else anyway, since sending a BS or other control character won't result
 in displaying anything.
 
 The OP's use case is representing every character by a single display
 cell. Obviously, BS will mess up things. But probably, a (binary) file
 won't contain many of those (in the area of interest), but possibly a
 lot of NULs. Skipping those in the output might be okay for his use.

I've just tested Christian's patch (on Ubuntu 13.10); adding 0 to
'isprint' messes up the displayed window contents in terminal Vim, less
so in GVIM (there, the NUL is shown as ?, but I still saw occasional
glitches when navigating in the window).

At least, no crashes or other critical problems. So, adding the patch
would make the option more consistent by allowing the 0 value, even
though it's questionable that the current behavior is of any actual use
(but maybe this prompts someone to develop better support for that).

-- regards, ingo

-- 
-- 
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: 'isfname' and 'isprint' don't allow to include ^@ = 0

[Ingo Karkat]

On 12-Jun-2014 12:51 +0200, Bram Moolenaar wrote:

 Christian wrote:
 
 On Di, 10 Jun 2014, Ingo Karkat wrote:

 Hello Vim developers,

 a question on Super User
 (http://superuser.com/questions/766817/hide-non-printable-characters-in-vim/)
 asks to show all non-printable (control) characters with a single
 display cell. One (hacky, and arguably not perfect) way to do this is by
 including all ASCII characters in 'isprint':

 :set isprint=0-255

 However, this yields E474: Invalid argument. It only works by
 excluding ^@ = 0 (via :set isprint=1-255). Also, other variants such as
 :set isprint^=0 and :set isprint=0,1-255 and :set
 isprint=C-vC-@,1-255 do not work (verified up to current version
 7.4.316).

 The same applies to the similar 'isfname' setting, even though its
 documentation (and 'isprint' refers to that, too) explicitly mentions
 the number 0:

 ,[ :help 'isfname' excerpt ]
 | The format of this option is a list of parts, separated with commas.
 | Each part can be a single character number or a range.  A range is two
 | character numbers with '-' in between.  A character number can be a
 | decimal number between 0 and 255 or the ASCII character itself (does
 | not work for digits).
 `

 I see this as a bug in the :set command, or, if technical reasons
 prevent the use of ^@ in those option values, a bug in the
 documentation. (Preferably, to address the issue in the mentioned
 question, the first. :-)

 I don't know if it is a bug or it was done intentionally and I even 
 don't know what :set isprint=0-255 is supposed to be doing. But here is 
 a patch:

 diff --git a/src/charset.c b/src/charset.c
 --- a/src/charset.c
 +++ b/src/charset.c
 @@ -197,7 +197,7 @@ buf_init_chartab(buf, global)
  #endif
 c2 = *p++;
 }
 -   if (c = 0 || c = 256 || (c2  c  c2 != -1) || c2 = 256
 +   if (c  0 || c = 256 || (c2  c  c2 != -1) || c2 = 256
  || !(*p == NUL || *p == 
 ','))
 return FAIL;
 
 Well, this allows having a zero in the option value, but I very much
 doubt it actually works.  In C the zero is used to terminate a string,
 thus sending a zero to the terminal just won't work.

Well, at least I can do this in a terminal:

$ printf foo\0bar\n
foobar

Seems like Bash handles this somehow, and the NUL is skipped / prints as
nothing.

 If you want to *display* control characters you need to do something
 else anyway, since sending a BS or other control character won't result
 in displaying anything.

The OP's use case is representing every character by a single display
cell. Obviously, BS will mess up things. But probably, a (binary) file
won't contain many of those (in the area of interest), but possibly a
lot of NULs. Skipping those in the output might be okay for his use.

-- regards, ingo

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

'isfname' and 'isprint' don't allow to include ^@ = 0

[Ingo Karkat]

Hello Vim developers,

a question on Super User
(http://superuser.com/questions/766817/hide-non-printable-characters-in-vim/)
asks to show all non-printable (control) characters with a single
display cell. One (hacky, and arguably not perfect) way to do this is by
including all ASCII characters in 'isprint':

:set isprint=0-255

However, this yields E474: Invalid argument. It only works by
excluding ^@ = 0 (via :set isprint=1-255). Also, other variants such as
:set isprint^=0 and :set isprint=0,1-255 and :set
isprint=C-vC-@,1-255 do not work (verified up to current version
7.4.316).

The same applies to the similar 'isfname' setting, even though its
documentation (and 'isprint' refers to that, too) explicitly mentions
the number 0:

,[ :help 'isfname' excerpt ]
| The format of this option is a list of parts, separated with commas.
| Each part can be a single character number or a range.  A range is two
| character numbers with '-' in between.  A character number can be a
| decimal number between 0 and 255 or the ASCII character itself (does
| not work for digits).
`

I see this as a bug in the :set command, or, if technical reasons
prevent the use of ^@ in those option values, a bug in the
documentation. (Preferably, to address the issue in the mentioned
question, the first. :-)

-- regards, ingo

-- 
-- 
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: virtcol() subject to showbreak (added: and linebreak)

[Ingo Karkat]

On 04-Jun-2014 16:54 +0200, Павлов Николай  Александрович wrote:

On 04-Jun-2014 16:54, Павлов Николай Александрович wrote:
 
 On June 4, 2014 6:44:34 PM GMT+03:00, Павлов Николай 
 Александрович zyx@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 
 
 On June 4, 2014 3:48:42 PM GMT+03:00, Ingo Karkat 
 sw...@ingo-karkat.de wrote:
 On 04-Jun-2014 13:34 +0200, Axel Bender wrote:
 
 I'd already be happy if virtcol() would take into account
 the length
 of the showbreak string. I'm otherwise prepared to work with 
 UTF-8 characters...
 
 Character widths are not directly related to this, but that 
 little incorrectness in your otherwise precise and welcome bug 
 report shouldn't have provoked such a rant. Sorry.
 
 I consider this a flaw (well maybe a bug?) that should be 
 fixed.
 
 I can reproduce this issue with 7.4.264. Even worse, :set 
 linebreak also affects the virtcol() value and makes it wrong 
 (when such wrap
 occurs).
 So, one only gets correct values out of virtcol() with :set 
 sbr=
 nolbr;
 which indeed should be fixed!
 
 I am not sure it is a bug. Most likely it is absolutely correct 
 behavior: pretend you need to know on which virtual line of the 
 current line cursor is located and on which virtual column on 
 this virtual line. Please describe how you will solve this with 
 current behavior of virtcol() and with proposed one.
 
 Discussing whether this behavior is a bug or not is pointless 
 without showing the use-case. I know that the above task may
 only be solved with bugged virtcol(), otherwise you will have
 to do option parsing for yourself which is a waste of time.
 
 I have a use-case: if you need to move to some character you 
 usually use bar motion and bar motion ignores additional
 characters from showbreak.
 
 Thus I would suggest to patch bar motion to also take breaks into 
 account like virtcol() does.

I use virtcol() in several of my plugins (e.g. AlignFromCursor,
http://www.vim.org/scripts/script.php?script_id=4155), mostly to align
the current line to a column. With the current (broken) behavior of
virtcol(), this alignment would be off when wrapping and linebreak /
showbreak is enabled! When I use the plugin to align the text right of
the cursor to column 80, I want the plugin to manipulate *the text*
(not including any editor embellishments like showbreak!) before the
cursor so that it occupies 79 display cells, regardless of the way
that text line is currently wrapped and displayed. Of course, my
plugin could replace virtcol() with strdisplaywidth(), but the latter
is a recent addition only, and in the next paragraph I'm going to
argue that the two should correspond, not have slightly different
semantics (that before this bug report nobody was aware of).

 I though think that virtcol() behavior is not a bug, but 
 documentation is incorrect (it says the last screen position 
 occupied by the character at that position, when the screen
 would be of **unlimited width** which obviously contradicts with
 the current behavior: no wraps are possible on the screen with 
 unlimited width hence these options may not apply).

To me, what the documentation describes is the sensible and desired
behavior, and the implementation should be changed, not the other way
around. Vim's wrapping behavior and 'showbreak' is limited to this
editor and the user's settings, but when I do formatting, I usually
want to align to idealistic screen columns. Same applies to the bar
motion; I think the current behavior is correct.

-- regards, ingo

-- 
-- 
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: virtcol() subject to showbreak (added: and linebreak)

[Ingo Karkat]

On 04-Jun-2014 13:34 +0200, Axel Bender wrote:

 I'd already be happy if virtcol() would take into account the length of the 
 showbreak string. I'm otherwise prepared to work with UTF-8 characters...

Character widths are not directly related to this, but that little
incorrectness in your otherwise precise and welcome bug report shouldn't
have provoked such a rant. Sorry.

 I consider this a flaw (well maybe a bug?) that should be fixed.

I can reproduce this issue with 7.4.264. Even worse, :set linebreak also
affects the virtcol() value and makes it wrong (when such wrap occurs).
So, one only gets correct values out of virtcol() with :set sbr= nolbr;
which indeed should be fixed!

-- regards, ingo

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

[Ingo Karkat]

On 28-May-2014 14:35 +0200, Bram Moolenaar wrote:

 Patch 7.4.310
 Problem:getpos()/setpos() don't include curswant.
 Solution:   Add a fifth number when getting/setting the cursor.
 Files:src/eval.c, src/testdir/test_eval.in, 
 src/testdir/test_eval.ok,
   runtime/doc/eval.txt

Nice addition, though I currently can't think of a situation where I
would actively set {curswant} to a particular column. Rather, I want my
plugins to set {curswant} when positioning the cursor (what I learned is
done by calling plain cursor(), but not plain getpos('.')). I think that
crucial distinction should be added to the help:

diff --git a/runtime/doc/eval.txt b/runtime/doc/eval.txt
--- a/runtime/doc/eval.txt
+++ b/runtime/doc/eval.txt
@@ -2620,6 +2620,10 @@ cursor({list})
When 'virtualedit' is used {off} specifies the offset in
screen columns from the start of the character.  E.g., a
position within a Tab or after the last character.
+   When {curswant} is omitted, the preferred column is set to
+   {col}, so cursor() behaves like a normal motion (unlike
+   setpos('.', [...]), where {curswant} needs to be present to do
+   this).
Returns 0 when the position could be set, -1 otherwise.

This assumes that the patch doesn't change the previous behavior of
:call cursor(2,3) and that :call cursor([2,3,0]) behaves the same; I
haven't tested that.

-- regards, ingo

-- 
-- 
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: j motion doesn't use position set by setpos('.'), but that of the last insert

[Ingo Karkat]

Hello Vim developers,

I have a custom surround function that basically does this:

let save_cursor = getpos('.')
execute normal! eaXY\Esc
call setpos('.', save_cursor)

And this correctly restores the cursor to the original position. But
when I move down a line (with j, same with k btw.) immediately after
triggering this, the cursor jumps to the column of the last insert (the
Y in the example above). This does not happen when:
- a (no-op) move within the same line is performed (e.g. l followed by
h) before the j
- cursor() is used instead of setpos('.')

I can reproduce this down to Vim version 7.0. Interestingly, in Vim
7.0.000, the cursor() function is also affected, but that starts working
in Vim 7.1.000. I see this in the latest Vim 7.4.307 (HUGE build) on
Linux/x64, as well as Vim 7.4.264 on Windows/x64.

You can reproduce this with the attached scriptlet:

$ vim -N -u NONE -S bug-cursor-j.vim

Or by executing this in the middle of some text:

let save_cursor = getpos('.')|execute normal! eaXY\Esc|call
setpos('.', save_cursor)|normal! j

The problematic call incorrectly positions the cursor (represented by |)
on the last insert column, instead of the column of the B where the
function was triggered:

QuickBrownFoxJumpsOverMe |he he
Quick|BrownFoxJumpsOverMe he he

-- regards, ingo
-- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --

-- 
-- 
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-cursor-j.vim
Description: application/octetstream

BUG: NFA-regexp discrepancy with \%v followed by .*

[Ingo Karkat]

Hello Vim developers,

there's another discrepancy between the regular expression engines:

for n in [1,2] | echo matchlist(foo, '\%#=' . n .
'^\(.*\%3v\)\(o\)')[1:2] | endfor
for n in [1,2] | echo matchlist(foo, '\%#=' . n .
'^\(.*\%3v\)\(.*\)')[1:2] | endfor

This affects matching with \%v (also with \%c) when it is followed by
a .* expression.

To reproduce, use above scriptlet or the identical attached script:

vim -N -u NONE -S bad-re4.vim
['f', 'o']
['f', 'o']
['f', 'oo']
['', 'foo']   - Wrong result with re=2 and following .* pattern

This is with a huge build of Vim 7.4.267, running in an Ubuntu 13.04 x64
VM, and with a self-compiled Windows/x64 build.

-- regards, ingo

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


bad-re4.vim
Description: application/octetstream

Re: _dd doesn't reset v:register

[Ingo Karkat]

On 30-Apr-2014 13:14 +0200, Bram Moolenaar wrote:

 Christian Brabandt wrote:
 
 Hi Andrew!

 On Di, 29 Apr 2014, Andrew wrote:

 Hi, Christian,

 Can you please come up with a mapping that shows the wrong behaviour?

 I made this example: https://gist.github.com/AndrewRadev/11408444

 It's supposed to paste some text and comment it in the process. It's kind 
 of silly, but a realistic enough example. If you `_dd` anything and then 
 immediately perform a `gp`, nothing happens, since the `v:register` 
 variable is set to `_`. If you've managed ot fix the issue, it should 
 paste normally, from the default register.

 Thanks. I think this one fixes it:

 diff --git a/src/normal.c b/src/normal.c
 --- a/src/normal.c
 +++ b/src/normal.c
 @@ -1263,6 +1263,10 @@ getcount:
  normal_end:

  msg_nowait = FALSE;
 +#ifdef FEAT_EVAL
 +/* reset v:register */
 +set_reg_var(0);
 +#endif

  /* Reset finish_op, in case it was set */
  #ifdef CURSOR_SHAPE

 (I hope, it doesn't have any side effect).

 Well, if one first does add  and then _dd, it's a bit unexpected that
 v:register is then '' and not '_' or 'a'.

 I am not sure I follow. Why would one expect v:register to hold the 
 register name from the previous
 normal mode command?
 
 Because that's where the deleted text is.  I know that the docs say that
 the v:register variable holds the register name for the *current* normal
 mode command, but it appears users writing a mapping also use it after
 the normal mode command is done, to find the text that was yanked or
 deleted.  It would then be logical to use the black hole register if any
 other delete must happen, without messing with registers.  But then
 v:register must also not be changed by the operation that uses the black
 hole register.

I find this undocumented behavior quirky and unexpected. If I do xyy,
then :echo v:register should return , not x. Isn't : a normal-mode
command that enters command-line mode? Also, after x:echo v:register, I
get x, but then the next :echo v:register gives , not x as in the yank
example.

 I don't have a good example of where this is needed though.  And perhaps
 it's not too difficult to get the value of v:register before using the
 black hole register, in which case the change to v:register is irrelevant.

I haven't seen this in use, neither. A mapping should go to command-line
mode as soon as possible, and there save / use the v:register value. If
someone really needs this, a v:prevregister could still be contemplated.

Christian, thanks for the patch!

-- regards, ingo

-- 
-- 
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: Change mark '[ at end, not start of first line after gq.

[Ingo Karkat]

On 28-Apr-2014 23:05 +0200, Christian Brabandt wrote:

 On Do, 24 Apr 2014, Ingo Karkat wrote:
 
 Hello Vim developers,

 my plugins' automated test suite found another regression. When
 reformatting lines with gq{motion}, the start of change mark '[ does not
 point to the start of the first line [0, lnum, 1, 0] any more, but
 instead to after the end of the original first line [0, lnum,
 len(getline(lnum)) + 1, 0].
 As gq processes entire lines, the start of the change should indeed be
 at column 1, as it used to.

 This scriptlet shows the discrepancy:

 :call setline(1, [\t\tO sodales, ludite, vos qui, attamen consulite 
 per voster honur. Tua pulchra facies me fay planszer milies])
 :1normal! gqj
 :echo getpos('[)  Should yield [0, 1, 1, 0], but gives [0, 1, 29, 0].

 Using the attached scriptlet, I've bisected this to the following patch:

 ,[ bad change ]
 | 7.4.178  the J command does not update '[ and '] marks
 `

 I still see this in the latest 7.4.264 (HUGE build) on Linux/x64.

 -- regards, ingo
 
 Please check the following patch. I'll added a new test for this.

Good job (as always)! I can confirm that this (patch 7.4.267) fixes the
problem for me and didn't create any new issues in my plugins' test suite.

-- thanks, ingo

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

[Ingo Karkat]

On 23-Apr-2014 23:11 +0200, Matteo Cavalleri wrote:

 Patch 7.4.264 (after 7.4.260)

 Problem:Can't define a function starting with g:.  Can't assign a

 funcref to a buffer-local variable.

 Solution:   Skip g: at the start of a function name.  Don't check for 
 colons

 when assigning to a variable.
 
 I'm still having problems:
 
 
 line   17:
 E121: Undefined variable: g:vundle_last_status
 E15: Invalid expression: 'updated' == g:vundle_last_status  empty(msg)
 Error detected while processing function 
 vundle#installer#new..SNR106_process.
 .vundle#installer#run..vundle#installer#install..SNR106_sync:
 line6:
 E117: Unknown function: g:shellesc_cd
 E15: Invalid expression: g:shellesc_cd(cmd)
 Error detected while processing function 
 vundle#installer#new..SNR106_process:
 
 line   13:
 E121: Undefined variable: g:vundle_last_status
 E15: Invalid expression: 'error' == g:vundle_last_status
 line   17:
 E121: Undefined variable: g:vundle_last_status
 E15: Invalid expression: 'updated' == g:vundle_last_status  empty(msg)
 Error detected while processing function 
 vundle#installer#new..SNR106_process.
 .vundle#installer#run..vundle#installer#install..SNR106_sync:
 line6:
 E117: Unknown function: g:shellesc_cd
 E15: Invalid expression: g:shellesc_cd(cmd)
 Error detected while processing function 
 vundle#installer#new..SNR106_process:
 
 line   13:
 E121: Undefined variable: g:vundle_last_status
 E15: Invalid expression: 'error' == g:vundle_last_status
 
 
 the following looks more like it's the script author fault, but I'm not sure 
 if all the errors are due to the illegal function name or not, so I'm pasting 
 them all:
 
 
 Error detected while processing 
 /Users/matteo/.vim/bundle/vdebug/plugin/vdebug.vim:
 line  151:
 E128: Function name must start with a capital or s:: 
 vdebug:get_visual_selection()
 line  155:
 E684: list index out of range: -1
 E15: Invalid expression: lines[-1][: col2 - 1]
 line  156:
 E684: list index out of range: 0
 E15: Invalid expression: lines[0][col1 - 1:]
 line  157:
 E133: :return not inside a function
 line  158:
 E193: :endfunction not inside a function
 line  160:
 E128: Function name must start with a capital or s:: vdebug:edit(filename)
 line  162:
 E121: Undefined variable: a:filename
 E116: Invalid arguments for function fnameescape(a:filename)
 E15: Invalid expression: fnameescape(a:filename)
 Press ENTER or type command to continue

Me, too. The following used to work:

fun! Foo()
endfun
let g:Foo = function('Foo')

After 7.4.264, I get:
 E705: Variable name conflicts with existing function: g:Foo

In general, I do welcome the introduced restrictions, though, I've found
a place where I attempted to define a buffer-local function (fun!
b:Foo()); this is now correctly flagged with E128.

-- regards, ingo

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

[Ingo Karkat]

On 23-Apr-2014 18:49 +0200, Bram Moolenaar wrote:

 Patch 7.4.261
 Problem:When updating the window involves a regexp pattern, an interactive
   substitute to replace a \n with a line break fails. (Ingo
   Karkat)
 Solution:   Set reg_line_lbr in vim_regsub() and vim_regsub_multi().
 Files:src/regexp.c, src/testdir/test79.in, src/testdir/test79.ok

Thanks (also to Christian for the quick initial fix)! I can confirm that
this fixes the issue for me.

-- regards, ingo

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

[Ingo Karkat]

On 24-Apr-2014 12:43 +0200, Bram Moolenaar wrote:

 Ingo Karkat wrote:
 
 Me, too. The following used to work:

 fun! Foo()
 endfun
 let g:Foo = function('Foo')

 After 7.4.264, I get:
  E705: Variable name conflicts with existing function: g:Foo
 
 That is correct.  Previously Foo() and g:Foo were different names, which
 is wrong.  Both refer to the same function.

Ah, okay. I can accept that.

What I find inconsistent and strange is that though I can define
g:Foo(), I cannot call it with that global-scoped name:

fun g:Foo()
return 42
endfun
echo Foo()
42
echo g:Foo()
E117: Unknown function: g:Foo
E15: Invalid expression: g:Foo()

Not that I personally would use the g:Foo() syntax, but I'm very used to
calling (script-local) s:Foo(), and this behavior is inconsistent.


 In general, I do welcome the introduced restrictions, though, I've found
 a place where I attempted to define a buffer-local function (fun!
 b:Foo()); this is now correctly flagged with E128.
 
 Right.  So the problem is that users have been using wrong function
 names, and they did work.  Now they are flagged as errors, which may
 break some scripts.
 
 The question is: Is it acceptable to expect users to fix those scripts,
 or do we need to be lenient.  A possible way is to add an option to
 allow the wrong names.  That's not a nice solution though, it hides the
 actual problem.

As these are real bugs, I'm against an option allowing those, too.

Rather, the help about the error message should provide good
instructions (drop the invalid scope prefix) so that even casual users
are able to fix their beloved decades-old plugin that has long been
abandoned by its original author.

-- regards, ingo

-- 
-- 
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: Change mark '[ at end, not start of first line after gq.

[Ingo Karkat]

Hello Vim developers,

my plugins' automated test suite found another regression. When
reformatting lines with gq{motion}, the start of change mark '[ does not
point to the start of the first line [0, lnum, 1, 0] any more, but
instead to after the end of the original first line [0, lnum,
len(getline(lnum)) + 1, 0].
As gq processes entire lines, the start of the change should indeed be
at column 1, as it used to.

This scriptlet shows the discrepancy:

:call setline(1, [\t\tO sodales, ludite, vos qui, attamen consulite per 
voster honur. Tua pulchra facies me fay planszer milies])
:1normal! gqj
:echo getpos('[)  Should yield [0, 1, 1, 0], but gives [0, 1, 29, 0].

Using the attached scriptlet, I've bisected this to the following patch:

,[ bad change ]
| 7.4.178  the J command does not update '[ and '] marks
`

I still see this in the latest 7.4.264 (HUGE build) on Linux/x64.

-- regards, ingo
-- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --

-- 
-- 
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-gq-changecol.vim
Description: application/octetstream

Re: Regression: Change mark '[ at end, not start of first line after gq.

[Ingo Karkat]

On 24-Apr-2014 14:27 +0200, Christian Brabandt wrote:

 Am 2014-04-24 13:39, schrieb Ingo Karkat:
 Hello Vim developers,

 my plugins' automated test suite found another regression. When
 reformatting lines with gq{motion}, the start of change mark '[ does not
 point to the start of the first line [0, lnum, 1, 0] any more, but
 instead to after the end of the original first line [0, lnum,
 len(getline(lnum)) + 1, 0].
 As gq processes entire lines, the start of the change should indeed be
 at column 1, as it used to.

 This scriptlet shows the discrepancy:

 :call setline(1, [\t\tO sodales, ludite, vos qui, attamen
 consulite per voster honur. Tua pulchra facies me fay planszer
 milies])
 :1normal! gqj
 :echo getpos('[)  Should yield [0, 1, 1, 0], but gives [0, 1,
 29, 0].

 Using the attached scriptlet, I've bisected this to the following patch:

 ,[ bad change ]
 | 7.4.178  the J command does not update '[ and '] marks
 `

 I still see this in the latest 7.4.264 (HUGE build) on Linux/x64.
 
 Yes, previously, the join command wouldn't update the '[ and '] marks.
 Now it does.
 That is causing your regression.

Yeah, I had assumed that the gq implementation internally uses the join
command, so this is a classic case of unexpected side effects.

 I look into it.

Thank you very much!

 BTW: What kind of regression tests are you doing? Could that be used
 to extend the unit-test functionality in the testdir/ directory of Vim's
 source?

I have automated tests for about half of my plugins, using my own
runVimTests (http://www.vim.org/scripts/script.php?script_id=2565) test
framework. For illustration, here's the particular test that exposed
this regression:

,[ example runVimTests test ]
|  Test formatting lines to the width.
|
| edit text.txt
|
| call vimtest#StartTap()
| call vimtap#Plan(2)
|
| 13normal V5j\gq
|
| 3normal V5j\gq
| call vimtap#Is(getpos('[), [0, 3, 1, 0], 'start of change')
| call vimtap#Is(getpos(']), [0, 14, 3, 0], 'end of change')
|
| call vimtest#SaveOut()
| call vimtest#Quit()
`

As all of my tests require and mainly test my plugins, I don't think
that Vim's test suite can directly benefit from them. However, as a side
effect, my test suite had exposed several bugs in the NFA-based regexp
engine before.

I've put down a note to set up a cron job that every few days pulls down
the latest changes from Mercurial, compiles Vim, and runs my tests. That
should enable me to quickly point out any regressions caught by my suite
in the future!

For each test failure, I still have to analyze, extract the code from my
test and plugin, and distill a minimal test scriptlet, which I then use
to bisect and post here. I hope that those can indeed be easily turned
into a Vim test. If there's anything I can do to make this translation
easier, please let me know. In general, a short tutorial how the Vim
tests work, idioms, and best practices (posted here on or vim.org) would
be great.

-- regards, ingo

-- 
-- 
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: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag

[Ingo Karkat]

Hello Vim developers,

I've noticed a regression:

:s/.*/\=foo\nbar/

This correctly replaces the current line with two lines containing foo
and bar, respectively. Now add the confirm flag, and accept the
replacement:

:s/.*/\=foo\nbar/c

This replaces the current line with a single line containing foo^@bar
(where ^@ is Nul). This is inconsistent and unexpected. Replacing with
\r instead works (with and without the flag), and can be used as a
workaround.

Using the attached scriptlet, I've bisected this to the following patch:

,[ bad change ]
| 7.3.225  \n in a substitute() inside :s not handled correctly
`

The problem therefore can be seen in this and all following Vim
versions, verified up to the latest 7.4.258. (I've used a HUGE build on
both Windows/x64 and Linux/x64.)

-- regards, ingo
-- 
  -- Ingo Karkat --  /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
  --   http://vim.sourceforge.net/account/profile.php?user_id=9713   --

-- 
-- 
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-s_c-newline.vim
Description: application/octetstream

Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag

[Ingo Karkat]

On 23-Apr-2014 16:28 +0200, Bram Moolenaar wrote:

 Ingo Karkat wrote:
 
 I've noticed a regression:

 :s/.*/\=foo\nbar/

 This correctly replaces the current line with two lines containing foo
 and bar, respectively. Now add the confirm flag, and accept the
 replacement:

 :s/.*/\=foo\nbar/c

 This replaces the current line with a single line containing foo^@bar
 (where ^@ is Nul). This is inconsistent and unexpected. Replacing with
 \r instead works (with and without the flag), and can be used as a
 workaround.

 Using the attached scriptlet, I've bisected this to the following patch:

 ,[ bad change ]
 | 7.3.225  \n in a substitute() inside :s not handled correctly
 `

 The problem therefore can be seen in this and all following Vim
 versions, verified up to the latest 7.4.258. (I've used a HUGE build on
 both Windows/x64 and Linux/x64.)
 
 I cannot reproduce this problem.

Ah, sorry, I missed one crucial detail of my environment (and forgot to
use -N -u NONE). In my 'statusline', I have a custom function that
performs a =~ comparison. Define the following:

function! TitleString()
let check = 'foo' =~ 'bar'
return 
endfunction
set titlestring=%{TitleString()}

Then, the

:s/.*/\=foo\nbar/c

command will produce the ^@. So the =~ (probably triggered while the
confirm flag is in action) somehow affects the behavior of :substitute.

Attached is an updated scriptlet.

-- regards, ingo

-- 
-- 
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-s_c-newline.vim
Description: application/octetstream

Re: Regression: ^@ instead of line break when using sub-replace-expr and \n together with :s_c flag

[Ingo Karkat]

On 23-Apr-2014 17:37 +0200, Christian Brabandt wrote:

 Am 2014-04-23 16:28, schrieb Bram Moolenaar:
 Ingo Karkat wrote:

 I've noticed a regression:

 :s/.*/\=foo\nbar/

 This correctly replaces the current line with two lines containing foo
 and bar, respectively. Now add the confirm flag, and accept the
 replacement:

 :s/.*/\=foo\nbar/c

 This replaces the current line with a single line containing foo^@bar
 (where ^@ is Nul). This is inconsistent and unexpected. Replacing with
 \r instead works (with and without the flag), and can be used as a
 workaround.

 Using the attached scriptlet, I've bisected this to the following patch:

 ,[ bad change ]
 | 7.3.225  \n in a substitute() inside :s not handled correctly
 `

 The problem therefore can be seen in this and all following Vim
 versions, verified up to the latest 7.4.258. (I've used a HUGE build on
 both Windows/x64 and Linux/x64.)

 I cannot reproduce this problem.
 
 I see the problem with vim-airline. I think, it is caused by the
 evaluation of the statusline resetting reg_line_lbr when displaying the
 confirmation message. Attached patch fixes this, but I think one should
 also reset all the other internal static variables.

Thanks Christian, that patch indeed fixes the problem for me. Good hunch
about the statusline, that is indeed a necessary condition (as I have
added in my updated message).

You seem to be really knowledgable about Vim's internals. The question I
have in mind right now is whether you still feel comfortable about those
internal static variables, or whether you think this poses long-term
risks to Vim's stability. At least some people think so, and have
suggested / started a complete rewrite (in a language like C++ that has
better means to avoid such). Is there anything (apart from more test
coverage) that we can do with the current code base?!

-- regards, ingo

-- 
-- 
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: _dd doesn't reset v:register

[Ingo Karkat]

On 19-Apr-2014 17:41 +0200, Andrew wrote:

 I suspect something about your setup is doing this.  When I follow your 
 instructions, I get precisely the expected behavior.
 
 Ah, actually, that was silly of me. You wouldn't be able to reproduce it like 
 this, since the normal `p` works just fine :/.
 
 Instead, try:
 
 _dd:echo v:registercr
 
 As in, just take a look at the value of `v:register` after the `_dd` 
 operation. For me, it's `_`, but after the operation is done, I would expect 
 it to change to the default, usually ``.
 
 Also, I realize I forgot to link to my `vim --version` output: 
 https://gist.github.com/AndrewRadev/11087768

The same applies to yank commands, too. This matters for mappings and
plugins that evaluate v:register. After a command such as _dd, the
register used by the mapping / plugin is wrong. One first has to do
another command (e.g. hl: back-and-forth motions) to reset v:register
to the correct default.

-- regards, ingo

-- 
-- 
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: Tab Indent Problem

[Ingo Karkat]

On 15-Mar-2014 10:06 +0100, Andre Sihera wrote:

 Hi all,
 
 I have found an annoyance with the tab indenting (SHIFT + '', SHIFT +
 '') and
 was wondering if this was by design or should be fixed.
 
 My .vimrc contains the following:
 
 set ts=4
 set shiftwidth=4
 
 So, when I visually select a block of text and press SHIFT + '' it will
 insert
 a tab on the left on each line and the block moves four characters to
 the right.
 
 However, this feature does not honour leading whitespace within each
 line. I use a
 mixture of tabs and whitespace to ensure that my code looks uniform on
 all platforms
 no matter what the tab size. However, the tab indent breaks this. For
 example,
 if I have the following text at ts=4 (a full stop . character
 indicates a space):
 
 TABsprintf(szSomeVariable,
 TABSome text %i, %i, %i, %i\n,
 TABsome_very_long_expression_that_takes_up_most_of_the_line_#1,
 TABsome_very_long_expression_that_takes_up_most_of_the_line_#2,
 TABsome_very_long_expression_that_takes_up_most_of_the_line_#3,
 TABsome_very_long_expression_that_takes_up_most_of_the_line_#4);
 
 and I visually highlight the above block and press SHIFT + '', I would
 expect
 it to look as follows:
 
 TABTABsprintf(szSomeVariable,
 TABTABSome text %i, %i, %i, %i\n,
 TABTABsome_very_long_expression_that_takes_up_most_of_the_line_#1,
 
 TABTABsome_very_long_expression_that_takes_up_most_of_the_line_#2,
 
 TABTABsome_very_long_expression_that_takes_up_most_of_the_line_#3,
 
 TABTABsome_very_long_expression_that_takes_up_most_of_the_line_#4);
 
 
 However, it actually looks like this:
 
 TABTABsprintf(szSomeVariable,
 TABTABTABTABSome text %i, %i, %i, %i\n,
 TABTABTABTABsome_very_long_expression_that_takes_up_most_of_the_line_#1,
 
 TABTABTABTABsome_very_long_expression_that_takes_up_most_of_the_line_#2,
 
 TABTABTABTABsome_very_long_expression_that_takes_up_most_of_the_line_#3,
 
 TABTABTABTABsome_very_long_expression_that_takes_up_most_of_the_line_#4);
 
 
 i.e., ViM is being too clever and compressing all my whitespace into
 tabs when I
 didn't ask it to.
 
 Is this by design? Has it been fixed since my ancient version of ViM
 (7.3.475)?
 Did I miss something in the docs? Or is this just a feature?

I think you're looking for

:set preserveindent copyindent

-- regards, ingo

-- 
-- 
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: Is there any way to get the vim executable path from within vim?

[Ingo Karkat]

On 14-Mar-2014 08:20 +0100, Jürgen Krämer wrote:

 Hi,
 
 Viktor Kojouharov wrote:
 To easily use the remote-expr feature. You need to start a new
 instance of vim and point it to the current running vim server. And I
 need the full executable path in order to start the remote-expr. Vim
 is usually in the path on linux systems, but that's not the case on
 windows and macvim

 
 at least on Windows Vim puts its own directory at the end of the %PATH%
 environment variable. You can check this with :echo $PATH. So there is
 no need to use a full path to the Vim executable.

If this is for a plugin, I'd also keep this Simple and Stupid: Just
allow (users, individual systems) to specify a full path via a
configuration variable, and default to vim found via the PATH, which
should already work on most systems.

Even with a suggested new v:progpath variable, you'd need to handle
older Vim versions, anyway.

-- regards, ingo

-- 
-- 
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: Incorrect expansion of %?

[Ingo Karkat]

On 11-Mar-2014 15:14 +0100, Ben Fritz wrote:

 On Tuesday, March 4, 2014 1:15:40 AM UTC-6, Gary Johnson wrote:


 Using a GUI file manager, I opened this file with gvim.  I made some

 changes to it, then tried comparing the changed buffer with the

 copy on disk with this command which I have used for years:



 :w !diff % -



 The result surprised me.



 diff: Dropbox/vimfiles/filetype \(toucan's conflicted copy 
 2014-03-01\).vim: No such file or directory



 shell returned 2



 However, if instead I typed



 :w !diff ^R% -



 where ^R means Ctrl-R, the command became



 :w !diff Dropbox/vimfiles/filetype (toucan's conflicted copy 
 2014-03-01).vim -



 and worked fine.



 
 Isn't this situation what shellescape() is designed for?
 
 That's not saying shellescape() will work, but I think it's supposed
 to work, unlike using a bare % which should always work for internal
 Vim commands but will only work by accident in external commands.

No, shellescape() would be used in a mapping / command, like this:
shellescape(expand('%'), 1). With the 1 flag (for use with :!), a
literal % is properly escaped to \% so that Vim's special handling does
not apply.

% is handy for interactive use, like :!perl %

-- regards, ingo

-- 
-- 
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: v:beval_winnr is enumerates windows from 0 upwards

[Ingo Karkat]

On 16-Jan-2014 23:46 +0100, Lech Lorens wrote:

 winnr() returns the index of the window 1-based while v:beval_winnr
 (:help 'bexpr') is 0-based.  I believe the latter should be fixed.  The
 attached patch adds increments the value of v:beval_winnr by 1.

The choosen base is unfortunate, but for backwards compatibility, I'd
rather keep it 0-based. The help (which your patch fails to adapt)
clearly mentions this:

,[ :h v:beval_winnr ]
| The first window has number zero (unlike most other places where a
| window gets a number).
`

-- regards, ingo

-- 
-- 
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/groups/opt_out.

Re: How to find out when a VimL function was added?

[Ingo Karkat]

On 15-Jan-2014 09:59 +0100, boss wrote:

 Hello!
 
 A user of one of my plugins recently reported this error: `E117:
 Unknown function: gettabvar`.  He also told me the version of Vim he's
 using.
 
 How can I find out when gettabvar() – or any function in general – was
 added to VimL?
 
 Being able to find this out would help me decide whether or not to use
 a particular VimL function, and/or whether to wrap it in a
 version-check guard.

Note that instead of checking for the version in the guard (which
usually involves also checking the patch level), it's easier and better
to check for the existence, in your case via if exists('*gettabvar') ...
See :h exists().

-- regards, ingo

-- 
-- 
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/groups/opt_out.

Re: Allow gvim to start with no file name after --remote-silent

[Ingo Karkat]

On 30-Dec-2013 13:36 +0100, Axel Bender wrote:

 A simple solution might be the one attached below. Don't know however,
 if there are any side effects. Works for me.

Unlike :edit, the :drop command adds the file to the argument list. I'd
say that's an unexpected side effect.

 [42 lines deleted]

-- regards, ingo

-- 
-- 
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/groups/opt_out.

Re: Complete Overwrite Vim

[Ingo Karkat]

On 22-Dec-2013 21:15 +0100, Ishfaque Jahan Rafee wrote:

 [1 sentence deleted] But yet requirement of compile time support for
 different language, while installing plugins during use, does suck. If
 not drop support, it should be made mandatory for all package manager
 to have everything as +.

Better leave that decision to the package managers; I think most do try
to offer as much as possible. For example, the Vim that comes with my
Ubuntu installation supports all of Perl, Python, and Ruby.

 [2 paragraphs deleted]
 
 Nobody said about number 4 argument. Latex is the only major language that's 
 pushing me to emacs. I think its about time scopes are created for plugins 
 like preview-latex in Vim. Its impossible in terminal vim, but shouldn't be 
 impossible on GVim.

Vim strives to be as consistent (between terminal and GUI) as possible.
See here:

,[ :help design-not ]
| - Vim is not a fancy GUI editor that tries to look nice at the cost of
|   being less consistent over all platforms.  But functional GUI
|   features are welcomed.
`

 Argument number 5 was about opening up documentation where I am
 editing. If you ever use YouCompleteMe or Jedi-vim, you will see that
 they provide pydoc documentation to the buffer I am editing. The popup
 contains the completion data, but the documentation is displayed at a
 split at Top. But it would be much better if the documentation was
 provided at the point where I am editing, so that I don't need to move
 my eyes from one place to another.

Don't compare Vim too much to IDEs! Because of its strict cell layout
(also in the GUI, see counter-argument 4 above), there's much less space
for showing the completion information than a proportional,
smaller-sized font would allow. I find the use of the preview window for
additional information a very clever invention.

-- regards, ingo

-- 
-- 
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/groups/opt_out.

Re: bug in search-and-replace in visual mode?

[Ingo Karkat]

On 07-Dec-2013 18:02 +0100, Hisashi T Fujinaka wrote:

 I have two columns of text and I just want to replace in one of the two
 columns. For example:
 
 foo-bar-grillfoo-bar
 2foo-bar-grillfoo-bar
 
 and I just want to replace the second foo-bar with moose or something. I
 can visually select either column and then try a search and replace.
 Hitting : will prepopulate with ',' and so the line will look
 something like: ','s/foo-bar/moose/.
 
 No matter what column I select, only the first column gets changed.
 
 The only google help I get is from wikia and it talks about %V which
 doesn't work for me.
 
 Is this normal behavior?

Yes, it is, because :substitute always applies to entire lines of the
passed range, regardless of what was selected. You indeed have to use
\%V inside the pattern to further restrict the match:

','s/\%Vfoo-ba\%Vr/moose/

(or use the vis.vim plugin's :B command).

-- regards, ingo

-- 
-- 
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/groups/opt_out.

BUG: NFA-regexp discrepancy with non-greedy match

[Ingo Karkat]

Hello Vim developers,

there's another discrepancy between the regular expression engines:

for n in [0, 1] | echo string(matchstr(' x', '\%#=' . n . '^\s\{-}\zs\(x\| 
x$\)')) | endfor
for n in [0, 1] | echo string(matchstr(' x', '\%#=' . n . '^\s\{-}\ze\(x\| 
x$\)')) | endfor
for n in [0, 1] | echo string(substitute(' x', '\%#=' . n . '^\(\s\{-}\)\(x\| 
x$\)', '\1|\2', '')) | endfor

It apparently depends on the non-greedy \s\{-} match together with the
branches where only one is anchored. It does _not_ matter whether the
split is introduced with \zs, \ze, or capturing groups.

To reproduce, use above scriptlet or the identical attached script:

vim -N -u NONE -S bad-re3.vim
'x'
' x'
' '
''
' |x'
'| x'

This is with a huge build of Vim 7.4.110, running in an Ubuntu 13.04 x64
VM.

-- regards, ingo

-- 
-- 
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/groups/opt_out.


bad-re3.vim
Description: application/octetstream

Re: Regression: cursor not at end of paste after resetting 'virtualedit' (after 7.4.034)

[Ingo Karkat]

On 21-Nov-2013 07:54 +0100, Christian Brabandt wrote:

 On Wed, November 20, 2013 20:58, Christian Brabandt wrote:
 On Mi, 20 Nov 2013, Ingo Karkat wrote:
 the automated test suite of one of my plugins caught a regression,
 caused by

 ,[ patch 7.4.034 ]
 | using p in Visual block mode only changes the first line
 `

 The steps to reproduce are a bit strange, but not unusual when used in a
 plugin. It's based on pasting over a characterwise visual selection that
 ends at the end of the current line via p while :set virtualedit=all,
 then clearing virtualedit. I've used the attached script with hg
 bisect; it'll exit with 1 when the bug is present.
 
 I think, this patch is a little better:
 
  diff --git a/src/ops.c b/src/ops.c
  --- a/src/ops.c
  +++ b/src/ops.c
  @@ -3818,7 +3818,11 @@
  ml_replace(lnum, newp, FALSE);
  /* Place cursor on last putted char. */
  if (lnum == curwin-w_cursor.lnum)
  +   {
  +   /* make sure curwin-w_virtcol is updated */
  +   curwin-w_valid = 0;
  curwin-w_cursor.col += (colnr_T)(totlen - 1);
  +   }
  }
   #ifdef FEAT_VISUAL
  if (VIsual_active)

Thanks, Christian! I can confirm that above patch fixes the problem.

-- regards, ingo

-- 
-- 
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/groups/opt_out.

Regression: cursor not at end of paste after resetting 'virtualedit' (after 7.4.034)

[Ingo Karkat]

Hello Vim developers,

the automated test suite of one of my plugins caught a regression, caused by

,[ patch 7.4.034 ]
| using p in Visual block mode only changes the first line
`

The steps to reproduce are a bit strange, but not unusual when used in a
plugin. It's based on pasting over a characterwise visual selection that
ends at the end of the current line via p while :set virtualedit=all,
then clearing virtualedit. I've used the attached script with hg
bisect; it'll exit with 1 when the bug is present.

-- regards, ingo

-- 
-- 
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/groups/opt_out.


bug-virtualedit-pastepos.vim
Description: application/octetstream