Re: the :sort command does not appear to give expected result

On Tue, Oct 27, 2020 at 10:26:47PM EDT, Tony Mechelynck wrote:
> On Tue, Oct 27, 2020 at 11:55 PM Chris Jones <cjns1989@gmail.com> wrote:

> A "stable" sort is a sort which will keep lines with the same sort
> keys in the order they were before the sort. (If you sort on whole
> lines the difference is not visible, unless there exist different
> lines which sort as equal, but if you sort on "pattern" or on "first
> number" it may matter.)
>
> But there is another few sentences which may be relevant in the help
> for :sort, near the end, as follows:
>
> <quote>
> The details about sorting depend on the library function used. There is no
> guarantee that sorting obeys the current locale. You will have to try it out.
> </quote>
>
> $LC_COLLATE is the part of the locale which says how to sort. if
> $LC_ALL is set if overrides all the others, otherwise $LANG is used as
> a fallback for any locale variable which is not set. ":lang" with no
> arguments lists all settiings after taking care of $LANG and/or
> $LC_ALL if present.

Thanks for reminding me what 'stable' means in this context. What I am
driving at is that... stable or not... I just need sort to do the job
right, which in this particular use case appears not to be the case.

In other words when I use the vim :sort command the output should have
index entries starting with É under letter E... Œ under letter O, etc.
which as far as I know is the way things work with French language
indexes.

As quoted above the ':help :sort' documentation proceeds to inform me
that I will have to 'try it out'. Seriously?

As it happens my original post explained just that. I 'tried it out' and
the result is either of two things: I did not 'try it out' right (user
error) or vim does not sort correctly (bug).

Now you're telling me that it's not vim's fault (couldn't care less
whose fault it is)... it's "the libary's".

So what's the next step?

Should I determine what library is at fault so I can discuss it with the
developer... or should I ask vim to kindly switch to a library that
actually works such as GNU's (coreutils) which as tested (cf. original
post) does sort correctly?

Thank you,

CJ

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201031191652.gnitlkzwur5z6nod%40turki.local.

Available vim python IDE plugin which supporting dynamic/runtime auto-completion for type/variable/function names.

Hi,

Are there any existent vim python IDE plugins which supporting
dynamic/runtime auto-completion for type/variable/function names, just
as the behavior showed by ipython/jupyter?

Regards,
--
Assoc. Prof. Hongyi Zhao <hongyi.zhao@gmail.com>
Theory and Simulation of Materials, Xingtai Polytechnic College
NO. 552 North Gangtie Road, Xingtai, China

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAGP6POJtkTvMc83Tr48%3DfmcPFDosozOR2WR%2BeiyZWq30xE6Chw%40mail.gmail.com.

Re: the :sort command does not appear to give expected result

On Tue, Oct 27, 2020 at 11:55 PM Chris Jones <cjns1989@gmail.com> wrote:
>
> Here's a (test) file that contains a sample of single characters from
> the French alphabet.
>
> Column 1 contains a <tab> character (0x09) and column 2 contains the
> actual letters.
>
> A
> E
> O
> À
> È
> É
> Ô
> Œ
>
> If I use the sort command provided on linux by the GNU coreutils package
> so as to sort this file at the terminal with the following locale:
>
> LANG=en_US.UTF-8
> LANGUAGE=
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
>
> ... without changing locales the resulting ouput appears to be
> sorted the way it should be:
>
> A
> À
> E
> É
> È
> O
> Ô
> Œ
>
> But when I edit the file in vim and run the :sort / / where the '//'
> pattern contains a tab character (0x09) nothing happens.
>
> In other words... the fancy pants letters (À, È, É, Ô, Œ ) stay where
> they are instead of being moved to the spot where they belong.
>
> So I tried launching vim like so:
>
> $ LANG='fr_FR.UTF-8' vim
>
> I noticed that vim was now talking French to me and when I ran the
> ':language' commmand I saw that vim's locale-related variables were now
> set to the 'fr_FR' locale:
>
> Langue courante pour :
>
> "LC_CTYPE=fr_FR.UTF-8;
> LC_NUMERIC=C;
> LC_TIME=fr_FR.UTF-8;
> LC_COLLATE=fr_FR.UTF-8;
> LC_MONETARY=fr_FR.UTF-8;
> LC_MESSAGES=fr_FR.UTF-8;
> LC_PAPER=fr_FR.UTF-8;
> LC_NAME=fr_FR.UTF-8;
> LC_ADDRESS=fr_FR.UTF-8;
> LC_TELEPHONE=fr_FR.UTF-8;
> LC_MEASUREMENT=fr_FR.UTF-8;
> LC_IDENTIFICATION=fr_FR.UTF-8"
>
> But when I ran the same ':sort / /' command it didn't make any difference.
>
> Am I doing it wrong?
>
> Thanks,
>
> CJ
>
> P.S. I'm using a bit of vim trickery to translate the LaTeX '\index ...'
> etc. stuff to html tags so as to have a basic index with links to
> anchors in the HTML version of the document. Unfortunately the original
> document happens to be in French... and naturally... correct sorting of
> the 'TABLE ALPHABÉTIQUE' is crucial (I do want eggs/œufs to appear under
> letter 'O'... not relegated to the index's last page).
>
> I've read the ':h :sort' doc something like a dozen times and find parts
> of it a little cryptic. Especially when somewhere near the end it says:
> 'Vim does do a "stable" sort.' :-) What's up with that?

A "stable" sort is a sort which will keep lines with the same sort
keys in the order they were before the sort. (If you sort on whole
lines the difference is not visible, unless there exist different
lines which sort as equal, but if you sort on "pattern" or on "first
number" it may matter.)

But there is another few sentences which may be relevant in the help
for :sort, near the end, as follows:

<quote>
The details about sorting depend on the library function used. There is no
guarantee that sorting obeys the current locale. You will have to try it out.
</quote>

$LC_COLLATE is the part of the locale which says how to sort. if
$LC_ALL is set if overrides all the others, otherwise $LANG is used as
a fallback for any locale variable which is not set. ":lang" with no
arguments lists all settiings after taking care of $LANG and/or
$LC_ALL if present.

Best regards,
Tony.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXs_EgN%2Bd9vm1VJUu%3D92%3DR0t6RGXW3sjQZqtucKMeu53cg%40mail.gmail.com.

the :sort command does not appear to give expected result

Here's a (test) file that contains a sample of single characters from
the French alphabet.

Column 1 contains a <tab> character (0x09) and column 2 contains the
actual letters.

A
E
O
À
È
É
Ô
Œ

If I use the sort command provided on linux by the GNU coreutils package
so as to sort this file at the terminal with the following locale:

LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

... without changing locales the resulting ouput appears to be
sorted the way it should be:

A
À
E
É
È
O
Ô
Œ

But when I edit the file in vim and run the :sort / / where the '//'
pattern contains a tab character (0x09) nothing happens.

In other words... the fancy pants letters (À, È, É, Ô, Œ ) stay where
they are instead of being moved to the spot where they belong.

So I tried launching vim like so:

$ LANG='fr_FR.UTF-8' vim

I noticed that vim was now talking French to me and when I ran the
':language' commmand I saw that vim's locale-related variables were now
set to the 'fr_FR' locale:

Langue courante pour :

"LC_CTYPE=fr_FR.UTF-8;
LC_NUMERIC=C;
LC_TIME=fr_FR.UTF-8;
LC_COLLATE=fr_FR.UTF-8;
LC_MONETARY=fr_FR.UTF-8;
LC_MESSAGES=fr_FR.UTF-8;
LC_PAPER=fr_FR.UTF-8;
LC_NAME=fr_FR.UTF-8;
LC_ADDRESS=fr_FR.UTF-8;
LC_TELEPHONE=fr_FR.UTF-8;
LC_MEASUREMENT=fr_FR.UTF-8;
LC_IDENTIFICATION=fr_FR.UTF-8"

But when I ran the same ':sort / /' command it didn't make any difference.

Am I doing it wrong?

Thanks,

CJ

P.S. I'm using a bit of vim trickery to translate the LaTeX '\index ...'
etc. stuff to html tags so as to have a basic index with links to
anchors in the HTML version of the document. Unfortunately the original
document happens to be in French... and naturally... correct sorting of
the 'TABLE ALPHABÉTIQUE' is crucial (I do want eggs/œufs to appear under
letter 'O'... not relegated to the index's last page).

I've read the ':h :sort' doc something like a dozen times and find parts
of it a little cryptic. Especially when somewhere near the end it says:
'Vim does do a "stable" sort.' :-) What's up with that?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201027225540.GC5998%40turki.local.

Avoid quickfix override

I use linters (plugins like ALE), which use the quickfix window every time I enter a buffer or every time I edit the text, when I compile my program and I get a list of warnings and/or errors and I jump to one of them the quickfix get overrode by the linter plugin.

I know I can use :colder, :cnewer and :chistory, the problem is that sometimes the quickfix with the info of the compiler get wipe out when I do enough jumps and not to mention that it's too tedious being all the time switching between quickfix.

For now my idea is to turn off the quickfix every time I compile and turn it back with a command or a map when I am finish, but this is obviously a workaround.

Does someone of you got a better idea?, It would be great if the artist plugin has access to one instance of the quickfix and only his plugin can override that instance or give the user the possibility of locking one quickfix so when you open the quickfix window you always see the one you locked and make sure it doesn't get override.  

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/74a7f81d-d252-4261-ad46-9bb57d819d7fn%40googlegroups.com.

Re: Disable automatic indentation of a block that starts with number+period after issuing gw-type commands

On Mon, Oct 26, 2020 at 03:51:57PM EDT, Gary Johnson wrote:
> On 2020-10-26, Chris Jones wrote:
>
> It looks like you have the 'n' flag in 'formatoptions' set. Try
> executing this,
>
> :set fo-=n
>
> and reformatting that paragraph. If that's it, you can find the
> last place where 'formatoptions' was set with
>
> :verbose set fo?
>
> Hopefully, that will be the place where 'n' was added and you can
> fix it. Also see
>
> :help 'fo'
> :help fo-table
>
> I usually have 'n' included in my 'formatoptions', so I run into
> this problem occasionally. When I do, I shift the second line left
> (<<), then reformat the rest of the paragraph (gq}).

Removing the 'n' from that fo collection did the trick!

With the file I'm currently cleaning up this was driving me insane.

The place where it was set...? you guessed right... my own ~/.vimrc...!

Cleaning up that mess is about 20 years overdue...

Thanks,

CJ

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201027202041.GB5998%40turki.local.

Re: v:shell_error is 1 starting gvim

Solved, after bisecting all plugins, I found in one of mine this instruction which return bad shell error:

"   let g:Explorer_RubyLibPath=substitute(fnamemodify(system('which '.g:Explorer_RubyLibName),":p"),':..',':',"")

Now tagbar works as it did with Universal Ctags, see:

Le mardi 27 octobre 2020 à 10:08:23 UTC+1, Ni Va a écrit :

Hi,

v:shell_error is 1 starting vim, how can I retrieve last shell command executed ?

It broke plugin such as tagbar.vim

Thank you

NiVa

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/d9c2c829-0f87-4337-84a7-d0175d5140f7n%40googlegroups.com.

Re: v:shell_error is 1 starting gvim

Hi Gary and thank you for your answer.

I have a different approach to the problem.

Looking at the code of the script tagbar.vim version 2.7, line 640 if v:shell_error ctags_output! Universal) Ctags'?

 I note that the author as elsewhere written in the help of tagbar, seeks to see if it is either Exuberant or Universal Ctags. So the two executables are compatible. 

And after a few tests I note that my problem comes from the condition v:shell_error which ends up at 1 for a reason unknown to me ... or at least I think it comes from one of my plugins:=>  because when I launch Vim with the option -u NONE, this variable is at 0. 

So I'm still in investigation. Thank you  

Le mardi 27 octobre 2020 à 18:13:12 UTC+1, Gary Johnson a écrit :

On 2020-10-27, Ni Va wrote:
> Got this verbose report in level 4 just after opening tagbar.vim and try toggle
> tagbar.
>
> sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim"
> filetype detection:ON plugin:ON indent:ON
> finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim
> line 1: sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\
> debug.vim"
> finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\
> debug.vim
> continuing in <SNR>148_ToggleWindow
> Tagbar: Ctags doesn't seem to be Exuberant Ctags!
> BSD ctags will NOT WORK. Please download Exuberant Ctags from
> ctags.sourceforge.net and install it in a directory in your $PATH or set
> g:tagbar_ctags_bin.
> Executed command: "D:\Logiciels\Vim\vim82\ctags.exe --version"
> Command output:
> Universal Ctags 5.9.0(5d000b1a), Copyright (C) 2015 Universal Ctags Team^M
> Universal Ctags is derived from Exuberant Ctags.^M
> Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert^M
> Compiled: Oct 26 2020, 01:20:04^M
> URL: https://ctags.io/^M
> Optional compiled features: +win32, +wildcards, +regex, +internal-sort,
> +unix-path-separator, +iconv, +option-directory, +xpath, +json, +interactive,
> +yaml, +case-insensitive-filenames, +packcc^M
> Exit code: 1 >> v:shell_error

As the error message says, the tagbar plugin was written to use
Exuberant Ctags and will not work with BSD ctags. The author tries
to verify that the required version of ctags is being used by
executing "ctags --version". The problem is that tagbar does not
recognize the Universal Ctags you are using, which is an improved
and supported derivative of Exuberant Ctags.

Universal Ctags should work as well if not better than Exuberant
Ctags. There is one irritating incompatibility between the two:
the author of Universal Ctags changed the spelling of the "--extra"
option "--extras". A plugin that uses that option but knows the
ctags version can work around that.

I think the best solution here is to modify tagbar.vim, either
yourself or by contacting the author, so that it accepts Universal
Ctags as well as Exuberant Ctags.

You could install Exuberant Ctags and make sure it is earlier in
your PATH than Universal Ctags, but since the former is unsupported
and not as capable, I wouldn't recommend that.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/f47f3c7b-cc6d-4b07-b822-2d27574a4e31n%40googlegroups.com.

Re: v:shell_error is 1 starting gvim

On 2020-10-27, Ni Va wrote:
> Got this verbose report in level 4 just after opening tagbar.vim and try toggle
> tagbar.
>
> sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim"
> filetype detection:ON plugin:ON indent:ON
> finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim
> line 1: sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\
> debug.vim"
> finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\
> debug.vim
> continuing in <SNR>148_ToggleWindow
> Tagbar: Ctags doesn't seem to be Exuberant Ctags!
> BSD ctags will NOT WORK. Please download Exuberant Ctags from
> ctags.sourceforge.net and install it in a directory in your $PATH or set
> g:tagbar_ctags_bin.
> Executed command: "D:\Logiciels\Vim\vim82\ctags.exe --version"
> Command output:
> Universal Ctags 5.9.0(5d000b1a), Copyright (C) 2015 Universal Ctags Team^M
> Universal Ctags is derived from Exuberant Ctags.^M
> Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert^M
> Compiled: Oct 26 2020, 01:20:04^M
> URL: https://ctags.io/^M
> Optional compiled features: +win32, +wildcards, +regex, +internal-sort,
> +unix-path-separator, +iconv, +option-directory, +xpath, +json, +interactive,
> +yaml, +case-insensitive-filenames, +packcc^M
> Exit code: 1 >> v:shell_error

As the error message says, the tagbar plugin was written to use
Exuberant Ctags and will not work with BSD ctags. The author tries
to verify that the required version of ctags is being used by
executing "ctags --version". The problem is that tagbar does not
recognize the Universal Ctags you are using, which is an improved
and supported derivative of Exuberant Ctags.

Universal Ctags should work as well if not better than Exuberant
Ctags. There is one irritating incompatibility between the two:
the author of Universal Ctags changed the spelling of the "--extra"
option "--extras". A plugin that uses that option but knows the
ctags version can work around that.

I think the best solution here is to modify tagbar.vim, either
yourself or by contacting the author, so that it accepts Universal
Ctags as well as Exuberant Ctags.

You could install Exuberant Ctags and make sure it is earlier in
your PATH than Universal Ctags, but since the former is unsupported
and not as capable, I wouldn't recommend that.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20201027171238.GA11165%40phoenix.

Re: v:shell_error is 1 starting gvim

Got this verbose report in level 4 just after opening tagbar.vim and try toggle tagbar.

sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim"

filetype detection:ON  plugin:ON  indent:ON

finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar.vim

line 1: sourcing "D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\debug.vim"

finished sourcing D:\Logiciels\Vim\vimfiles\plugged\tagbar\autoload\tagbar\debug.vim

continuing in <SNR>148_ToggleWindow

Tagbar: Ctags doesn't seem to be Exuberant Ctags!

BSD ctags will NOT WORK. Please download Exuberant Ctags from ctags.sourceforge.net and install it in a directory in your $PATH or set g:tagbar_ctags_bin.

Executed command: "D:\Logiciels\Vim\vim82\ctags.exe --version"

Command output:

Universal Ctags 5.9.0(5d000b1a), Copyright (C) 2015 Universal Ctags Team^M

Universal Ctags is derived from Exuberant Ctags.^M

Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert^M

  Compiled: Oct 26 2020, 01:20:04^M

  URL: https://ctags.io/^M

  Optional compiled features: +win32, +wildcards, +regex, +internal-sort, +unix-path-separator, +iconv, +option-directory, +xpath, +json, +interactive, +yaml, +case-insensitive-filenames, +packcc^M

Exit code: 1                           >> v:shell_error                                 

Le mardi 27 octobre 2020 à 10:37:59 UTC+1, Ni Va a écrit :

I got that output executing this command :

5verbose let out=system(expand('$vimruntime/ctags.exe --version') ) | put=out | put=v:shell_error

Universal Ctags 5.9.0(5d000b1a), Copyright (C) 2015 Universal Ctags Team

Universal Ctags is derived from Exuberant Ctags.

Exuberant Ctags 5.8, Copyright (C) 1996-2009 Darren Hiebert

  Compiled: Oct 26 2020, 01:20:04

  URL: https://ctags.io/

  Optional compiled features: +win32, +wildcards, +regex, +internal-sort, +unix-path-separator, +iconv, +option-directory, +xpath, +json, +interactive, +yaml, +case-insensitive-filenames, +packcc

0  

Le mardi 27 octobre 2020 à 10:13:16 UTC+1, cbl...@256bit.org a écrit :

On Di, 27 Okt 2020, Ni Va wrote:

> Hi,
>
> v:shell_error is 1 starting vim, how can I retrieve last shell command executed
> ?
>
> It broke plugin such as tagbar.vim

Set the verbose option to 4 and verbosefile to log the verbose messages
and check the resulting logfile for the shell commands executed.


Best,
Christian
--
Trinkt der Bauer und fährt Traktor, wird er zum Gefahrenfaktor.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/dc0af472-913f-4f73-9e80-c92dbd860bc3n%40googlegroups.com.