netrw

[Charles E Campbell]

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


Regards,
Chip Campbell

--
--
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'm getting a "critical" murrine_style_draw_box assertion error/warning

[Charles E Campbell]

Christian Brabandt wrote:
> On Mi, 14 Feb 2018, Charles E Campbell wrote:
>
>> [D]fsp#03 cec/ xorn? gvim -u NONE -U NONE
>>
>> ** (gvim:4731): CRITICAL **: murrine_style_draw_box: assertion 'height
>>> = -1' failed
>>
>> Hello:
>>
>> However, it doesn't prevent gvim from starting up (it appears to be a
>> gtk issue, actually).
>>
>> So, I use:
>>
>> gvim -u NONE -U NONE  2> /dev/null
>>
>> so the error/warning message gets routed out-of-sight.
>>
>> Chip Campbell
>>
>> vim --version : 8.0.1520
>> O/S: Scientific Linux 7.3 (Nitrogen)
>> pkg-config --modversion gtk+-2.0 : 2.24.28
>> pkg-config --modversion gtk+-3.0 : 3.14.13
>> I also use Mate (https://mate-desktop.org/)
> Google suggests, that this is a theme problem and occurs with the 
> Ambience and Radience theme (or whatever it is called).
> Here is a fix from Ubuntu launchpad:
> https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/538499/comments/24

Well, that's interesting.  I spent a little time trying to find out what
my current gtk theme is.  I saw gtkrc mentioned several times, so I
found .gtkrc in my home directory -- and it holds the following text:

# -- THEME AUTO-WRITTEN DO NOT EDIT
include "/usr/share/themes/Bluecurve/gtk/gtkrc"
# -- THEME AUTO-WRITTEN DO NOT EDIT

However, /usr/share/themes/Bluecurve doesn't exist.  I suspect that
non-existence of the theme is responsible for those assertion messages
I've been getting.

Thanks!
Chip Campbell


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

I'm getting a "critical" murrine_style_draw_box assertion error/warning

[Charles E Campbell]

[D]fsp#03 cec/ xorn? gvim -u NONE -U NONE

** (gvim:4731): CRITICAL **: murrine_style_draw_box: assertion 'height
>= -1' failed


Hello:

However, it doesn't prevent gvim from starting up (it appears to be a
gtk issue, actually).

So, I use:

gvim -u NONE -U NONE  2> /dev/null

so the error/warning message gets routed out-of-sight.

Chip Campbell

vim --version : 8.0.1520
O/S: Scientific Linux 7.3 (Nitrogen)
pkg-config --modversion gtk+-2.0 : 2.24.28
pkg-config --modversion gtk+-3.0 : 3.14.13
I also use Mate (https://mate-desktop.org/)

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

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

Re: [vim/vim] Wrong highlighting in latex (#2433)

[Charles E Campbell]

K.Takata wrote:
>
> Dr. Chip commented at
> https://groups.google.com/d/msg/vim_dev/Q1YYNLNNes4/E0UC9zQvBwAJ .
> (I don't know why his comment is reflected here.)
>
>
Because the email showed up as email to the vim mailing list.

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

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

Re: [vim/vim] Wrong highlighting in latex (#2433)

[Charles E Campbell]

Urbain Vaes wrote:
>
> Hi!
>
> When I edit the following document with |vim -N -u NONE|,
>
> |\documentclass{article} \usepackage{amsmath} \begin{document}
> \begin{subequations} \begin{align} &1 + 1 = 2 \\ &2 + 2 = 4
> \end{align} \end{subequations} \end{document} |
>
> and use |:syntax on|, the line |\end{subequations}| appears as an
> error, although I believe this is correct latex code.
>
>
Hello:

Looks like a "leftover" problem.  I've been trying to remove all package
related information from syntax/tex.vim.  Instead, you should use add-on
syntax highlighting for packages.

 * you can get an updated syntax/tex.vim from my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX .
 * you can get an add-on syntax package for amsmath also from my
website: http://www.drchip.org/astronaut/vim/index.html#LATEXPKGS

Regards,
Chip Campbell


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

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

Re: [vim/vim] Minor grammar fix for docs (#1889)

[Charles E Campbell]

KingCaper wrote:
>
> Change "an URL" to "a URL".
>
> 
>
The crux of this is whether or not "url" has moved into the dictionary
as a word on its own.  As an acronym, it should be referred to as "URL"
(note the caps), and so "a URL" is appropriate (because the "U" is a
long u when treated as an acronym), and so "a URL" is appropriate.

However, as a word, url has a short-u start and so should be referred to
as "an url".

So more changes are needed -- all the "url"s will become "URL"s.  I'm
afraid that I never referred to any URLs in the pi_netrw.txt file, just
urls, so the change "an URL" to "a URL" isn't quite right either (while
we're in pedantic mode).

Chip Campbell

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

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

Re: [vim/vim] add rand(), srand() (#1277)

[Charles E Campbell]

Yegappan Lakshmanan wrote:
>
>> Mines.vim, which generates a minefield, does so using a pseudo-random
>> number generator (which comes with it, btw, since I wrote that in vim).
>>
> I leveraged your pseudo-random number generator for the battleship
> game Vim plugin. (https://github.com/yegappan/battleship).
>
> - Yegappan
>
Thank you, Yegappan, for telling me!
Chip

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

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

Re: [vim/vim] add rand(), srand() (#1277)

[Charles E Campbell]

Bram Moolenaar wrote:
>
> Yasuhiro Matsumoto wrote:
>
> > This add Xorshift random generator. In general implementation, srand()
> > may be called from some plugins in several times. So it need to have
> > statefull random generator like Xorshift. Below is an usage of
> > srand().
> >
> > ```vim
> > :echo srand()
> > [123456789, 362436069, 521288629, 88675123]
> > :echo srand(-1)
> > [1479837050,, 362436069, 521288629, 88675123]
> > :echo srand(2)
> > [2, 362436069, 521288629, 88675123]
> > ```
> > srand return four numbers as list. When expr is not given, the x
> element of xorshift become 123456789. When negative number is given, x
> become time(NULL). When positive number is given, x become it given.
> >
> > Below is an usage of rand()
> >
> > ```vim
> > let a = srand()
> > :echo rand(a)
> > 597902826
> > :echo rand(a)
> > 458295558
> > :echo rand(a)
> > 1779455562
> > :echo rand(a)
> > 663552176
> > :echo rand(a)
> > 507026878
> > ```
>
> What plugin needs a pseudo-random number generator?
Mines.vim, which generates a minefield, does so using a pseudo-random
number generator (which comes with it, btw, since I wrote that in vim).

Regards,
Chip Campbell

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

updated vim to 8.0.642 and am getting messages

[Charles E Campbell]

Hello:

I just got around to updating vim -- and am now getting a "critical"
error message.

** (gvim:1416): CRITICAL **: murrine_style_draw_box: assertion 'width >=
-1' failed

o/s: Scientific Linux 7.3 (Nitrogen)

to configure: ./configure --with-features=huge --enable-gui=gtk2
--enable-perlinterp --enable-pythoninterp --enable-rubyinterp  
--enable-cscope

./vim --version :

VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jun 15 2017 12:11:58)
Included patches: 1-642
Compiled by cecam...@gs-mesa-xorn.gsfc.nasa.gov
Huge version with GTK2 GUI.  Features included (+) or not (-):
+acl +file_in_path+mouse_sgr   +tag_old_static
+arabic  +find_in_path-mouse_sysmouse  -tag_any_white
+autocmd +float   +mouse_urxvt -tcl
+balloon_eval+folding +mouse_xterm +termguicolors
+browse  -footer  +multi_byte  +terminfo
++builtin_terms  +fork()  +multi_lang  +termresponse
+byte_offset +gettext -mzscheme+textobjects
+channel -hangul_input+netbeans_intg   +timers
+cindent +iconv   +num64   +title
+clientserver+insert_expand   +packages+toolbar
+clipboard   +job +path_extra  +user_commands
+cmdline_compl   +jumplist+perl+vertsplit
+cmdline_hist+keymap  +persistent_undo +virtualedit
+cmdline_info+lambda  +postscript  +visual
+comments+langmap +printer +visualextra
+conceal +libcall +profile +viminfo
+cryptv  +linebreak   +python  +vreplace
+cscope  +lispindent  -python3 +wildignore
+cursorbind  +listcmds+quickfix+wildmenu
+cursorshape +localmap+reltime +windows
+dialog_con_gui  -lua +rightleft   +writebackup
+diff+menu-ruby+X11
+digraphs+mksession   +scrollbind  -xfontset
+dnd +modify_fname+signs   +xim
-ebcdic  +mouse   +smartindent +xpm
+emacs_tags  +mouseshape  +startuptime +xsmp_interact
+eval+mouse_dec   +statusline  +xterm_clipboard
+ex_extra-mouse_gpm   -sun_workshop-xterm_save
+extra_search-mouse_jsbterm   +syntax 
+farsi   +mouse_netterm   +tag_binary 
   system vimrc file: "$VIM/vimrc"
 user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
  user exrc file: "$HOME/.exrc"
  system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
   defaults file: "$VIMRUNTIME/defaults.vim"
system menu file: "$VIMRUNTIME/menu.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK  -pthread
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15
-I/usr/include/libdrm -I/usr/include/harfbuzz -g -O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1  
Linking: gcc   -Wl,--enable-new-dtags -Wl,-rpath,/usr/lib64/perl5/CORE  
-L/usr/local/lib -Wl,--as-needed -o vim   -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
-lcairo -lpango-1.0 -lfontconfig -lgobject-2.0 -lglib-2.0 -lfreetype  
-lSM -lICE -lXpm -lXt -lX11 -lSM -lICE  -lm -ltinfo -lelf -lnsl 
-lselinux  -lacl -lattr -ldl   -Wl,--enable-new-dtags
-Wl,-rpath,/usr/lib64/perl5/CORE  -fstack-protector 
-L/usr/lib64/perl5/CORE -lperl -lresolv -lnsl -ldl -lm -lcrypt -lutil
-lpthread -lc -L/usr/lib64/python2.7/config -lpython2.7 -lpthread -ldl
-lutil -lm -Xlinker -export-dynamic

So I tried configuring with gtk3; I now get the following messages with
.vim -g :
(gvim:5903): Gtk-WARNING **: GtkNotebook 0x1d831d0 is mapped but visible
child GtkEventBox 0x1d85160 is not mapped

(gvim:5903): Gtk-WARNING **: GtkNotebook 0x1d831d0 is mapped but visible
child GtkEventBox 0x1d85160 is not mapped
fsp#20 src/ xorn?
(gvim:5903): Gtk-WARNING **: GtkNotebook 0x1d831d0 is mapped but visible
child GtkEventBox 0x1d85160 is not mapped

(gvim:5903): Gtk-WARNING **: GtkNotebook 0x1d831d0 is mapped but visible
child GtkEventBox 0x1d85160 is not mapped

(gvim:5903): Gtk-WARNING **: GtkNotebook 0x1d831d0 is mapped but visible
child GtkEventBox 0x1d85160 is not mapped

I think I'll continue to use my older version of vim for the nonce.
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Mar 13 2017 15:53:41)
Included patches: 1-446, 446-455

Regards,
Chip Campbell

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

Re: [vim/vim] Bash substring removal breaks syntax highligh if pattern contains an open curly braces (#1750)

[Charles E Campbell]

Henry John Kupty wrote:
>
> Hi.
>
> The following snippet breaks the syntax highlight, making it consider
> from this check onwards until the end of the file a string:
>
> if [ -n "${arg%{*}" ]; then
>   echo $arg
> fi
>
> Trying to work around the bug by adding a comment closing the block
> makes it even worse:
>
> if [ -n "${arg%{*}" ]; then #}"
>   echo $arg
> fi
>
> I tested this on vim 8.0.
>
> Thanks in advance!
>
>
I suspect that what you want is:

if [ -n "${arg%{*}}" ]; then
  echo $arg
fi Note the additional closing curly brace. Regards, Chip Campbell


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

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

Re: [vim/vim] Unified spellings "VIM" to "Vim" and "GVIM" or "Gvim" or "gVim" to "gvim" in help documents (#1733)

[Charles E Campbell]

Tatsuki wrote:
>
> Unified spellings "VIM" to "Vim" and "GVIM" or "Gvim" or "gVim" to
> "gvim" in help documents.
>
> 
>
>
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/vim/vim/pull/1733
>
>
> Commit Summary
>
>   * Change spelling VIM to Vim and GVIM or Gvim or gVim to gvim
>
>
> File Changes
>
>   * *M* runtime/doc/arabic.txt
>  (40)
>   * *M* runtime/doc/autocmd.txt
>  (2)
>   * *M* runtime/doc/editing.txt
>  (4)
>   * *M* runtime/doc/ft_ada.txt
>  (2)
>   * *M* runtime/doc/gui_w32.txt
>  (4)
>   * *M* runtime/doc/hangulin.txt
>  (16)
>   * *M* runtime/doc/help.txt
>  (2)
>   * *M* runtime/doc/if_ole.txt
>  (4)
>   * *M* runtime/doc/if_perl.txt
>  (6)
>   * *M* runtime/doc/intro.txt
>  (8)
>   * *M* runtime/doc/map.txt
>  (8)
>   * *M* runtime/doc/mbyte.txt
>  (2)
>   * *M* runtime/doc/netbeans.txt
>  (4)
>   * *M* runtime/doc/os_beos.txt
>  (2)
>   * *M* runtime/doc/os_vms.txt
>  (24)
>   * *M* runtime/doc/os_win32.txt
>  (4)
>   * *M* runtime/doc/pi_getscript.txt
>  (8)
>   * *M* runtime/doc/pi_netrw.txt
>  (4)
>   * *M* runtime/doc/print.txt
>  (64)
>   * *M* runtime/doc/quotes.txt
>  (116)
>   * *M* runtime/doc/spell.txt
>  (22)
>   * *M* runtime/doc/sponsor.txt
>  (4)
>   * *M* runtime/doc/usr_02.txt
>  (2)
>   * *M* runtime/doc/usr_08.txt
>  (4)
>   * *M* runtime/doc/usr_09.txt
>  (6)
>   * *M* runtime/doc/usr_21.txt
>  (4)
>   * *M* runtime/doc/usr_31.txt
>  (2)
>   * *M* runtime/doc/version5.txt
>  (2)
>   * *M* runtime/doc/version6.txt
>  (18)
>   * *M* runtime/doc/version7.txt
>  (122)
>
>
> Patch Links:
>
>   * https://github.com/vim/vim/pull/1733.patch
>   * https://github.com/vim/vim/pull/1733.diff
>
>
For netrw: all the characters in a subtitle are in caps.  DON'T CHANGE
GVIM in such a title to gvim .  Please.   Similarly, don't change VIM to
Vim in such a title.
Also, you'll find in pi_netrw.txt a usage of GVIM associated with
v:servername.  Changing GVIM to gvim would not simply be disconcerting,
it'd be wrong.
The only place where arguably such a change would be acceptable is in
the licensing where it refers to the "VIM LICENSE"; in which case, it
should be "Vim license".

I don't have time to run through all your changes; you need to make sure
you're not messing with VIM or GVIM when it has to do with remote server
names (ex. :he clientserver, then search for "...running GVIM server...".

Regards,
Chip Campbell

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

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

Re: [vim/vim] netrw-mf with g:netrw_liststyle =3 (#1692)

[Charles E Campbell]

Maxim Kolodyazhny wrote:
>
> VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 03 2017 12:11:53)
> Included patches: 1-313, 315-596
>
> |../ foo/ | bar/ | | file.txt | file.txt |
>
> If I press mf on file.txt, both files will be marked
>
>
Actually, both files are highlighted; only one is actually marked.  See 
:help netrw-mf and look for "Known Problem".

Regards,
Chip Campbell

-- 
-- 
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: bash syntax highlighting for quoted heredoc terminals incorrect(?)

[Charles E Campbell]

Ted Lilley wrote:
> read myvar <<'  EOS'
> some string text
>   EOS
Hello:

First I saw your email -- wonder where it was bouncing.  Did you try
removing the embedded NOSPAM from the email address you used for me?

Anyway, please try
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH and see if that
version of syntax/sh.vim fixes your issue.

Regards,
Chip Campbell

-- 
-- 
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: Security Risk: (was vim 'less.sh' script probs w/folds)

[Charles E Campbell]

Christian Brabandt wrote:
> On Do, 30 Mär 2017, Bram Moolenaar wrote:
>
>> Pity "z" is a command in less, thus we can't use "zR".  I doubt it's
>> used much.  Would it be too weird to skip the map for "z" if there are
>> folds in the file?
> I wouldn't worry at all and simply use the Vim z maps.
>
That would affect a "less" power user.   I've used less for decades and
never noticed the z; according to the manual, all it does is affect the
window size (or acts the same as space).
I rather agree with Christian on this -- simply use the vim z maps.

Chip Campbell

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

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

Re: [vim/vim] Invalid syntax highlighting inside string literals - it detects /* as a starting line for a comment (#1584)

[Charles E Campbell]

Tony Mechelynck wrote:
> On Wed, Mar 29, 2017 at 4:07 PM, Charles E Campbell
> <drc...@campbellfamily.biz> wrote:
>> Simon Cornelius P. Umacob wrote:
>>> examplejs
>>> <https://cloud.githubusercontent.com/assets/128593/24188811/b74f1c68-0f1d-11e7-856c-2c1f19b44564.png>
>>>
>>> Copy-pasteable:
>>>
>>> |const init_env =` for i in \`ls
>>> ${process.env['LAMBDA_TASK_ROOT']}/bin/*\`; do echo $i done `; |
>>>
>> Hello:
>>
>> Some questions for you...
>>
>>  * what language is this for?
>>  * I don't even see a /* in the example, so I don't see how that could
>> be affecting the highlighting
> There is /*\ at the end of the backtick-quoted text, but AFAICT it is
> not within single- or double-quoted text. That /*\ and everything
> following it are highlighted in blue.
>
>>  * have you tried contacting the maintainer of the syntax highlighting
>> supporting whatever language you're using?  (look into the syntax
>> highlighting file, you'll likely find a "Maintainer" comment therein)
>>
Hello, Tony:

Yep, you're right, /* is there.  Still, what language is it for?  It
almost looks like shell script, which would be something I should
handle, but const isn't a shell-script keyword (for sh/bash/ksh/posix),
or at least not as currently done.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Invalid syntax highlighting inside string literals - it detects /* as a starting line for a comment (#1584)

[Charles E Campbell]

Simon Cornelius P. Umacob wrote:
>
> examplejs
> 
>
> Copy-pasteable:
>
> |const init_env =` for i in \`ls
> ${process.env['LAMBDA_TASK_ROOT']}/bin/*\`; do echo $i done `; |
>
Hello:

Some questions for you...

 * what language is this for?
 * I don't even see a /* in the example, so I don't see how that could
be affecting the highlighting
 * have you tried contacting the maintainer of the syntax highlighting
supporting whatever language you're using?  (look into the syntax
highlighting file, you'll likely find a "Maintainer" comment therein)

Regards,
Chip Campbell

-- 
-- 
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: gvim and geometry

[Charles E Campbell]

Kazunobu Kuriyama wrote:
> 2017-03-25 5:14 GMT+09:00 Charles E Campbell
> <drc...@campbellfamily.biz <mailto:drc...@campbellfamily.biz>>:
>
> Hello:
>
> On at least two machines, which both run Scientific Linux, I'm getting
> odd behavior with a -geometry command:
>
> gvim -geometry "316x40+0-0" somefile
>
> The file is opened on the bottom of the screen (316x40, open 0 pixels
> from left and 0 pixels from the bottom).
> Or, at least, that's what its supposed to do.  Sometimes it opens 0
> pixels from the top of the screen instead.
>
> I haven't found a way to get the problematic opening to occur with
> regularity -- I just did it ten times and it opened correctly, for
> example.
>
> Regards,
> Chip Campbell
>
>
> Hi Dr. Chip, 
>
> First of all, I think we need to make sure how the geometry of an X11
> app is determined when it appears on the screen for the first time.
>
> That's a result of a negotiation between the window manager in use and
> an X11 app which is going to be substantiated on the screen.
>
> As the argument to -geometry is seemingly always honored by the window
> manager, it's natural that one might have an impression as if
> -geometry were a command.
>
> The reality is, however, that window managers are usually implemented
> to take the argument as a hint to compute another geometry which it
> thinks is suitable for the app's sharing the whole screen with other
> apps already appearing on the screen, based on the geometry management
> policy of each window manager.  The result of the computation is sent
> out to the X11 app under negotiation as an X11 event, and, by
> convention, the app is expected to follow the result as it it, not
> asking another negotiation.
>
> Accordingly, the geometry which is actually used is not the one given
> by the argument to -geometry, but the one the window manager computed,
> taking it as a hint and into account as such.
>
> Hence, it's not a surprise that X11 apps sometimes appear on the
> screen in a way failing one's expectation, depending on the geometry
> management policy of each window manager which is often subtle or obscure.
>
> In addition to that, I think we need to consider another factor
> specific to gvim.
>
> Usually, geometry negotiations are done with respect to the geometry
> of the top-level window of an app; it re-computes children's geometry
> based on the geometry allocated to the top-level window by the window
> manager.  It's really straightforward.
>
> As to gvim, when it computes its geometry, it puts more emphasis on
> the geometry of the text area than that of the top-level window. 
> Naturally, the numbers of columns and lines do matter much more for
> Vim than the values of x, y, width and height of the top-level window
> because it's THE text editor :)  Plus, as can be seen in the richness
> of 'guioptions', the text area is surrounded with GUI elements which
> can be added or removed arbitrarily even at runtime, which gets the
> computation far more involved than usual GUI apps.
>
> While following the geometry management convention, gvim is struggling
> to keep its values as a text editor.  The negotiation is always tough
> and sometime fails, unfortunately, though I know that's a thing to be
> improved.
>
Just thought I'd mention why I do this: I prefer a tiled display, and in
order to emulate how vim works I have gvim opening atop whatever window
I used to invoke it (I use the command line, not an icon, etc to do
that).  So, the space is there, its just not being utilized as I wish.

Regards, and thank you for your answer,
Chip Campbell

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

gvim and geometry

[Charles E Campbell]

Hello:

On at least two machines, which both run Scientific Linux, I'm getting
odd behavior with a -geometry command:

gvim -geometry "316x40+0-0" somefile

The file is opened on the bottom of the screen (316x40, open 0 pixels
from left and 0 pixels from the bottom).
Or, at least, that's what its supposed to do.  Sometimes it opens 0
pixels from the top of the screen instead.

I haven't found a way to get the problematic opening to occur with
regularity -- I just did it ten times and it opened correctly, for example.

Regards,
Chip Campbell

-- 
-- 
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] TeX: avoid indent after one-line environment (runtime/indent/tex.vim)

[Charles E Campbell]

Eisuke Kawashima wrote:
> Dear DrChip,
>
>> I suggest sending your patch to the indent/tex.vim maintainer.  It might
>> even get incorporated that way!
>>
>> Chip Campbell
>>
>> P.S. Look at $VIMRUNTIME/indent/tex.vim and you'll see YiChao's email
>> address.
> I put the maintainer's address in CC noted in the file, as you describe.
> Did I fail?
>
>
Hello, Eisuke Kawashima:

Sorry, I didn't check to see if the original email had the maintainer as
CC: or not.  Usually the general email list (vimdev) gets updates from
people who *don't* bother to tell the maintainer, and then if the
maintainer isn't active on the list, the update gets dropped.

Regards,
Chip Campbell

-- 
-- 
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] TeX: avoid indent after one-line environment (runtime/indent/tex.vim)

[Charles E Campbell]

Eisuke Kawashima wrote:
> Dear all and YiChao Zhou,
>
> Currently shiftwidth is inserted after a line containing \begin, which gives
>
> \begin{pmatrix} 0 \\ 1 \\ \end{pmatrix}
>   \begin{pmatrix} 1 \\ 0 \\ \end{pmatrix}
>
> This patch avoids indent after one-line environment, which gives
>
> \begin{pmatrix} 0 \\ 1 \\ \end{pmatrix}
> \begin{pmatrix} 1 \\ 0 \\ \end{pmatrix}
>
>
I suggest sending your patch to the indent/tex.vim maintainer.  It might
even get incorporated that way!

Chip Campbell

P.S. Look at $VIMRUNTIME/indent/tex.vim and you'll see YiChao's email
address.

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

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

Re: [vim/vim] Gvim spellcheck right-click change not consistently working (#1483)

[Charles E Campbell]

Jon Crall wrote:
>
> I have a latex document and in it I've spelled the word
> "intermittently" incorrectly as intermittenly.
>
> \documentclass[10pt,twocolumn,letterpaper]{article}
> \usepackage[T1]{fontenc}
> 
> \begin{document}
> 
> \title{A minimum working example of a bug}
> 
> The bug is that intermittenly is spelled wrong, and has a yellow squiggle.
> However, if I right click and select ``Change "intermittenly" to
>   intermittently'' it usually does nothing, but sometimes it will change 
> it.
> \end{document}
>
> Spell check correctly identifies the two instances of this with a
> yellow squiggle underneath. However, if I right click to fix it does
> not always work. I can't figure out the conditions to consistently
> reproduce the error.
>
> Typically nothing happens when I click change. However, sometimes it
> works and changes the word. Furthermore, if I undo the change and then
> right click and change again it typically does nothing again.
>
> I'm at a loss to what is causing this behavior.
>
> I've tested this with a very minimal .vimrc
>
> source $VIMRUNTIME/mswin.vim
> behave mswin
I have been able to duplicate this behavior.  Instead of using "behave
mswin", I use  setl mousemodel=popup which enables the menu (by default,
it appears to be mousemodel=extend, at least on my Linux system).

Regards,
Chip Campbell

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

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

Re: [vim/vim] Missing bracket in tex.vim (#1482)

[Charles E Campbell]

zdohnal wrote:
>
> Fix for missing bracket in tex.vim (patch is from vim-dev mailing
> list, created by Hirohito Higashi ). I did not see any pull request or
> issue here for this problem, so I created this pull request for this
> reason.
>
> 
>
Hello:

The latest syntax/tex.vim is available at my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX, v103.

The \langle and \rangle glyphs are double-wide, which can cause problems
with many fonts.  I've chosen to use < and > instead by default;
however, if one uses  set ambw  or has "let g:tex_usedblwidth= 1" in
one's .vimrc, then the double-width 〈〉glyphs will be used instead.

Regards,
Chip Campbell

-- 
-- 
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] Remove "VimL" and like word from Vim source tree

[Charles E Campbell]

h_east wrote:
> Hi Bram, Dr.Chip and list,
>
> I removed "VimL" and like word from Vim source tree.
>
> Related comment:
> https://groups.google.com/d/msg/vim_dev/3Z5yM8KER2w/wAqws0QSEAAJ
>
> Please check an attached patch.
>
>
>> Dr.Chip  (as a netrw author)
> There is also a "VimL" word in the help of netrw.
> I hope you accept the following changes.
>
> diff --git a/runtime/doc/pi_netrw.txt b/runtime/doc/pi_netrw.txt
> index 914c576..633dc87 100644
> --- a/runtime/doc/pi_netrw.txt
> +++ b/runtime/doc/pi_netrw.txt
> @@ -479,7 +479,7 @@ file using root-relative paths, use the full path:
>  
> ==
>  4. Network-Oriented File Transfer*netrw-xfer* {{{1
>  
> -Network-oriented file transfer under Vim is implemented by a VimL-based 
> script
> +Network-oriented file transfer under Vim is implemented by a Vim script
>  () using plugin techniques.  It currently supports both reading 
> and
>  writing across networks using rcp, scp, ftp or ftp+<.netrc>, scp, fetch,
>  dav/cadaver, rsync, or sftp.
>
>
Thank you -- but I'd already changed it.  Haven't posted it yet, though.
Chip Campbell

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

[Charles E Campbell]

James McCoy wrote:
> On Feb 10, 2017 10:04 AM, "Charles E Campbell"
> <drc...@campbellfamily.biz <mailto:drc...@campbellfamily.biz>> wrote:
>
> Bram Moolenaar wrote:
> > Charles Campbell wrote:
> >
> >> Maybe I was just lucky for years, but it seemed to me that the
> order of
> >> tags files (left to right in the tags option) and order of tags
> >> (top-to-bottom in the tags file) was important in resolving
> multiple
> >> tags with the same name.  That no longer seems to be the case,
> which
> >> makes it hard to avoid prototypes vs the actual function from being
> >> called up as the first tag (and system prototypes, too).
> >>
> >> So -- was I just lucky, or is a deliberate change, or
> (hopefully) an
> >> inadvertent effect that needs fixing?
> > Maybe caused by patch 8.0.0190?  It changes the linear search for
> > duplicates to using a hash table.  You could try using the
> version just
> > before it and see if that makes a change.
> >
> Is there a way to use git to build 8.0.189?  I suppose I can dust
> off my
> ftp scripts.
>
>
> Yes. From your clone of the repository, "git checkout v8.0.0189" will
> switch to the code for that tag.  After testing, you can use "git
> checkout master" to get back to the master branch.
>
Thank you, James.  I'll use that next time.
Chip Campbell

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

[Charles E Campbell]

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> Maybe I was just lucky for years, but it seemed to me that the order of
>> tags files (left to right in the tags option) and order of tags
>> (top-to-bottom in the tags file) was important in resolving multiple
>> tags with the same name.  That no longer seems to be the case, which
>> makes it hard to avoid prototypes vs the actual function from being
>> called up as the first tag (and system prototypes, too).
>>
>> So -- was I just lucky, or is a deliberate change, or (hopefully) an
>> inadvertent effect that needs fixing?
> Maybe caused by patch 8.0.0190?  It changes the linear search for
> duplicates to using a hash table.  You could try using the version just
> before it and see if that makes a change.
>
I'm having problems with applying the patches:

 * First, patch said, starting with the very first two patches, that the
patch appeared to be reversed, etc.

 * Not looking forward to telling patch to reverse 189 patches, I
removed vim80/ and extracted vim-8.0.tar again to start afresh.  I then
used patch -R .  Patch then complained that some of the patches were not
reversed.

 * Then I decided to repeat the removal of vim80/ and extraction of
vim-8.0 again, but this time using patch -f (which forces the patch no
matter which way it appeared to go).  I then got a lot of hunk failures;
vim would not compile.

I see that there's a vim-8.0.069 so I'm using that for tag testing.  vim
v8-69 honors my priority ordering and vim v8-282 does not.

I then applied patches 70-189 and built vim successfully.  (!)  So I
repeated tags testing: vim v8-189 honors my priority ordering.  vim
v8-190 also honors my priority ordering.  (by "honors priority ordering"
I mean that vim tags to the first match of multiple matches)

By bisection, the patch that introduces the problem is: patch#195.

Regards,
Chip Campbell

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

[Charles E Campbell]

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> Maybe I was just lucky for years, but it seemed to me that the order of
>> tags files (left to right in the tags option) and order of tags
>> (top-to-bottom in the tags file) was important in resolving multiple
>> tags with the same name.  That no longer seems to be the case, which
>> makes it hard to avoid prototypes vs the actual function from being
>> called up as the first tag (and system prototypes, too).
>>
>> So -- was I just lucky, or is a deliberate change, or (hopefully) an
>> inadvertent effect that needs fixing?
> Maybe caused by patch 8.0.0190?  It changes the linear search for
> duplicates to using a hash table.  You could try using the version just
> before it and see if that makes a change.
>
Is there a way to use git to build 8.0.189?  I suppose I can dust off my
ftp scripts.

Regards,
Chip Campbell

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

tag priority

[Charles E Campbell]

Hello:

Maybe I was just lucky for years, but it seemed to me that the order of
tags files (left to right in the tags option) and order of tags
(top-to-bottom in the tags file) was important in resolving multiple
tags with the same name.  That no longer seems to be the case, which
makes it hard to avoid prototypes vs the actual function from being
called up as the first tag (and system prototypes, too).

So -- was I just lucky, or is a deliberate change, or (hopefully) an
inadvertent effect that needs fixing?

Regards,
Chip Campbell

-- 
-- 
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] fixed small mistakes in documentation

[Charles E Campbell]

Dominique Pellé wrote:
> Hi
>
> Attached patch fixes a few minor mistakes in help files.
>
> Dominique
>
regardless vs irregardless -- doesn't matter, really; "irregardless" is
a commonly used albeit non-standard word (that appears, btw, in several
dictionaries).

About  "thirty-two" vs "thirty two" : see
https://www.grammarly.com/handbook/punctuation/hyphen/11/hyphen-in-compound-numbers/
.  Essentially, "thirty-two" is correct.

Regards,
Chip Campbell

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

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

Re: [vim/vim] sh.vim: Feature request - Better processing of bash's substring expansion (#1437)

[Charles E Campbell]

Norman Abramovitz wrote:
>
> Tried out 168 and still seeing the error.
>
> Uploading some screenshots showing the error colorization. Also
> uploaded some highlight colorization showing that colorization is an
> error colorization.
>
> screen shot 2017-02-06 at 9 30 39 am
> 
>
>
Hello:

As I mentioned earlier, I am not getting error highlighting with your
example script.  So, let's try to find out why  you are having this problem:

* when you edit the example above: what does:echo b:is_bash  show? 
(should show 1)
* try   vim -Vtmp yourscript   and see if "sourcing.*syntax\/sh.vim" is
in there, and its where you've put v168.

Regards,
Chip Campbell

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

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

Re: [vim/vim] sh syntax highlighting should ignore "[" in echo lines (#1445)

[Charles E Campbell]

matthew-cline wrote:
>
> If a syntax highlighted sh or bash script echoes out unbalanced "["s,
> like with ANSI color codes
> , this
> will mess up highlighting until balancing "]"s are placed in
> non-quoted, non-commented code. The syntax highlighter should just
> ignore those brackets.
>
> Of course, I can also deal with it by putting each open square bracket
> in quotes, but that's clunky, and users shouldn't have to go to the
> effort of having to figure that out.
>
>
This problem is more of a documentation omission, I think.  See if putting

  let g:sh_no_error= 1

in your .vimrc will fix things for you.

Regards,
Chip Campbell

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

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

Re: [vim/vim] sh.vim: Feature request - Better processing of bash's substring expansion (#1437)

[Charles E Campbell]

Norman Abramovitz wrote:
>
> A valid substring expansion that can be differentiated from the :-
> expansion should not show as an error.
>
> #!/bin/bash
> f() {
>   local last=${1: -1:1}
>   echo ${last}
> }
> f abc
>
I don't see any error highlighting with this; I'm using syntax/sh.vim
v168, which you can get from
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH .

Regards,
Chip Campbell

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

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

Re: [vim/vim] sh.vim: Syntax highlighting thinks quote does not close (#1008)

[Charles E Campbell]

Norman Abramovitz wrote:
>
> Still seeing incorrect syntax highlighting for shell scripts
>
> " Vim syntax file
> " Language: shell (sh) Korn shell (ksh) bash (sh)
> " Maintainer: Charles E. Campbell ndroch...@pcampbellafamily.mbiz
> <mailto:ndroch...@pcampbellafamily.mbiz>
> " Previous Maintainer: Lennart Schultz lennart.schu...@ecmwf.int
> <mailto:lennart.schu...@ecmwf.int>
> " Last Change: Sep 22, 2016
> " Version: 165
>
> #!/bin/bash
>
> a="\""
>
> # syntax highlighting is correct
> [[ "${a}" = [\"\'] ]] && {
> echo "found quote 1"
> }
>
> # syntax highlighting is incorrect (flipped around the quotes in [])
> [[ "${a}" = [\'\"] ]] && {
> echo found quote 2
> }
>
> —
>
I see no problem.  Of course, I'm using syntax/sh.vim v168.

Regards,
Chip Campbell

P.S. see http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH

-- 
-- 
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] fix syntax error in syntax/tex.vim

[Charles E Campbell]

h_east wrote:
> Hello Dr.Chip (as a maintainer of syntax/tex.vim)
>
> PS
> This issue was reported by YamaCIR-KIT.
>
> I am reporting on behalf.
>
> He/She found syntax error in syntax/tex.vim L514
> Comma is used instead of Right square bracket.
>
> Patch attached.
> Please check it.
>
> --
> Best regards,
> Hirohito Higashi (a.k.a. h_east)
>
Hello, Hirohito Higashi:

Thank you -- I've included it.  I guess that reveals that I don't use
ambw=double often.

Please also send thanks to YamaCIR-KIT if you can.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Scheme highlighting is not R7RS-compliant (#1424)

[Charles E Campbell]

vim-dev ML wrote:
> Hi Chris and Koz,
>
> I'm the author of that plugin and owner of the mysterious website, and
> just wanted to say I'd be happy to submit the files. I will want to take
> some time to clean them up and make sure they work on a stock Vim first,
> but once that's done I assume I can simply post them to this list, is
> that right?
>
> My one concern is about maintenance. I've chipped away at the plugin
> over time and tweak it as I find things that aren't quite right, and I'm
> sure I'll find more in the future. Are you happy for periodical updates
> to be posted as well?
>
Hello, Evan:

No need to post your updates to the list; instead, email them directly
to b...@moolenaar.net.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Correct syntax in lstlisting w/out g:tex_verbspell (#1417)

[Charles E Campbell]

Martin Ueding wrote:
>
> In my setup of Vim, |verbatim| environments get highlighted just fine.
> The |lstlisting| environments do not have any special syntax
> highlighting. Characters like |$| or |_| screw up the syntax
> highlighting of all the following LaTeX code although they are not
> supposed to be interpreted as LaTeX.
>
> From the source it seems that support for |lstlisting| is built-in, but
> for some reason only when |g:tex_verbspell| is available and enabled.
> The only difference between the two blocks seems to be the
> |contains=@Spell|, so I have just copied the |lstlisting| line to the
> other branch.
>
Actually, the correct thing to do here is to remove lstlisting entirely
from syntax/tex.vim.  Its defined via a package, and package syntax
should not be supported inside syntax/tex.vim.

To get lstlisting highlighted correctly, see:
http://www.drchip.org/astronaut/vim/index.html#LATEXPKGS .

Regards,
Chip Campbell

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

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

Re: [vim/vim] <C-]> issue using Portuguese-Brazil keyboard layout (#1378)

[Charles E Campbell]

Eduardo Sousa wrote:
>
> When I'm using a portuguese keyboard layout, and I press ||, vim
> identifies it as ||, which makes me unable to navigate help files
> using this kind of keyboards
>
>
Hello:

First, I have no idea what a portuguese keyboard layout is like.  I
doubt that vim is modifying what  is producing on its own; rather,
I suspect that your keyboard generates a  instead on its own. 
However,  you could make a nmap to do what you want:

  nmap  :echo "it works!"

If pressing  gives you the "it works" message, then:

  nno  

ought to work.

Regards,
Chip Campbell

-- 
-- 
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] broken link pi_logipat.txt in runtime/doc/help.txt

[Charles E Campbell]

Dominique Pellé wrote:
> Hi
>
> In Vim main help page (runtime/doc/help.txt),
> there is a link |pi_logipat.txt| which is broken.
>
> Fixed in attached patch.
>
Thank you, Dominique -- I'll include that change.  It is a leftover from
its incorporation as a part of vim.

Chip Campbell

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

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

Re: [vim/vim] netrw: Unexpected behaviour when g:netrw_altfile is set to 1 (#1246)

[Charles E Campbell]

Martin Vuille wrote:
>
> @cecamp  Any thoughts on this issue?
> I'm willing to try to diagnose it further, just need some general guidance
>
>
Hello:

My home computer is having problems, so I'm trying to get it working
properly again.

Presumably something needs a "keepalt" that currently doesn't have it. 
Tracking that sort of thing down can be tedious.  I'm hoping to try
Christian Brabandt's "breakpoint expr" patch; it doesn't appear to have
made it in vim v8 and use it to track down where @# changes.

Regards,
Chip Campbell

-- 
-- 
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: Netrw doesn't work on Windows correctly. Please permit us to modify code on github.com

[Charles E Campbell]

mattn wrote:
> Hi, Dr. Chip and list.
>
> I met some problems on netrw on Windows for  a long time. Most of operations 
> which use Windows commands of cmd.exe doesn't work because netrw checks the 
> command exists by executable(). The commands are defined like:
>
> let g:netrw_localcopycmd= expand("$COMSPEC")." /c copy"
>
> So executable() always return 0 on Windows.
>
> And I met more bugs about netrw.
>
> * mz (decompress) doesn't work
> * documentation bug about ms
>
> I'm sorry but I say netrw is often buggy. But I want to fix them. So I hope 
> you that put the code of netrw on github or somewhere. And please permit us 
> to modify the code of netrw for vim-dev or vim-jp.
>
What do you have  g:netrw_compress  and g:netrw_decompress set to? 
Windows does not provide such commands; one needs to install them and
tell netrw (via those settings) how to invoke them.

You don't like the maintainer model; I differ.  Many times I have had to
reject incorrect changes; the latest rejection was to the documentation
(for the production of :Lexplore windows being affected by
g:netrw_browse_split).  If you have suggestions, please send them to
me.  If you have error reports, please send them to me.  The more
information the better (ie. "netrw is buggy" is worthless) - give
commands that can invoke the problem, and mention what o/s  is in use
(also read :help netrw-debug).  Have a patch?  Send them to me (along
with what it fixes, commands to illustrate, etc).

Chip Campbell

-- 
-- 
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: Netrw doesn't work on Windows correctly. Please permit us to modify code on github.com

[Charles E Campbell]

mattn wrote:
> On Wednesday, November 9, 2016 at 10:53:08 PM UTC+9, Tony Mechelynck wrote:
>> On Wed, Nov 9, 2016 at 2:12 AM, mattn  wrote:
>>> On Wednesday, November 9, 2016 at 3:58:03 AM UTC+9, DrChip wrote:
 Cesar Romani wrote:
 Netrw actually doesn't check that expand("$COMSPEC") is execuable before
 setting up g:netrw_localcopycmd; instead, it uses that if netrw reports
 has("win32") || has("win95") || has("win64") || has("win16") is true and
 that g:netrw_cygwin is false.

 So, what should one use instead of expand("$COMSPEC"), and how do I
 detect that condition?  The expand("$COMSPEC") stuff used to work, so
 presumably Windows has changed things (and I'm primarily a Linux user).

 Alternatively, one may provide substitutes for the various commands:
 (ie. the command to be run as a string)

   g:netrw_localcopycmd
   g:netrw_localcopydircmd
   g:netrw_localmkdir
   g:netrw_localmovecmd
   g:netrw_localrmdir

 Please let me know what those commands are.
>>> Not different from autoload/netrw.vim is defined for. Problem is a checking 
>>> with executable().
>>>
>>> BTW, I want to hear the answer from you about permiting to modify your 
>>> codes to us.
>>>
>>> I'm thinking that current development speed is so wrong. This is NOT only 
>>> things about netrw. Many authors of third-party plugin/files are already 
>>> spoiled to keep development. And they doesn't know how many problems is 
>>> remaining on vim8.
>>> Dr Chip, for example, have you seen this?
>>>
>>> https://github.com/vim/vim/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20netrw
>>>
>>> Maybe, the problems occuring on users are not same that you know. I'm 
>>> guessing that this is a reason that netvim is started. We can implement 
>>> timer APIs, We can implement job APIs, We can implment channel APIs. But 
>>> that was slowly to start.
>>>
>>> We need contribute from users. And I'm thinking that we should be possible 
>>> to modify bundled files directly. If those are personaly plugin isolated 
>>> from vim, it won't be a problem. But those are bundled as vim runtime 
>>> files. So I hope that vim-dev should manage latest version. My opinion may 
>>> not be a correct answer for this problem. So if you have opinion about 
>>> this, please let me known.
>>>
>>> I'm very sorry to trouble you about my rude, but waiting your answer.
>>>
>>> Thanks.
>>> - mattn
>> On the Windows system where you noticed this problem, is the PATHEXT
>> environment variable set? If it is, try clearing it near the top of
>> your _vimrc (see ":help executable()").
> No, problem is simple.
>
> :echo executable("cmd.exe")
> 1
>
> :echo executable("cmd.exe /c copy")
> 0
>
> The command should be specified as filename not with arguments.
>
>
I don't have a windows box handy at the moment to test v162c of netrw
out; however, I've split the options off from the commands.  The
executable() test was supposed to be bypassed if the command was
$COMSPEC followed by a space or tab; apparently it was being invoked anyway.
You can get v162c from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW .

Regards,
Chip Campbell

-- 
-- 
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: Netrw doesn't work on Windows correctly. Please permit us to modify code on github.com

[Charles E Campbell]

Cesar Romani wrote:
> On 08/11/2016 04:08 a.m., mattn wrote:
> > Hi, Dr. Chip and list.
> >
> > I met some problems on netrw on Windows for  a long time. Most of
> > operations which use Windows commands of cmd.exe doesn't work because
> > netrw checks the command exists by executable(). The commands are
> > defined like:
> >
> > let g:netrw_localcopycmd= expand("$COMSPEC")." /c copy"
> >
> > So executable() always return 0 on Windows.
> >
> > And I met more bugs about netrw.
> >
> > * mz (decompress) doesn't work
> > * documentation bug about ms
> >
> > I'm sorry but I say netrw is often buggy. But I want to fix them. So I
> > hope you that put the code of netrw on github or somewhere. And please
> > permit us to modify the code of netrw for vim-dev or vim-jp.
>
> I can confirm it. It would be fine to fix netrw for Windows.
Netrw actually doesn't check that expand("$COMSPEC") is execuable before
setting up g:netrw_localcopycmd; instead, it uses that if netrw reports
has("win32") || has("win95") || has("win64") || has("win16") is true and
that g:netrw_cygwin is false.

So, what should one use instead of expand("$COMSPEC"), and how do I
detect that condition?  The expand("$COMSPEC") stuff used to work, so
presumably Windows has changed things (and I'm primarily a Linux user).

Alternatively, one may provide substitutes for the various commands: 
(ie. the command to be run as a string)

  g:netrw_localcopycmd
  g:netrw_localcopydircmd
  g:netrw_localmkdir
  g:netrw_localmovecmd
  g:netrw_localrmdir
 
Please let me know what those commands are.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Autoformat with gqgq is broken inside tex environments (#1223)

[Charles E Campbell]

Coacher wrote:
> On Friday, 4 November 2016 14:36:12 UTC+3, Antony Scriven  wrote:
>> That's because 'o' in 'indentkeys' is causing new lines to be
>> indented according to 'indentexpr'.
> Indeed, after 'set indentkeys-=o' gqgq works as expected in the case 
> described above.
> gqgq works as expected in non-tex files even with the default 'indentkeys' 
> setting, which includes 'o'.
>
So, to find out where it was last changed (if at all):  verbose set
indentkeys?

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

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

Re: [vim/vim] Autoformat with gqgq is broken inside tex environments (#1223)

[Charles E Campbell]

Coacher wrote:
> On Wednesday, 2 November 2016 23:50:57 UTC+3, DrChip  wrote:
>> Using 8.0.055, I get your expected results.  So, I suggest that you
>> check your plugins.
> AFAIU since I have '-u NONE' in cmdline, only system-wide plugins are 
> possibly in effect and I don't have any, except for plugin manager itself. 
> Since ~/.vimrc isn't processed, plugin manager is never activated. Please 
> correct me if I am wrong, but I don't see how my plugins can change anything 
> here.
>
>
Your example has  "filetype plugin indent on" -- that means that you
have plugins enabled, and anything in ~/.vim/plugin has been loaded (ie.
sourced).  Ditto for indent plugins.

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

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

Re: [vim/vim] Autoformat with gqgq is broken inside tex environments (#1223)

[Charles E Campbell]

Gary Johnson wrote:
> On 2016-11-02, Charles E Campbell wrote:
>> Coacher wrote:
>>> Consider the following file:
>>>
>>> \begin{env}
>>>  x 
>>>  x
>>> \end{env}
>>>
>>> Open it like this: vim -N -u NONE -c 'filetype plugin indent on' -c 'set ft=
>>> tex' 
>>> Place the cursor at the beginning of the second line.
>>> In Normal mode type 'gqgq' to format it.
>>>
>>> Actual results:
>>>
>>> \begin{env}
>>>  x
>>> 
>>> x
>>> \end{env}
>>>
>>> Expected results:
>>>
>>> \begin{env}
>>>  x
>>>  x
>>> \end{env}
>>>
>>> vim version is 8.0.0055.
>> Using 8.0.055, I get your expected results.  So, I suggest that you
>> check your plugins.
> With my normal setup, I get his expected results, too, but if I
> start Vim with the command shown, I get his actual results.
>
> I'd contact the maintainer of $VIMRUNTIME/indent/tex.vim, whose
> email address is at the top of the file.
>
>
I tried it with both my usual set up and with the command shown from the
shell command line.  Both times I get the "Expected" result.  So this
may be a tough problem to resolve if its dependent somehow on o/s.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Autoformat with gqgq is broken inside tex environments (#1223)

[Charles E Campbell]

Coacher wrote:
>
> Consider the following file:
>
> |\begin{env} 
> x
> 
> x \end{env} |
>
> Open it like this: |vim -N -u NONE -c 'filetype plugin indent on' -c
> 'set ft=tex' |
> Place the cursor at the beginning of the second line.
> In Normal mode type 'gqgq' to format it.
>
> Actual results:
>
> |\begin{env} 
> x
> 
> x \end{env} |
>
> Expected results:
>
> |\begin{env} 
> x
> 
> x \end{env} |
>
> vim version is 8.0.0055.
>
Using 8.0.055, I get your expected results.  So, I suggest that you
check your plugins.

Regards,
Chip Campbell

-- 
-- 
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: gvim and ASCII glyphs

[Charles E Campbell]

Matěj Cepl wrote:
> On 2016-10-27, 11:58 GMT, Tony Mechelynck wrote:
>> Ohhh, so that's what you mean. Well, here is another try: Not 
>> being imitated, or not being a copycat himself, don't 
>> necessarily mean that Dr. Chip is wrong, especially with Vim, 
>> which prides himself about allowing the users to obtain the 
>> same results by different means.
> I don't even know whether Dr. Chip was wrong when he invented 
> vimballs. His crystal ball was obviously a bit murky so he 
> haven’t expected git (and particularly GitHub) typhoon. Either 
> because of that or for whatever other reason vimballs really are 
> not that widespread as was expected when they became part of 
> vim. I believe it is time to accept the reality and move on.
>
Well, I don't intend to spend hours re-inventing my scripts which do a
lot of housekeeping and are responsible for updating my website, and
which work with vimballs.  Nor am I about to start keeping your and
other's git repositories up-to-date.  That said, I don't mind your git
repositories, its just that I won't be using them.

Bram asked me to come up with a vim-based way years ago to handle vim
plugins; that is the provenance of vimball.  Prior to that I myself used
tar and gzip.

Regards,
Chip Campbell

-- 
-- 
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: gvim and ASCII glyphs

[Charles E Campbell]

Matěj Cepl wrote:
> So, for example how to make >= and <= be included so that they 
> translate into (glyphs from :digraphs):
>
> =< ≤  8804
> >= ≥  8805
>
> Matěj
>
Hello:

If you're using utf-8, its easy to get the glyph transform with
mathmenu.vim (comes with
http://www.drchip.org/astronaut/vim/index.html#MATH):  type  >=, select
with visual-block (ctrl-v), then press the "&" key.  Same sort of thing
for <=, too.
Lower case: select letter(s), press "_".  Upper case: select letter(s),
press "^".  Etc.

You'll also find an example with:
http://www.drchip.org/images/example_math.png .  Enable it by typing
":Math".

Regards,
Chip Campbell

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

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

Re: [vim/vim] fix syntax error in runtime/autoload/netrw.vim (#1090)

[Charles E Campbell]

haya14busa wrote:
>
> Closed #1090 .
>
>
Thank you -- I've applied your patches, albeit to a later netrw than you
used (v162bNR).  I need to work on it some more before releasing it.

Regards,
Chip Campbell

-- 
-- 
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: gx doesn't work anymore with vim 8.0.4

[Charles E Campbell]

Cesar Romani wrote:
> I'm using vim 8.0.4 on Windows 7 compiled with MinGW.
> When doing gx on an url I get:
>
> E117: Unknown function: netrw#CheckIfRemote
> E116: Invalid arguments for function netrw#BrowseX
>
> Many thanks in advance,
netrw#CheckIfRemote is in v156 which is distributed with vim 8.  So,
check paths/permissions/placement; for example, is netrw.vim in your
autoload directory?  Is your $VIMRUNTIME correct?  etc..

Regards,
Chip Campbell

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

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

Re: [vim/vim] Runtime files do not include sbt.vim (#1051)

[Charles E Campbell]

Denton Liu wrote:
>
> Inside |runtime/compiler|, a file is missing, |sbt.vim|, which can be
> found here
> . This
> is because |ftplugin/scala.vim|
> 
> requires |sbt| in order to be sourced.
>
> Currently, I am getting this error when I'm loading any |*.scala| files:
>
> |Error detected while processing
> /usr/share/vim/vim74/ftplugin/scala.vim: line 35: E666: compiler not
> supported: sbt |
>
Hello:

I have vim v7.4.2351, huge version:

 * the string "sbt" does not appear in ftplugin/scala.vim (actually,
fgrep sbt *.vim in that directory shows that it doesn't appear anywhere
in that directory)
 * vim -u NONE -N junk.scala does not have the error message you're getting
 * I've also tried with a minimal .vimrc:  vim -u simple8.vimrc
junk.scala   and did not get any error messages  (the file "junk.scala"
doesn't exist on my system)

Are you sure that you haven't modified your system file(s)?

Regards,
Chip Campbell

-- 
-- 
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.
set nocp
filetype plugin indent on
syn on

Re: unexpected "ad behavior

[Charles E Campbell]

Tony Mechelynck wrote:
> On Wed, Sep 7, 2016 at 7:06 AM, Tony Mechelynck
> <antoine.mechely...@gmail.com> wrote:
>> On Wed, Sep 7, 2016 at 6:22 AM, Charles E Campbell
>> <drc...@campbellfamily.biz> wrote:
>>> Hello:
>>>
>>> With the following 6 lines: (the last three are empty)
>>> -
>>> hello world!
>>> hello world!
>>> hello world!
>>>
>>>
>>>
>>> -
>>> Put cursor on line 4, use ctrl-v and move down 2 lines.
>>> Press "ad .  This operation grabs the visually selected text and puts it
>>> into register a.  (ie. the three blank lines)
>> At this point, (for me) the register contains ^J^J^J (three
>> carriage-return characters)
> Oops, sorry, in Block-visual (note Line-visual) the selected text is
> not deleted and the register contains ^J^J (only 2 carriage returns)
>>> :goto 1. This puts the cursor on the h in the first hello.
>>> "ap
>>>
>>> I rather expected that nothing would happen -- instead, a blank is inserted
>>> after each h.
>> With me, it inserts three empty lines immediately after the current
>> line (i.e., between lines 1 and 2)
> Sorry. In block-visual I see the same as you do. It "might" be
> correct, considering that we insert a three-line block after column 1
> and that, when the cursor is on an empty line, the "column" part of
> the ruler says 0-1 (i.e. "column 0, visual column 1" or maybe more
> precisely "byte 0, screen cell 1").
>
>>> Is this correct behavior?
>>>
Hello:

Well, this affects my vis.vim plugin, which allows one to perform an
arbitrary vim command on a visual block; for example, :B s/e// applied
to visual-block selected "e"s in the "hello"s.  Result was unwanted
blanks being inserted.  I've worked around this, but I think its a vim
bug (visual block selection of empty lines should not insert something).

Regards,
Chip Campbell

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

unexpected "ad behavior

[Charles E Campbell]

Hello:

With the following 6 lines: (the last three are empty)
-
hello world!
hello world!
hello world!



-
Put cursor on line 4, use ctrl-v and move down 2 lines.
Press "ad .  This operation grabs the visually selected text and puts it 
into register a.  (ie. the three blank lines)

:goto 1. This puts the cursor on the h in the first hello.
"ap

I rather expected that nothing would happen -- instead, a blank is 
inserted after each h.


Is this correct behavior?

Chip Campbell




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

syntax clear -- should it be removed from syntax files?

[Charles E Campbell]

Hello:

In nosing around the help, I see for :help filetypedetect-changed the
following:

The distributed syntax files no longer contain "syntax clear".  That
makes it
possible to include one in the other without tricks.  The syntax is now
cleared when the 'syntax' option is set (by an autocommand added from
synload.vim).  This makes the syntax cleared when the value of 'syntax' does
not correspond to a syntax file.  Previously the existing highlighting was
kept.

However:

fgrep "syn clear" *.vim | wc  shows 56 files with this command, and
fgrep "syntax clear" *.vim | wc shows 357 files with this command.

Should all the syn(tax) clears be removed?  Or am I reading the above
paragraph incorrectly?

Regards,
Chip Campbell

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

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

Re: [vim/vim] Vim cryptmethod is not authenticated (#638)

[Charles E Campbell]

Marvin Renich wrote:
> Bugs in Vim's encryption algorithms should, of course, be fixed if
> possible, but not in a way that prevents access to older encrypted
> data files. That includes keeping, for a significant amount of time
> (two years? I'm not sure how long), the ability to write files that
> can be read by older versions of Vim. Requiring a confirmation when
> using a deprecated algorithm is certainly reasonable. ...Marvin 

We seem to encounter folks with vims that are out of date by at least 6
years  (v7.3 - I had a bug report recently from a vim v7.3 user, for
example).  It wouldn't surprise me at all to find that there are 7.1 and
7.2 users out there (7.1 dates from 2007).

Regards,
Chip Campbell

P.S. As a tech thing, its likely that quantum computers will break all
the crypto in a decade or two.

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

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

Re: [vim/vim] Changed DB_COUNT to 16 (#1000)

[Charles E Campbell]

Marius Gedminas wrote:
>
> I once needed to diff more files than vim would support (IIRC I was
> comparing lists of installed packages across five servers). Having to
> recompile vim for that was a pain.
>
> Forgetting that you set diff on for a buffer is already possible when
> you're diffing just two buffers -- I used to do that all the time.
> Increasing the number of diff'able buffers is not going to affect this
> one way or another.
>
>
Seems that this would be a case where one ought to be able to show
something in the status line -- and the 'diff' setting seems to be
useful in this regard.

So, may I suggest using something like:   set stl="... %{? "[DIFF]"
: ""} ..."  where the dots is your choice controlling whatever else you
might like to have in your statusline.  Maybe a %d (for [diff]) and %D
(for [DIFF]) would be useful for new statusline modifiers?  (presumably
would expand to nothing when  is false)

Regards,
Chip Campbell

-- 
-- 
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: problems with git and maintaining files

[Charles E Campbell]

Christ van Willegen wrote:
>
> git stash
> git checkout / git revert
> git stash pop
> ?
>
> Sorry, getting terse, tablets are not helpful for
> cutting/pasting/editing...
>
I understand -- I try to avoid using my tablet to say much via email. 
I'll give this a go the next time I have the problem.

Thank you,
Chip Campbell

-- 
-- 
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: problems with git and maintaining files

[Charles E Campbell]

Marius Gedminas wrote:
> On Fri, Aug 19, 2016 at 04:56:34PM -0400, Charles E Campbell wrote:
>> Charles E Campbell wrote:
>>> Christ van Willegen wrote:
>>>> Op 19 aug. 2016 22:28 schreef "Charles E Campbell"
>>>> <drc...@campbellfamily.biz <mailto:drc...@campbellfamily.biz>>:
>>>>> I tried git stash push instead of git push -- and it still doesn't work:
>>>> Probably only 'stash' then...
>>>>
>>> That doesn't work either, unfortunately:
>>>
>>> runtime/syntax/sh.vim: needs merge
>>> runtime/syntax/sh.vim: needs merge
>>> runtime/syntax/sh.vim: unmerged (711971ea4ae7b3a72c2062c18130b3eca35dc67b)
>>> runtime/syntax/sh.vim: unmerged (34b8ab79e45bb1f39827e940e4b3428bedfad64b)
>>> runtime/syntax/sh.vim: unmerged (b285b04979551b260ab016ba089d9e69ded01612)
>>> fatal: git-write-tree: error building trees
>>> Cannot save the current index state
>>> Mruntime/doc/syntax.txt
>>> Uruntime/syntax/sh.vim
>>> Pull is not possible because you have unmerged files.
>>> Please, fix them up in the work tree, and then use 'git add/rm '
>>> as appropriate to mark resolution, or use 'git commit -a'.
>>> runtime/syntax/sh.vim: needs merge
>>> Cannot apply to a dirty working tree, please stage your changes
>>>
>> Oh, well -- I tried several things based on web searches, and none of
>> them worked.  I just went ahead and did what I know does work -- save
>> off the affected files manually, wipe out the local copy, git clone
>> https://github.com/vim/vim.git, and manually copy the affected files
>> back to where they needed to be.
> An entire full clone must be painful.  A simpler solution that doesn't
> rely on any advanced git mastery would be
>
>mv runtime/syntax/sh.vim runtime/syntax/sh.vim.mine  # for each file
>git checkout .  # restore pristine upstream versions of every file
>git pull
>mv runtime/syntax/sh.vim.mine runtime/syntax/sh.vim  # for each file
>
I'll try this the next time I have the problem -- looks like it should work.

Thank you,
Chip Campbell

-- 
-- 
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: problems with git and maintaining files

[Charles E Campbell]

Charles E Campbell wrote:
> Christ van Willegen wrote:
>> Op 19 aug. 2016 22:28 schreef "Charles E Campbell"
>> <drc...@campbellfamily.biz <mailto:drc...@campbellfamily.biz>>:
>>> I tried git stash push instead of git push -- and it still doesn't work:
>> Probably only 'stash' then...
>>
>>
> That doesn't work either, unfortunately:
>
> runtime/syntax/sh.vim: needs merge
> runtime/syntax/sh.vim: needs merge
> runtime/syntax/sh.vim: unmerged (711971ea4ae7b3a72c2062c18130b3eca35dc67b)
> runtime/syntax/sh.vim: unmerged (34b8ab79e45bb1f39827e940e4b3428bedfad64b)
> runtime/syntax/sh.vim: unmerged (b285b04979551b260ab016ba089d9e69ded01612)
> fatal: git-write-tree: error building trees
> Cannot save the current index state
> Mruntime/doc/syntax.txt
> Uruntime/syntax/sh.vim
> Pull is not possible because you have unmerged files.
> Please, fix them up in the work tree, and then use 'git add/rm '
> as appropriate to mark resolution, or use 'git commit -a'.
> runtime/syntax/sh.vim: needs merge
> Cannot apply to a dirty working tree, please stage your changes
>
Oh, well -- I tried several things based on web searches, and none of
them worked.  I just went ahead and did what I know does work -- save
off the affected files manually, wipe out the local copy, git clone
https://github.com/vim/vim.git, and manually copy the affected files
back to where they needed to be.

Regards,
Chip Campbell

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

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

Re: [vim/vim] Broken syntax in tex when defining custom math column type (#984)

[Charles E Campbell]

Bart Baker wrote:
> \documentclass{article}
>
> \newcolumntype{R}{>{$}r<{$}}
>
> \begin{document}
>
> This is colored as if it is in a math section, rather than the default
> text
> color.
>
> \end{document}

I get the following when I apply latex to the file containing the above
example:

baker01.tex|3 error| Undefined control sequence. \newcolumntype
{R}{>{$}r<{$}}
baker01.tex|3 error| Missing \begin{document}.
baker01.tex|3 error| Extra }, or forgotten $.  }
\newcolumntype{R}{>{$} r<{$}}
baker01.tex|3 error| Missing } inserted.   }
\newcolumntype{R}{>{$}r<{$ }}

Obviously LaTeX doesn't like this control sequence (pdftex,
3.141592-1.40.3-2.2).  Furthermore, I've seen \newcolumntype mentioned
in conjunction with several packages, including array and tabularx. 
Please refer to   :help tex-package  .

Regards,
Chip Campbell2

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

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

Re: [vim/vim] sh syntax script highlights multiline arrays inside an if statement incorrectly (#962)

[Charles E Campbell]

keremc wrote:
>
> Inside an if statement the opening parenthesis of a multiline array
> will not be highlighted at all, while the closing parenthesis will be
> highlighted as an error.
>
>
Hello:

Please try the attached syntax/sh.vim.

Regards,
Chip Campbell

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


sh.vim
Description: application/octetstream

Re: Wish list for a more powerful search in Vim

[Charles E Campbell]

Christian Brabandt wrote:
> Hi Yegappan!
>
> On Fr, 29 Jul 2016, Yegappan Lakshmanan wrote:
>
>> Hi Christian,
>>
>> On Thu, Jul 28, 2016 at 11:16 PM, Christian Brabandt  
>> wrote:
>>> On Do, 28 Jul 2016, Bram Moolenaar wrote:
>>>
 I think it should.  Most users will have 'wrapscan' on, since it is the
 default.  If someone switches it off he must have a reason for it.
>>> okay, fixed with the latest version
>>>
>> I tested the latest patch and the confirmed that the problems I reported 
>> earlier
>> are fixed. I saw some new issues. Take the following text:
>>
>>   1
>>   2 these
>>   3 the
>>   4 their
>>   5 there
>>   6 their
>>   7 the
>>   8 them
>>   9 these
>>
>> The cursor is in line 1 and I have 'nowrapscan' set. I search for "the" and
>> press CTRL-N 7 times and "the" in "these" is highlighted. Now I press
>> CTRL-L to copy "s" and then erase it. Now if I press CTRL-P, I expect
>> that the cursor will move to line 8. Instead the cursor moves to line 7.
>>
>> Another problem: Place the cursor in line 1. Enter "/thes" and then press
>> CTRL-N. The "thes" in line 9 is highlighted. Now if you press backspace,
>> the cursor jumps back to line 3. I expected that the cursor will remain
>> in line 9.
> Thanks, will look at these and add some tests.
>
>> I think, the CTRL-N and CTRL-P should respect the search direction.
>> For example, if I search a pattern using "?text", pressing CTRL-N
>> should search backwards. Currently CTRL-N always searches
>> forward (irrespective of the search direction). Note that this is
>> different from how "n" and "N" work.
> Please don't make me do this. Currently the inconsistent search 
> direction is one of my biggest annoyances of Vim. I really really really 
> hate it, that I can't rely on the fact that N searches backwards and n 
> forward.
>
> (I even made a patch, to make this configurable 
> https://github.com/chrisbra/vim-mq-patches/blob/master/cpo-N
> and this is one of the reasons, I made gn always search forward).
>
That's because, Christian, you keep your eyes on the front of your
head.  You need to move them to back of your head occasionally, and that
way you'll get used to the idea.
:)

Regards,
Chip Campbell

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

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

Re: [vim/vim] Syntax highlighting for messages with RFC3339 timestamp (#946)

[Charles E Campbell]

Sung Po-Han wrote:
>
> vim-messages
> 
> It seems that the hostname is considered as a tag name.
>
> By checking the file runtime/syntax/messages.vim, I found it is easy
> to fix.
>
> |diff --git a/runtime/syntax/messages.vim b/runtime/syntax/messages.vim
> index c22e4e8..59425fc 100644 --- a/runtime/syntax/messages.vim +++
> b/runtime/syntax/messages.vim @@ -26,7 +26,7 @@ syn match
> messagesDateRFC3339 contained display '\d\{4}-\d\d-\d\d' syn match
> messagesRFC3339T contained display '\cT' \
> nextgroup=messagesHourRFC3339 -syn match messagesHourRFC3339 contained
> display '\c\d\d:\d\d:\d\d\(\.\d\+\)\=\([+-]\d\d:\d\d\|Z\)' +syn match
> messagesHourRFC3339 contained display
> '\c\d\d:\d\d:\d\d\(\.\d\+\)\=\([+-]\d\d:\d\d\|Z\)\s*' \
> nextgroup=messagesHost syn match messagesHost contained display '\S*\s*' |
>
Please send changes to syntax files to their maintainer; typically,
you'll find their name and email at the top of the sytnax file itself. 
Hint: its Yakov Lerner, for syntax/messages.vim.  Otherwise, unless the
maintainer keeps an eye on the mailing list, your changes will not be
included.
Chip Campbell

-- 
-- 
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: Changing the defaults with Vim 8

[Charles E Campbell]

Christian Brabandt wrote:
> Hi Bram!
>
> On So, 24 Jul 2016, Bram Moolenaar wrote:
>
>>> please no hlsearch. That is most often annoying.
>> Well, I find it useful.  But I suppose that's more a personal
>> preference.
> perhaps, if we made ctrl-l clear the search highlighting by default?
>
>>> some more I would set, the mentioned
>>> :set display+=lastline
>> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
>> be surprised if this changes.
> Really? I think the default of a bunch of '@'
> doesn't really help anybody, instead show at least the beginning of the 
> line.
>
> Just my opinion however,
>
How about another opinion? :)

I use ve=all and nowrap, not that I think these should be inflicted on
everyone.  However, because of the nowrap, I don't really need the
display+=lastline as I don't get those @s.  So I don't suppose I would
be affected either way.

Regards,
Chip

-- 
-- 
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: Changing the defaults with Vim 8

[Charles E Campbell]

Bram Moolenaar wrote:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
>   set backspace=indent,eol,start
>   set history=50  " keep 50 lines of command line history
>   set ruler   " show the cursor position all the time
>   set showcmd " display incomplete commands
>   set incsearch   " do incremental searching

Except for incsearch, my .vimrc already incorporates these settings, so
I'm fine with them myself.  incsearch is "noisy" and changes the visual
interface (ie. becomes prominent) and I don't advise doing so, even
though I myself might decide to use it someday.  At least its easily
reversible in one's .vimrc.
>
>   " Don't use Ex mode, use Q for formatting
>   map Q gq

Doesn't modify look (unless one types a "Q", of course).  Guess I'm
neutral on this one.
>
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif

Probably a good idea.
>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif

Setting hlsearch definitely modifies the look, and I myself only
use hls in specific situations.  I'd rather not have this one, although
at least its easy to countermand with a set nohls.
>
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>   
> augroup vimrcEx
> au!
>   
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
This modifies look and is difficult to prevent except on a
file-by-file basis.  Please don't do this.
>   
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif
I myself already do something like this in my  .vimrc.  However, even
though I like this, it would be difficult not-to-have.  Perhaps cp
should have levels: 0=compatible, 1= current nocp, 2=more, etc, or
perhaps a letter-driven selection (something like complete).
>   
> augroup END
>   else
> set autoindent" always set autoindenting on
>   endif
I don't care, I guess -- easily reversed.
>   
>   if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif

I had to look this one up as I've never had cause to use it.  Easily
reversed, so I'm neutral on this one.
>
>
> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile
>
>   " may conflict with a user mapping
>   inoremap  u
>
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif
>
> Comments?
>
Leaving files behind -- I have enough of a problem with macs and .dSYM
directories getting into my tarballs; I use set directory to move swap
files where I don't back them up, and I've not used undofiles.  These
two are easily reversible, though.  I'm sure I wouldn't like the
proposed ctrl-u map, although I know how to get rid of it so it wouldn't
be a major problem.  I think it would be best to document any of these
changes and include how-to-prevent/restore/obviate them.  Does the last
item (with matchit) mean that matchit will become a package which must
be packadd'd?

Regards,
Chip Campbell

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

folding patch

[Charles E Campbell]

Hello:

Here's my patch for neater folding displays, updated to apply cleanly
for vim 7.4.1979.

Regards,
Chip Campbell

-- 
-- 
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.
*** eval.c.orig 2016-07-01 17:46:29.997747660 -0400
--- eval.c  2016-07-01 17:47:11.949546588 -0400
***
*** 1,12227 
--- 1,12231 
  char_u*r;
  int   len;
  char  *txt;
+ charfmt[40];
+ int nuw;
+ int padding;
+ unsignedrlen;
  #endif
  
  rettv->v_type = VAR_STRING;
***
*** 12255,12270 
s = skipwhite(s + 1);
}
}
!   txt = _("+-%s%3ld lines: ");
!   r = alloc((unsigned)(STRLEN(txt)
!   + STRLEN(vimvars[VV_FOLDDASHES].vv_str)/* for %s */
!   + 20/* for %3ld */
!   + STRLEN(s)));  /* concatenated */
if (r != NULL)
{
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
!   - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 12259,12280 
s = skipwhite(s + 1);
}
}
!   /* next two lines construct a format to be used for the folded region.
!* Example: assume nuw=5, then fmt becomes "+-%-5s%5ld lines: %*s"
!*/
!   nuw= number_width(curwin);  /* obtain log10(lastline) */
!   padding= STRLEN(vimvars[VV_FOLDDASHES].vv_str);
!   sprintf(fmt,"+-%%-%ds%%%dld lines:%%*s",(padding > nuw)? padding : 
nuw,nuw);
!   txt = _(fmt);   /* internationalize   */
!   rlen= (STRLEN(txt) - 11) + 2*nuw + ((padding > nuw)? padding : nuw) + 
STRLEN(s) + 10;
!   r   = alloc(rlen);
if (r != NULL)
{
+   if(padding > nuw) padding= nuw;
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
!   - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1),
!   padding," ");
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */

Re: Patch 7.4.1952

[Charles E Campbell]

Bram Moolenaar wrote:
> Patch 7.4.1952
> Problem:Cscope interface does not support finding assignments.
> Solution:   Add the "a" command. (ppettina, closes #882)
> Files:  runtime/doc/if_cscop.txt, src/if_cscope.c
>
Hello!

I'm using git .. and I don't seem to have if_cscop.txt (or
if_cscope.txt, if that was a typo).  What do I need to do to get
if_cscop[e].txt ?

Regards,
Chip Campbell

-- 
-- 
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: Spellcheck after Ellipsis again [vim bug found?]

[Charles E Campbell]

David Woodfall wrote:
>> David Woodfall wrote:
>>> syn sync fromstart
>>> syn match Ellipsis /[.][.][.]\s\+\l.*\>/ contains=@NoSpell transparent
>>> syn match Ellipsis2 /[.][.][.]\n\s\+\l.*\>/ contains=@NoSpell
>>> transparent
>>> syn cluster Spell add=Ellipsis
>>> syn cluster Spell add=Ellipsis2
>>>
>>> syn cluster texDocGroup add=Ellipsis
>>> syn cluster texPartGroupadd=Ellipsis
>>> syn cluster texChapterGroup add=Ellipsis
>>> syn cluster texSectionGroup add=Ellipsis
>>> syn cluster texSubSectionGroup  add=Ellipsis
>>> syn cluster texSubSubSectionGroup   add=Ellipsis
>>> syn cluster texParaGroupadd=Ellipsis
>>>
>>> syn cluster texDocGroup add=Ellipsis2
>>> syn cluster texPartGroupadd=Ellipsis2
>>> syn cluster texChapterGroup add=Ellipsis2
>>> syn cluster texSectionGroup add=Ellipsis2
>>> syn cluster texSubSectionGroup  add=Ellipsis2
>>> syn cluster texSubSubSectionGroup   add=Ellipsis2
>>> syn cluster texParaGroupadd=Ellipsis2
>> Please try the attached file instead; place in your $HOME/syntax
>> directory.  I tried it with the attached "junk.tex" file.
>>
>> Regards,
>> Chip Campbell
>
> Thanks. That works on .tex files but on a txt file with syn=tex in the
> modeline still messes up unless I also put ft=tex in the modeline.
>
> This is where it is falling down.
>
I haven't used the syntax option before.  It sounded like a
sourcing/sequencing problem, so I ran   vim -V10tmp junk.txt  (after
renaming junk.tex to junk.txt and appending the % vim: syn=tex
modeline).  I then used  ":g/sourcing.*tex\.vim and got:

line 24: sourcing "/home/cec/.SW/VIM/vim74/runtime/syntax/tex.vim"
finished sourcing /home/cec/.SW/VIM/vim74/runtime/syntax/tex.vim
line 24: sourcing "/home/cec/.vim/after/syntax/tex/tex.vim"
finished sourcing /home/cec/.vim/after/syntax/tex/tex.vim
line 24: sourcing "/home/cec/.vim/syntax/tex.vim"
finished sourcing /home/cec/.vim/syntax/tex.vim
line 24: sourcing "/home/cec/.SW/VIM/vim74/runtime/syntax/tex.vim"
finished sourcing /home/cec/.SW/VIM/vim74/runtime/syntax/tex.vim
line 24: sourcing "/home/cec/.vim/after/syntax/tex/tex.vim"
finished sourcing /home/cec/.vim/after/syntax/tex/tex.vim

You'll see that the runtime syntax/tex.vim got sourced again, which
wiped out the effects of .vim/syntax/tex.vim .  Furthermore,
.vim/syn/tex.vim was not sourced a second time, so its directives were
effectively lost.
I'm not sure if this is a vim bug or not  (after/syntax/tex/tex.vim is
unrelated and something I use).  I suggest moving  the
$HOME/syntax/tex.vim to $HOME/after/syntax/tex/tex.vim.
I don't have time to try that out.

Regards,
Chip Campbell

P.S. I've attached junk.txt and tex.vim for any who want to try it out. 
The question is: should $HOME/syntax/tex.vim be sourced when the
modeline syn=tex is used?

-- 
-- 
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.
\documentclass[12pt]{article}
\usepackage{here}
\pagestyle{empty}
\title{nothing}

\newcommand{\GPS}{{\small GPS}}
\newcommand{\NASA}{{\small NASA}}

% Textwidth and textheight specification
\newtheorem{example}{Example}[section]
\newcommand{\widepage}{
 \setlength{\topmargin}{0.0in}
 \setlength{\textheight}{8.75in}
 \setlength{\footskip}{0.25in}
 \setlength{\oddsidemargin}{0in}
 \setlength{\textwidth}{6.5in}
 }
\widepage

\newfont{\smit}{cmsl10 scaled\magstephalf}
\newtheorem{alg}{Algorithm}
\def\qed{\quad \vrule height7.5pt width4.17pt depth0pt} %Thanks to Ed Perkins  
(\qed)

% Uncomment following line.  Put the second line just after each \section, then
% equations will be numbered with section.eqn-number.
%\renewcommand{\theequation}{\thesection.\arabic{equation}}
%\setcounter{equation}{0}

\begin{document}

  normal words
  mispeling
  ... xyz
  mispeling
  normal words
  
\end{document}
% vim: syn=tex


tex.vim
Description: application/octetstream

Re: [vim] Vim cryptmethod uses SHA-256 for password-based key derivation (#639)

[Charles E Campbell]

Benjamin Fritz wrote:
>
> On Wed, Mar 23, 2016 at 4:58 PM, Bram Moolenaar  > wrote:
> >
> > > Speaking of defaults: I think Vim should default to the strongest
> > > method available. I additionally think Vim should warn on saving with
> > > a known broken format such as the original blowfish implementation, or
> > > the zip algorithm, or even blowfish2 without a decent KDF. Maybe even
> > > compile without the broken algorithms altogether unless the user
> > > specifically passes --include-bad-crypto to the configure script or
> > > something.
> >
> > This has the danger of writing a file on one system, go on holiday and
> > find out you can't open it on your laptop (that actually happened to
> me).
> >
>
> That makes some sense, however it only applies to people who edit the
> same file on multiple systems, AND they don't have the same version of
> Vim on each of those systems.
And, if libraries are used, the system may update the library (while one
is on holiday), potentially rendering encrypted text unreadable.  I know
that these things should be done in a backwards compatible fashion, but
Murphy's Law plus having many users guarantees trouble will happen.

I agree that libraries will get better testing, though.

Chip Campbell

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

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

Re: [vim/vim] propose vim as manpager that syntax highlights and follows symlinks (#491)

[Charles E Campbell]

Enno wrote:
> Dear Charles, 
>
> Does this mean that ManPageView overrides Vim's built-in :Man? Then :MANPAGER 
> would use it, once ManPageView installed. 
>
> You should propose to SungHyun Nam, the maintainer of :Man, to merge 
> :ManPageView into :Man. 
>
> As an aside, perhaps worth thinking about including your :Info command, 
> turning Vim into an info reader. 
>
ManPageView's :Man does override the :Man command provided by the
runtime, and ManPageView doesn't provide :Info, but it does provide :Man
topic.i, which currently  provides vim with an info reader, too.   It
also provides :VMan, :Oman, and more (including :HEMan for you body
building types! :)  ).

Merging it -- well, its completely different from SungHyun Nam's
version, so it would either be a replacement or Nam would have to
duplicate functionality -- and there's a lot of extra functionality.

Regards,
Chip Campbell

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

warning in term.c

[Charles E Campbell]

Hello:

I'm getting a warning from term.c:

  term.c|6180 warning| ignoring return value of 'fgets', declared with
attribute warn_unused_result

The line in question does use (void)fgets(...) so the result is
intentionally thrown away.

Regards,
Chip Campbell


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

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

Re: [vim/vim] propose vim as manpager that syntax highlights and follows symlinks (#491)

[Charles E Campbell]

Murukesh Mohanan wrote:
>
> Typically man pages have bold and underlines displayed using |x\bx|
> and |_\bx|, |\b| being the backspace and |x| the letter in question
> (Thomas Dickey talks about this in this Unix & Linux post
> ). That's what makes
> using just |vim -| as the manpager annoying. The workaround I have
> seen posted in a number of places is to filter out the backspaces, and
> the characters that would have been printed over. Typically:
>
> |MANPAGER='col -b | vim -' |
>
> There's no reason to do this with |col -b|, of course. You could do
> something like:
>
> if !empty($MAN_PN)
> autocmd StdinReadPost * set ft=man | file $MAN_PN | call PrepManPager()
> endif
>
> And |PrepManPager()| defined in some suitable place:
>
> function! PrepManPager()
> setlocal modifiable
> %s/.\b\(.\)/\1/g
> 1
> setlocal nomodified
> setlocal nomodifiable
> endfunction
> 
>
> Aside:
>
> In the Unix & Linux post mentioned above, I'd posted my method, which
> involves keeping the backspaces and concealing them, instead of
> removing them. Personally, I feel the loss of functionality in
> searching is balanced by the added syntax highlighting I can do with
> the backspaces retained. There are manpages for which the standard
> |syntax/man.vim| is useless, because it has no way to know what the
> actual page would have highlighted. (Pick any C++ STL manpage, for
> example.) If anyone's interested, here's how I use conceal for this
> .
>
>
Have you tried ManPageView?  I use the kornshell, but it should work
with bash also:

# man: {{{2
function man
{
gv -c "Man $*" -c "sil! only"
}

then   man printf  brings up ManPageView in vim.  (you can get
ManPageView from
http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW).

Regards,
Chip Campbell

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

[Charles E Campbell]

Charles Campbell wrote:
> Bram Moolenaar wrote:
>> Charles Campbell wrote:
>>
>>> Bram Moolenaar wrote:
 Patch 7.4.1770
 Problem:Cannot use true color in the terminal.
 Solution:   Add the 'guicolors' option. (Nikolai Pavlov)
 Files:  runtime/doc/options.txt, runtime/doc/term.txt,
 runtime/doc/various.txt, src/auto/configure, src/config.h.in,
 src/configure.in, src/eval.c, src/globals.h, src/hardcopy.c,
 src/option.c, src/option.h, src/proto/term.pro, src/screen.c,
 src/structs.h, src/syntax.c, src/term.c, src/term.h,
 src/version.c, src/vim.h
>>> One unwanted side effect that I've noticed so far: Ignore highlighting
>>> is no longer ignored.
>> What do you mean with "Ignore highlighting", what is used in the help
>> file?  How can it be reproduced?
>>
> Hello:
>
> Here's how to reproduce the problem: (after using bunzip2 and tar xf, of
> course)
>
> 1. vim -u gcol.vimrc junk
>:so junksyn.vim
>
>As attached, gcol.vimrc uses the gcol option.  Note that the trailing
> ~123 does not get Ignore'd.
>
> 2. To see what it should have done: comment out the set gcol line in
>
I need to further mention that when I did this example I had not
configured with  --enable-termtruecolor .  After having done so, the
~123 which should be Ignore'd is not Ignore'd either with or without set
gcol.

Regards,
Chip Campbell

-- 
-- 
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: $VIMRUNTIME/syntax/vim.vim seems to be highlighted wrongly

[Charles E Campbell]

tyru wrote:

Hi Vimmers and Dr.Chip,

Some items seems to be highlighted wrongly in my vimrc.
Please see attached Vim script file, HTML(:TOhtml), screenshot.

Vim script file: reproducible script
HTML: ":TOhtml"'s result
PNG: screen capture of HTML


Hello!

I see nothing wrong in the highlighting, so please point out 
specifically what you find a problem with.  On the off chance that its 
the following two lines:


command! -nargs=* AutocmdWhenVimStartingautocmd vimrc-guioptions 
FocusGained * 
command! -nargs=* AutocmdWhenVimStartingEnd autocmd vimrc-guioptions 
FocusGained * autocmd! vimrc-guioptions


The highlighting is correctly pointing out that you've formed your 
autocmds incorrectly.  Try switching the filename (vimrc-guioptions) 
with the event (FocusGained).


This is the second time I've pointed out this problem; please let the 
author of the script know to fix it.


Regards,
Chip Campbell

--
--
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]Strange interaction between Netrw and expr mapping with ! command

[Charles E Campbell]

Nicola wrote:
> To reproduce, use this vimrc_minimal:
>
> set nocompatible
> fun! MyFun()
>  silent !ls
> endf
> nmap o MyFun()
>
> Then:
>
> vim -u vimrc_minimal
> :Ex
> :enew
> \o
>
> (:enew is optional). You should get the following error:
>
> Error detected while processing function 28_LocalBrowseRefresh:
> line   26:
> E523: Not allowed here:tabn
> Press ENTER or type command to continue
> Error detected while processing function 28_LocalBrowseRefresh:
> line   63:
> E523: Not allowed here: 1wincmd w
>
> Note that \o does not give errors if used before :Ex.
>
> The workaround is to use:
>
> nmap o :call MyFun()
>
> but of course a workaround should not be necessary.
Hello:

What I think is happening: MyFun() is returning an integer 0 after
having done a shell command.  Netrw invokes s:LocalBrowseRefresh()
whenever a shell command is invoked; it checks over all tabs and windows
for a netrw buffer that might have been affected.  However, in a
map-, tabs and windows really shouldn't be changed.

Please try v157a of netrw, which you can get from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW .

Regards,
Chip Campbell

-- 
-- 
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: $VIMRUNTIME/syntax/vim.vim seems to be highlighted wrongly

[Charles E Campbell]

tyru wrote:
> Hi Vimmers and Dr.Chip,
>
> Some items seems to be highlighted wrongly in my vimrc.
> Please see attached Vim script file, HTML(:TOhtml), screenshot.
>
> Vim script file: reproducible script
> HTML: ":TOhtml"'s result
> PNG: screen capture of HTML
>
You might want to try swapping the FocusGained event with the filename
vimrc-guioptions.

Regards,
Chip Campbell

-- 
-- 
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 7.5 or Vim 8?

[Charles E Campbell]

Michael Jarvis wrote:
> On Tuesday, April 5, 2016 at 2:28:34 AM UTC-5, Dominique Pelle wrote:
>> Bram Moolenaar wrote:
>>
>>> I have been wondering if the next release should be called 7.5 or 8.
>>> We have quite a few new features, but not that many as with the Vim 7
>>> release.  Well, that was a big release.  I think the most important
>>> addition since then is persistent undo in 7.3.  Now we have more new
>>> features than in 7.3 or 7.4.  7.1 and 7.2 were mostly bug fixes.
>> 8.0 or 7.5 is a bit arbitrary without conventions such as:
>> - major version number increased when breaking backward
>>compatibility (which should be rare)
>> - middle version number increased when adding new features
>> - minor version increased for bug fixes
> I informally think of Vim by putting the patch number as a third minor 
> version, similar to the "Semantic Versioning" standard (http://semver.org/) 
> that we use at my place of employment.
>
> For example, instead of "Vim 7.4, patches 1-1726," I mentally think, "Vim 
> 7.4.1726". 
>
> Maybe it's time to make this an official nomenclature? 
>
> This does break the model where some people selectively cherry-pick patches, 
> and use something like, "Vim 7.4 with patches 1-5,9-33,1024-1726." In the 
> "old days", sometimes people lacked quality Internet access to the old CVS 
> repository and would have to manually patch their Vim source code from the 
> emailed diffs. If they were only concerned with Vim on a given architecture, 
> they could theoretically skip patches that didn't apply to them.
>
> I would argue that number one, this is NOT a good idea, because the source 
> code changes are cumulative. Trying to do regression testing on 7.4 plus 
> every combination of the current 1726 patches would be nearly impossible to 
> implement and manage. I think you should always apply ALL the patches, even 
> the ones that might not apply to your situation, just to avoid side effects.
>
> Number two, I don't think this use case still applies. I doubt that very many 
> people still download a tarball of the Vim 7.4 source code, and then manually 
> apply each and every diff based on the email attachments from Bram. I could 
> be wrong, but Internet access is more common now, and ever since we switched 
> to first Mercurial and now Git it has become very easy to get the latest 
> "snapshot" of the code. 
>
I did -- because patch #866 broke a plugin I use.  Fortuitously, a
(much) later patch fixed the problem, so I'm now using Git.

Regards,
Chip Campbell

-- 
-- 
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: iskKeep is a global variable in runtime/syntax/vim.vim.

[Charles E Campbell]

Naruhiko Nishino wrote:
> Hi Bram and Charles,
>
> I found that `iskKeep` is a global variable in runtime/syntax/vim.vim.
> I think that the variable have to use script scope better than global scope.
>
> I wrote this patch. Please check it.
>
Hello!

Thank you -- I've included it.

Chip Campbell

-- 
-- 
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: BSD specific cType's for syntax highlighting

[Charles E Campbell]

frantisek holop wrote:
> Christian Brabandt, 08 Apr 2016 08:08:
>> I don't have any saying in that, but I guess what Bram wants is 
>> something like this:
>>
>> if exists("c_bsd_types")
>> syn keyword cType   u_int8_t u_int16_t u_int32_t u_int64_t
>> endif
>>
>> And then add an entry at runtime/doc/syntax.txt below *ft-c-syntax* and 
>> document the variable.
> ah, i see.  i am of course slightly biased in favor of
> having this cType's, but i think for non-bsd people
> this would be mostly a no-op so if the condition is
> desired, an opt-out ("c_no_bsd_types") might be nicer :}
>
For the vast majority, I agree that your new types would not have much
effect.  However, its a big world, and there are bound to be people who
have ginned up their own (conflicting) types.  I agree with Christian
that it should be an optional (c_bsd_types) inclusion.

Regards,
Chip Campbell

-- 
-- 
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 7.5 or Vim 8?

[Charles E Campbell]

Bram Moolenaar wrote:
> I have been wondering if the next release should be called 7.5 or 8.
> We have quite a few new features, but not that many as with the Vim 7
> release.  Well, that was a big release.  I think the most important
> addition since then is persistent undo in 7.3.  Now we have more new
> features than in 7.3 or 7.4.  7.1 and 7.2 were mostly bug fixes.
>
> I have made a list of the most important improvements compared to Vim
> 7.4.  I might still be missing some (let me know!).
>
> Also, now is a good time to check out the new features, we can still
> make changes.  Especially the Channel, Job and timer support.  Once the
> release is out we can't really make changes that break backwards
> compatibility.
>
Do you have Big Improvements on the horizon?  If not, I'd go for v8.

* Would love to see Christian B's
:breaka[dd] expr {string}
  patch get included  (allows for something like gdb's watchpoints)

* Would like it if my folding patch got included (straightens up the
folded display)

Regards,
Chip Campbell

-- 
-- 
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] netrw silently closing buffers on its own (#231)

[Charles E Campbell]

Jake Bell wrote:
>
> Also experiencing this issue, as noted in macvim-dev/macvim#255
> . It appears to have
> /started/ happening for me some time between patch 7.4.1362 and the
> current HEAD.
>
> I'll try to do a |git bisect| in the next few days to determine the
> exact commit that (re-?)introduced the issue.
>
>
Before you go to the trouble of bisecting -- why not try the latest
netrw, which you can get from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW .

Chip Campbell

-- 
-- 
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] netrw suppress '@' when editing a file (from ssh) (#684)

[Charles E Campbell]

pLesur wrote:
>
> When SSHing to a directory using vim:
>
> |scp://user@host//dir/|
>
> and you want to edit a file, the command will read as:
>
> |scp://userhost//dir/file #<- '@' is missing !|
>
> An empty file is then opened, and if saved, will override the real,
> potentially non empty, remote file.
> It makes the whole ssh functionality almost useless in my opinion
> (unless you connect without specifying a username)
>
>
I've tried this and was unable to duplicate your problem.  Please try
the attached file:

  vim -u netrw.vimrc

and see if the problem occurs.  Also use the latest netrw (v156b) which
you can get from my website:

  http://www.drchip.org/astronaut/vim/index.html#NETRW

Thank you for your feedback,
Chip Campbell



-- 
-- 
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.
" start vim with:  vim -u netrw.vimrc --noplugins
set nocp
let g:netrw_browse_split= 3
set sol
syn on
runtime plugin/netrwPlugin.vim

Re: Undefined variable: b:netrw_curdir

[Charles E Campbell]

Xavier de Gaye wrote:
> This is a regression introduced somewhere after 7.4.944.
>
> This error occurs when opening a file and when:
> let g:netrw_browse_split = 3"  open file in new tab
>
> Error message:
> Error detected while processing function 27_NetrwBrowseChgDir:
> line  135:
> E121: Undefined variable: b:netrw_curdir
> E116: Invalid arguments for function 27_SetRexDir
>
Hello!

I just tried that -- and no problem occurred.  Please try the attached file:

vim -u netrw.vimrc

and try to come up with a sequence of commands that causes the above
error message.  Also, please use netrw v156b which you can get from my
website:

  http://www.drchip.org/astronaut/vim/index.html#NETRW

Thank you,
Chip Campbell


-- 
-- 
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.
" start vim with:  vim -u netrw.vimrc --noplugins
set nocp
let g:netrw_browse_split= 3
set sol
syn on
runtime plugin/netrwPlugin.vim

Re: [vim] Long lines make VIM slow but... (#555)

[Charles E Campbell]

Hugo Oliveira wrote:
>
> @chrisbra , I can also confirm the
> behaviour of @Deluxo . Using the kludge of
> setting synmaxcol to a high value and calling syntax on again make
> scrolling faster. Can you explain why?
>
> I have syntax on on my vimrc and editing latex files with synmaxcol
> really large make it much slower. doing @deluxo
>  kludge make things much better (not super
> fast but fine for text editing).
>
>
On the off-chance that participants in this "issue" will pay attention
to the mailing list instead of the bugtracker...have any of you read 
:help tex-slow ?  In particular, the hint given about folding.

Apologies for responding to vimdev, because this "issue" really should
have been on the vim mailing list.

Chip Campbell

-- 
-- 
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] sh.vim incorrectly highlighting if/fi (#636)

[Charles E Campbell]

Christian Brabandt wrote:
> Hi Charles!
>
> On Di, 01 Mär 2016, Charles E Campbell wrote:
>
>> This is a solution, but inadequate, I'm afraid.  The right solution
>> (now, for the 3rd time): use a vim with patch 1141, along with
>> syntax/sh.vim v145.
> I am afraid, your message does not make it to the github issue, so the 
> OP did probably not notice. I'll leave an info there then and close.
>
Hello, Christian:

Has this been a vim bugtracker issue?  The prior setup had some text
that made that prominent in the message.  I just looked at the original
message; it says "Reply to this email directly or view it on GitHub". 
Well, I don't see it on the bugtracker -- so I presume there is
yet-another-mailing-list?  Should I be responding via that "view it on
GitHub" link somehow, as obviously "replay to this email directly" does
not work.

Regards,
Chip Campbell

-- 
-- 
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] sh.vim incorrectly highlighting if/fi (#636)

[Charles E Campbell]

Christian Brabandt wrote:
>
> I think, the problem is this line from sh.vim (distributed with vim):
>
> |syn region shCaseEsac matchgroup=shConditional start="\ matchgroup=shConditional end="\" end="\" contains=@shLoopList |
>
> which matches the xcode-select command. Something like this might work:
>
> diff --git a/runtime/syntax/sh.vim b/runtime/syntax/sh.vim
> index 15a00eb..cbf10fb 100644
> --- a/runtime/syntax/sh.vim
> +++ b/runtime/syntax/sh.vim
> @@ -240,7 +240,7 @@ if exists("b:is_kornshell") || exists("b:is_bash")
>   syn cluster shFunctionListadd=shRepeat
>   syn region shRepeat   matchgroup=shLoop   start="\ end="\"me=e-2 contains=@shLoopList,shDblParen,shDblBrace
>   syn region shRepeat   matchgroup=shLoop   start="\ end="\"me=e-2 contains=@shLoopList,shDblParen,shDblBrace
> - syn region shCaseEsac matchgroup=shConditional start="\ matchgroup=shConditional end="\" end="\" contains=@shLoopList
> + syn region shCaseEsac matchgroup=shConditional
> start="-\@"
> end="\" contains=@shLoopList
>  else
>   syn region shRepeat   matchgroup=shLoop   start="\ end="\"me=e-2   contains=@shLoopList
>   syn region shRepeat   matchgroup=shLoop   start="\ end="\"me=e-2   contains=@shLoopList
>
This is a solution, but inadequate, I'm afraid.  The right solution
(now, for the 3rd time): use a vim with patch 1141, along with
syntax/sh.vim v145.

Regards,
Chip Campbell

-- 
-- 
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] sh.vim incorrectly highlighting if/fi (#636)

[Charles E Campbell]

Josh Reichardt wrote:
>
> With no plugins installed:
>
> With the cursor before the |--install| flag I get |shConditional|.
> With the cursor after the |--install| flag I get |shCaseEsac|.
>
>
shCaseEsac should only be in effect when one is using a case construct. 
Your example doesn't have a case construct.  I still see no problems,
though, even when I embed your example into a case.
shConditional is used for if, fi, then, elif, else, do, done, select,
in, case, and esac.

* I suggest using hilinks.vim (it'll translate what's under the cursor
into the  applicable syntax and highlighting groups; using :HLT! will
track your cursor as you move it).  See
http://www.drchip.org/astronaut/vim/index.html#HILINKS

* What does :version show?

* Try  usinjg
   vim -u NONE
   :set nocp
   :syn on
   :so [path]/.vim/plugin/hilinks.vim(assuming you've gotten
hilinks.vim)

Regards,
Chip Campbell

-- 
-- 
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] sh.vim incorrectly highlighting if/fi (#636)

[Charles E Campbell]

Christian Brabandt wrote:
>
> Well, what is the output of the synID command given above? It does not
> seem reproducible.
>
>
Version questions:

 * what version of syntax/sh.vim are you using?  The latest release: v145
 * what version of vim are you using?  You need 7.4.1141 or later.

Charles Campbell

-- 
-- 
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: Problem with patch#866

[Charles E Campbell]

Charles E Campbell wrote:
> Hello:
>
> Back to the patch#866 problem I'm having.  I'm using vim 7.4.1416:
>
>  * using efence: links fine, but won't run (runs out of memory)
>  * using valgrind: works
>  * using valgrind --leak-check=full:  works
>
> As can be seen from the trace below, the program hangs in a call to
> nanosleep
> in mch_delay().  The parameters to the nanosleep call seem to me to be
> correct.
>
> I put in the following code in mch_delay to force HAVE_USLEEP at line 632:
>
> #undef HAVE_NANOSLEEP
> #ifndef HAVE_USLEEP
> # define HAVE_USLEEP
> #endif
>
> This, too, "fixes" the problem.  I wrote a small program which exercises
> nanosleep with the same time delay (5ms) and it doesn't hang.  So, its
> not clear to me whether there's a vim source bug, a compiler bug, or o/s
> bug.
>
> So: is there a configure option to disable HAVE_NANOSLEEP?
>
Sigh -- seems that this isn't the whole story.  vim no longer hangs, but
gvim does, even with usleep instead of nanosleep.
With valgrind+gvim, no valgrind problems but it still hangs.

New trace, not the same as before:
(gdb) where
#0  0x0038a36df0d8 in poll () from /lib64/libc.so.6
#1  0x0038a4e449f9 in ?? () from /lib64/libglib-2.0.so.0
#2  0x0038a4e44e4c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
#3  0x00620ed3 in gui_mch_wait_for_chars (wtime=-1) at
gui_gtk_x11.c:6553
#4  0x006108ee in gui_wait_for_chars (wtime=-1) at gui.c:2925
#5  0x005f5d0c in ui_inchar (buf=0x8e6a52 "", maxlen=82,
wtime=-1, tb_change_cnt=19) at ui.c:186
#6  0x004dbb9c in inchar (buf=0x8e6a52 "", maxlen=246,
wait_time=-1, tb_change_cnt=19) at getchar.c:3056
#7  0x004db7b8 in vgetorpeek (advance=1) at getchar.c:2832
#8  0x004d97dd in vgetc () at getchar.c:1605
#9  0x004d9d11 in safe_vgetc () at getchar.c:1801
#10 0x00529fb6 in normal_cmd (oap=0x7fff7958c510, toplevel=1) at
normal.c:637
#11 0x00647a18 in main_loop (cmdwin=0, noexmode=0) at main.c:1345
#12 0x00647358 in main (argc=2, argv=0x7fff7958c828) at main.c:1044
(gdb) up 2
#2  0x0038a4e44e4c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
(gdb) up
#3  0x00620ed3 in gui_mch_wait_for_chars (wtime=-1) at
gui_gtk_x11.c:6553
6553g_main_context_iteration(NULL, TRUE);

Regards,
Chip Campbell


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

Problem with patch#866

[Charles E Campbell]

Hello:

Back to the patch#866 problem I'm having.  I'm using vim 7.4.1416:

 * using efence: links fine, but won't run (runs out of memory)
 * using valgrind: works
 * using valgrind --leak-check=full:  works

As can be seen from the trace below, the program hangs in a call to
nanosleep
in mch_delay().  The parameters to the nanosleep call seem to me to be
correct.

I put in the following code in mch_delay to force HAVE_USLEEP at line 632:

#undef HAVE_NANOSLEEP
#ifndef HAVE_USLEEP
# define HAVE_USLEEP
#endif

This, too, "fixes" the problem.  I wrote a small program which exercises
nanosleep with the same time delay (5ms) and it doesn't hang.  So, its
not clear to me whether there's a vim source bug, a compiler bug, or o/s
bug.

So: is there a configure option to disable HAVE_NANOSLEEP?

Regards,
Chip Campbell

  gdb Debugging Trace
 -
(gdb) where
#0  0x0038a3e0eff0 in __nanosleep_nocancel () from
/lib64/libpthread.so.0
#1  0x0055b5b0 in mch_delay (msec=50, ignoreinput=1) at
os_unix.c:638
#2  0x005f5e61 in ui_delay (msec=50, ignoreinput=1) at ui.c:251
#3  0x004ea8c6 in ServerWait (dpy=0xd38600, w=98566147,
endCond=0x4eadcc , endData=0x7fff004deb10,
localLoop=0, seconds=-1) at if_xcmdsrv.c:633
#4  0x004eae42 in serverReadReply (dpy=0xd38600, win=98566147,
str=0x7fff004deb70, localLoop=0) at if_xcmdsrv.c:821
#5  0x00478620 in f_remote_read (argvars=0x7fff004decc0,
rettv=0x7fff004df4a0) at eval.c:17009
#6  0x0046b0d2 in call_func (funcname=0x1050b50
"remote_read(serverid)", len=11, rettv=0x7fff004df4a0, argcount=1,
argvars=0x7fff004decc0, firstline=5, lastline=5,
doesrange=0x7fff004dee9c, evaluate=1, selfdict=0x0) at eval.c:8913
#7  0x0046ab2e in get_func_tv (name=0x1050b50
"remote_read(serverid)", len=11, rettv=0x7fff004df4a0, arg=
0x7fff004df450, firstline=5, lastline=5, doesrange=0x7fff004dee9c,
evaluate=1, selfdict=0x0) at eval.c:8712
#8  0x00465ba0 in eval7 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1, want_string=0) at eval.c:5245
#9  0x004653eb in eval6 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1, want_string=0) at eval.c:4896
#10 0x00464f9a in eval5 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1) at eval.c:4712
#11 0x00464507 in eval4 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1) at eval.c:4407
#12 0x00464357 in eval3 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1) at eval.c:4322
#13 0x004641ca in eval2 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1) at eval.c:4254
#14 0x00463ffd in eval1 (arg=0x7fff004df450,
rettv=0x7fff004df4a0, evaluate=1) at eval.c:4182
#15 0x00463f58 in eval0 (arg=0x1050b50 "remote_read(serverid)",
rettv=0x7fff004df4a0, nextcmd=0x7fff004df568,
evaluate=1) at eval.c:4142
#16 0x0045fa00 in ex_let (eap=0x7fff004df560) at eval.c:1957
#17 0x004a36ef in do_one_cmd (cmdlinep=0x7fff004dfbf8,
sourcing=1, cstack=0x7fff004df750, fgetline=
0x4a0fd4 , cookie=0x7fff004df6c0) at ex_docmd.c:2930
#18 0x004a0439 in do_cmdline (cmdline=0x0, fgetline=0x488468
, cookie=0x1061d40, flags=7)
at ex_docmd.c:1116
#19 0x004879ab in call_user_func (fp=0x1041ac0, argcount=1,
argvars=0x7fff004e0140, rettv=0x7fff004e0310, firstline=
5, lastline=5, selfdict=0x0) at eval.c:25127
#20 0x0046af93 in call_func (funcname=0x1021ef0 "pchk#PChk",
len=9, rettv=0x7fff004e0310, argcount=1, argvars=
0x7fff004e0140, firstline=5, lastline=5, doesrange=0x7fff004e030c,
evaluate=1, selfdict=0x0) at eval.c:8883
#21 0x0046ab2e in get_func_tv (name=0x1021ef0 "pchk#PChk",
len=9, rettv=0x7fff004e0310, arg=0x7fff004e0330,
firstline=5, lastline=5, doesrange=0x7fff004e030c, evaluate=1,
selfdict=0x0) at eval.c:8712
#22 0x00462cfb in ex_call (eap=0x7fff004e0410) at eval.c:3533
#23 0x004a36ef in do_one_cmd (cmdlinep=0x7fff004e0aa8,
sourcing=1, cstack=0x7fff004e0600, fgetline=
0x4ba15b , cookie=0x0) at ex_docmd.c:2930
#24 0x004a0439 in do_cmdline (cmdline=0x1061aa0 "call
pchk#PChk(s:Check,)", fgetline=0x4ba15b , cookie=
0x0, flags=11) at ex_docmd.c:1116
---Type  to continue, or q  to quit---
#25 0x004aa70f in do_ucmd (eap=0x7fff004e0c70) at ex_docmd.c:6742
#26 0x004a36c3 in do_one_cmd (cmdlinep=0x7fff004e1308,
sourcing=0, cstack=0x7fff004e0e60, fgetline=
0x4ba15b , cookie=0x0) at ex_docmd.c:2921
#27 0x004a0439 in do_cmdline (cmdline=0x0, fgetline=0x4ba15b
, cookie=0x0, flags=0) at ex_docmd.c:1116
#28 0x0053286b in nv_colon (cap=0x7fff004e1430) at normal.c:5335
#29 0x0052b0b7 in normal_cmd (oap=0x7fff004e1510, toplevel=1) at
normal.c:1159
#30 0x00647a74 in main_loop (cmdwin=0, noexmode=0) at main.c:1345
#31 0x006473b4 in main (argc=2, argv=0x7fff004e1828) at main.c:1044

(gdb) down
#2  

Re: backing out patch 866

[Charles E Campbell]

Tony Mechelynck wrote:
> On Mon, Feb 1, 2016 at 4:43 PM, Charles E Campbell
> <drc...@campbellfamily.biz> wrote:
>> Bram Moolenaar wrote:
>>> Charles Campbell wrote:
>>>
>>>> I'm afraid that patch 866, which is flawed, will end up in 7.5.  Could
>>>> this patch be backed out until its fixed, please?
>>> I'm not aware of a known problem.  What is the flaw?
>>>
>> Hello, Bram:
>>
>> With the latest batch of patches I can no longer compile vim without
>> patch#866, so I may be using an out-of-date version of vim for awhile.
>>
>> I ran pchk with the fully updated vim and got the usual hang:
>>
>> I think that the second gvim process (the "remote" gvim process) is
>> probably ok, its just awaiting commands.
>>
>> It seems to be hung in a 50msec delay -- which lasts forever.  FYI -- I
>> used gdb to attach to these two processes.
>>
>> Regards,
>> Chip Campbell
> Do you have steps to reproduce? (what to type or click, what happens,
> what you expected)
> When you talk of a "usual" hang it makes me think I lack the necessary
> context to understand what is being talked about.
>
Well, I hadn't intended this note to go to the entire list, but to Bram
only; my bad.

As far as context: you'll need to get pchk.vim: 
http://www.drchip.org/astronaut/vim/index.html#PCHK.
Set up a file with the one line:  :PChkSnapshot
Edit that file, run :PChkTry

This process worked before patch#866.  After patch#866, it hangs.

Chip Campbell

-- 
-- 
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: backing out patch 866

[Charles E Campbell]

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> I'm afraid that patch 866, which is flawed, will end up in 7.5.  Could
>> this patch be backed out until its fixed, please?
> I'm not aware of a known problem.  What is the flaw?
>

Hello, Bram:

With the latest batch of patches I can no longer compile vim without
patch#866, so I may be using an out-of-date version of vim for awhile.

I ran pchk with the fully updated vim and got the usual hang:

In the first gvim process:
(gdb) where
#0  0x003f4100efa0 in __nanosleep_nocancel () from
/lib64/libpthread.so.0
#1  0x00559b20 in mch_delay (msec=50, ignoreinput=1) at
os_unix.c:638
#2  0x005f3e99 in ui_delay (msec=50, ignoreinput=1) at ui.c:251
#3  0x004e7b2a in ServerWait (dpy=0x1fdd400, w=85983235,
endCond=0x4e8030 , endData=0x7fff0178f050, localLoop=0,
seconds=-1) at if_xcmdsrv.c:633
#4  0x004e80a6 in serverReadReply (dpy=0x1fdd400, win=85983235,
str=0x7fff0178f0b0, localLoop=0) at if_xcmdsrv.c:821
#5  0x00475dc8 in f_remote_read (argvars=0x7fff0178f200,
rettv=0x7fff0178f9e0) at eval.c:15857
#6  0x0046a5bd in call_func (funcname=0x233a0f0
"remote_read(serverid)", len=11, rettv=0x7fff0178f9e0, argcount=1,
argvars=0x7fff0178f200, firstline=6, lastline=6,
doesrange=0x7fff0178f3dc, evaluate=1, selfdict=0x0) at eval.c:8700
#7  0x0046a022 in get_func_tv (name=0x233a0f0
"remote_read(serverid)", len=11, rettv=0x7fff0178f9e0,
arg=0x7fff0178f990, firstline=6, lastline=6, doesrange=0x7fff0178f3dc,
evaluate=1, selfdict=0x0) at eval.c:8499
#8  0x004653f4 in eval7 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1, want_string=0) at eval.c:5204
#9  0x00464c51 in eval6 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1, want_string=0) at eval.c:4855
#10 0x00464809 in eval5 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1) at eval.c:4671
#11 0x00463d67 in eval4 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1) at eval.c:4366
#12 0x00463bba in eval3 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1) at eval.c:4281
#13 0x00463a30 in eval2 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1) at eval.c:4213
#14 0x00463863 in eval1 (arg=0x7fff0178f990,
rettv=0x7fff0178f9e0, evaluate=1) at eval.c:4141
#15 0x004637be in eval0 (arg=0x233a0f0 "remote_read(serverid)",
rettv=0x7fff0178f9e0, nextcmd=0x7fff0178faa8, evaluate=1) at eval.c:4101
#16 0x0045f2a6 in ex_let (eap=0x7fff0178faa0) at eval.c:1929
#17 0x004a098f in do_one_cmd (cmdlinep=0x7fff01790138,
sourcing=1, cstack=0x7fff0178fc90, fgetline=0x49e274 ,
cookie=0x7fff0178fc00) at ex_docmd.c:2930
#18 0x0049d6d9 in do_cmdline (cmdline=0x0, fgetline=0x485b47
, cookie=0x231baf0, flags=7) at ex_docmd.c:1116
#19 0x00485092 in call_user_func (fp=0x2320f20, argcount=1,
argvars=0x7fff01790680, rettv=0x7fff01790850, firstline=1, lastline=1,
selfdict=0x0) at eval.c:23959
#20 0x0046a484 in call_func (funcname=0x1ecde40 "pchk#PChk",
len=9, rettv=0x7fff01790850, argcount=1, argvars=0x7fff01790680,
firstline=1, lastline=1, doesrange=0x7fff0179084c, evaluate=1,
selfdict=0x0) at eval.c:8670
#21 0x0046a022 in get_func_tv (name=0x1ecde40 "pchk#PChk",
len=9, rettv=0x7fff01790850, arg=0x7fff01790870, firstline=1,
lastline=1, doesrange=0x7fff0179084c, evaluate=1, selfdict=0x0) at
eval.c:8499
#22 0x00462595 in ex_call (eap=0x7fff01790950) at eval.c:3502
#23 0x004a098f in do_one_cmd (cmdlinep=0x7fff01790fe8,
sourcing=1, cstack=0x7fff01790b40, fgetline=0x4b73db ,
cookie=0x0) at ex_docmd.c:2930
#24 0x0049d6d9 in do_cmdline (cmdline=0x231b870 "call
pchk#PChk(s:Try  ,)", fgetline=0x4b73db , cookie=0x0,
flags=11) at ex_docmd.c:1116
#25 0x004a79af in do_ucmd (eap=0x7fff017911b0) at ex_docmd.c:6742
#26 0x004a0963 in do_one_cmd (cmdlinep=0x7fff01791848,
sourcing=0, cstack=0x7fff017913a0, fgetline=0x4b73db ,
cookie=0x0) at ex_docmd.c:2921
#27 0x0049d6d9 in do_cmdline (cmdline=0x0, fgetline=0x4b73db
, cookie=0x0, flags=0) at ex_docmd.c:1116
#28 0x00530de7 in nv_colon (cap=0x7fff01791970) at normal.c:5335
#29 0x00529633 in normal_cmd (oap=0x7fff01791a50, toplevel=1) at
normal.c:1159
#30 0x00641efc in main_loop (cmdwin=0, noexmode=0) at main.c:1351
#31 0x0064183c in main (argc=4, argv=0x7fff01791d68) at main.c:1050


In the second gvim process:
(gdb) (gdb) where
Undefined command: "".  Try "help".
(gdb) #0  0x003f408df108 in poll () from /lib64/libc.so.6
(gdb) #1  0x003f420449f9 in ?? () from /lib64/libglib-2.0.so.0
(gdb) #2  0x003f42044e4c in g_main_context_iteration () from
/lib64/libglib-2.0.so.0
(gdb) #3  0x0061ef57 in gui_mch_wait_for_chars (wtime=-1) at
gui_gtk_x11.c:5504
(gdb) #4  0x0060e982 in gui_wait_for_chars (wtime=-1) at gui.c:2931
(gdb) #5  0x005f3da0 in ui_inchar (buf=0x22545f5 "", maxlen=70,
wtime=-1, tb_change_cnt=112) at ui.c:186
(gdb) #6  

backing out patch 866

[Charles E Campbell]

Hello!

I'm afraid that patch 866, which is flawed, will end up in 7.5.  Could
this patch be backed out until its fixed, please?

Thank you,
Charles Campbell

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

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

Re: [vim] Vim directory browsing is leaving swap files (#552)

[Charles E Campbell]

Marius Gedminas wrote:
> On Mon, Jan 11, 2016 at 03:31:17PM -0500, Charles E Campbell wrote:
>> Dino Morelli wrote:
>>> On Monday, January 11, 2016 at 1:29:48 PM UTC-5, Christian Brabandt wrote:
>>>> Closed #552.
>>>>
>>> Can you tell me if this is an existing issue already reported? Or if it's 
>>> not an issue at all but something that can be changed with config? There 
>>> are no details for why this has been closed.
>>>
>>> As it stands, I temporarily rolled back to 7.4.884 in my distro and pinned 
>>> it to no longer upgrade. Eventually I'm going to have to unpin that to let 
>>> my system update.
>>>
>> Did you (D.M.) miss my reply?  Please try v155h of netrw.
> Can we get an updated version of netrw included in vim?  Currently
> https://github.com/vim/vim/blob/master/runtime/plugin/netrwPlugin.vim#L23
> is v154.
>
v154 is the latest stable release.  I'm not ready to release v155 as yet
-- I've got more to work on with it.

C Campbell

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

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

Re: [vim] Vim directory browsing is leaving swap files (#552)

[Charles E Campbell]

Dino Morelli wrote:
> On Monday, January 11, 2016 at 1:29:48 PM UTC-5, Christian Brabandt wrote:
>> Closed #552.
>>
> Can you tell me if this is an existing issue already reported? Or if it's not 
> an issue at all but something that can be changed with config? There are no 
> details for why this has been closed.
>
> As it stands, I temporarily rolled back to 7.4.884 in my distro and pinned it 
> to no longer upgrade. Eventually I'm going to have to unpin that to let my 
> system update.
>
Did you (D.M.) miss my reply?  Please try v155h of netrw.

Regards,
Chip Campbell

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

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

Re: [vim] Vim directory browsing is leaving swap files (#552)

[Charles E Campbell]

Dino Morelli wrote:
>
> This behavior was observed with version 74994 but not in 74778
>
> Steps to reproduce:
>
> In a terminal window
>
> |$ mkdir -p vimswap/foo/bar $ touch vimswap/foo/bar/file1 $ touch
> vimswap/foo/bar/file2 $ cd vimswap |
>
> In a different terminal window
>
> |$ cd vimswap $ vim :e |
>
> Navigate with the directory browser to foo/bar/file1 and open it
>
> |:new :e |
>
> Navigate with the directory browser to foo/bar/file2 and open it
>
> In the first terminal window:
>
> |$ tree -a |
>
> You see this:
>
> ||-- foo |   |-- bar |   |   |-- file1 |   |   |-- file1swp |   |   |--
> file2 |   |   |-- file2swp |   |-- barswp |-- fooswp |-- swo |-- swp |
>
> Older versions of vim do this, I believe this is the correct behavior:
>
> ||-- foo |-- bar |-- file1 |-- file1swp |-- file2 |-- file2swp |
>
> Earlier versions of Vim did not keep these |sw?| files in directories
> that you navigated through This problem compounds for the entire time
> you keep this copy of vim running and use file browsing It keeps
> making more swap files, most of them in the top-level directory (the
> one that was named in the |:e| command
>
>
Please try netrw v155h available from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW

Regards,
Chip Campbell

-- 
-- 
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] error E201 when opening 3 large files with -o option when using LargeFile plugin

[Charles E Campbell]

Ben Fritz wrote:
> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote:
>> Having said that, I personally don't like the  argument as 
>> well. Perhaps we could use a new command modifier like
>> :keeppos windo ...
>>
>> That could be useful for other commands as well.
>>
> I like that idea better as well.
>
I, too, like the "keeppos" (short for keepposn?) command modifier.

I agree that one shouldn't change the default behavior due to backwards
compatability considerations.   My own plugins typically do a
save position and so wouldn't be affected by whether or not that
default behavior changed.

One thing about keepposn, though: a lot of the save position
commands currently available keep the cursor in the same place in the
text, but don't keep the text in the same position on the screen. 
Consequently using these causes the text to bounce around, which IMHO is
unacceptable.  For example,

:set ve=all
:help getcurpos()
:let scp= getcurpos()
:norm! 4k4zl
:call setpos('.',scp)

This set of operations restores the cursor position in the text, but
does not restore the text position relative to the window.

Regards,
Chip Campbell

-- 
-- 
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: warning during compilation

[Charles E Campbell]

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> I just noticed that there's a warning when compiling with gcc under
>> scientific linux:
>>
>> misc2.c: In function 'put_time':
>> misc2.c:6312: warning: ignoring return value of 'fwrite', declared with
>> attribute warn_unused_result
>>
>> In grep'ing through the patches, I see this one must have creeped in
>> back with patch#649, which in turn was trying to get rid of an annoying
>> compiler message for whatever compiler Michael Jarvis used.  The
>> solution was to use (void)fwrite(...) in the put_time() function, but
>> gcc v4.4.7 gets grumpy even when explicitly told not to worry by the
>> (void) cast.  IMHO gcc should let explicitly specified ignored values go
>> unmentioned, but there it is.
>>
>> Presumably, given the optimization and fortify settings, the function is
>> prototyped with __attribute_warn_unused_result__ .
>>
>> There are two solutions:
>>
>> * apply given patch: this removes the warning using gcc at the price of
>> a "silly" variable assignment.  I'm afraid that I wouldn't be surprised
>> if some compiler out there flags silly as an unused variable, though.
>> * specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0 .  Probably
>> won't want to do that, I'd guess.
>>
>> I didn't see any -W... settings to turn this message off, btw.
> Let's do it the same way as with put_bytes(): return OK or FAIL
> depending on what fwrite() returns, which then gets ignored.
>
OK -- please try the patch which implements this.

Regards,
Chip Campbell

-- 
-- 
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.
*** orig_misc2.c2016-01-07 15:57:47.401235338 -0500
--- misc2.c 2016-01-07 16:42:11.863004712 -0500
***
*** 6301,6307 
  /*
   * Write time_t to file "fd" in 8 bytes.
   */
! void
  put_time(fd, the_time)
  FILE  *fd;
  time_tthe_time;
--- 6301,6307 
  /*
   * Write time_t to file "fd" in 8 bytes.
   */
! int
  put_time(fd, the_time)
  FILE  *fd;
  time_tthe_time;
***
*** 6309,6315 
  char_ubuf[8];
  
  time_to_bytes(the_time, buf);
! (void)fwrite(buf, (size_t)8, (size_t)1, fd);
  }
  
  /*
--- 6309,6317 
  char_ubuf[8];
  
  time_to_bytes(the_time, buf);
! if (fwrite(buf, (size_t)8, (size_t)1, fd) < ((size_t)8))
!   return FAIL;
! return OK;
  }
  
  /*
*** proto/orig_misc2.pro2016-01-07 16:46:47.662667891 -0500
--- proto/misc2.pro 2016-01-07 16:43:52.284702126 -0500
***
*** 105,111 
  time_t get8ctime __ARGS((FILE *fd));
  char_u *read_string __ARGS((FILE *fd, int cnt));
  int put_bytes __ARGS((FILE *fd, long_u nr, int len));
! void put_time __ARGS((FILE *fd, time_t the_time));
  void time_to_bytes __ARGS((time_t the_time, char_u *buf));
  int has_non_ascii __ARGS((char_u *s));
  /* vim: set ft=c : */
--- 105,111 
  time_t get8ctime __ARGS((FILE *fd));
  char_u *read_string __ARGS((FILE *fd, int cnt));
  int put_bytes __ARGS((FILE *fd, long_u nr, int len));
! int put_time __ARGS((FILE *fd, time_t the_time));
  void time_to_bytes __ARGS((time_t the_time, char_u *buf));
  int has_non_ascii __ARGS((char_u *s));
  /* vim: set ft=c : */

Re: warning during compilation

[Charles E Campbell]

Charles E Campbell wrote:
> Bram Moolenaar wrote:
>> Charles Campbell wrote:
>>
>>> I just noticed that there's a warning when compiling with gcc under
>>> scientific linux:
>>>
>>> misc2.c: In function 'put_time':
>>> misc2.c:6312: warning: ignoring return value of 'fwrite', declared with
>>> attribute warn_unused_result
>>>
>>> In grep'ing through the patches, I see this one must have creeped in
>>> back with patch#649, which in turn was trying to get rid of an annoying
>>> compiler message for whatever compiler Michael Jarvis used.  The
>>> solution was to use (void)fwrite(...) in the put_time() function, but
>>> gcc v4.4.7 gets grumpy even when explicitly told not to worry by the
>>> (void) cast.  IMHO gcc should let explicitly specified ignored values go
>>> unmentioned, but there it is.
>>>
>>> Presumably, given the optimization and fortify settings, the function is
>>> prototyped with __attribute_warn_unused_result__ .
>>>
>>> There are two solutions:
>>>
>>> * apply given patch: this removes the warning using gcc at the price of
>>> a "silly" variable assignment.  I'm afraid that I wouldn't be surprised
>>> if some compiler out there flags silly as an unused variable, though.
>>> * specify either -U_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=0 .  Probably
>>> won't want to do that, I'd guess.
>>>
>>> I didn't see any -W... settings to turn this message off, btw.
>> Let's do it the same way as with put_bytes(): return OK or FAIL
>> depending on what fwrite() returns, which then gets ignored.
>>
> OK -- please try the patch which implements this.
>
Never mind -- I see you've already sent out a patch to do this.

Thank you,
Chip

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

[Charles E Campbell]

Bram Moolenaar wrote:
> Charles Campbell wrote:
>
>> I had a problem with patch#1001:
>>
>> Applying patch 7.4.1001
>> can't find file to patch at input line 18
>> Perhaps you used the wrong -p or --strip option?
>> The text leading up to this was:
>> --
>> |To: vim_dev@googlegroups.com
>> |Subject: Patch 7.4.1001
>> |Fcc: outbox
>> |From: Bram Moolenaar 
>> |Mime-Version: 1.0
>> |Content-Type: text/plain; charset=UTF-8
>> |Content-Transfer-Encoding: 8bit
>> |
>> |
>> |Patch 7.4.1001 (after 7.4.1000)
>> |Problem:test_viml isn't run.
>> |Solution:   Include change in makefile.
>> |Files:  src/testdir/Make_all.mak
>> |
>> |
>> |*** ../vim-7.4.1000/src/testdir/Make_all.mak2015-12-28
>> 21:35:07.773243000 +0100
>> |--- src/testdir/Make_all.mak2015-12-30 13:54:20.291584685 +0100
>> --
>> File to patch:
>>
>>
>> There is no testdir/Make_all.mak file.
> This file was added in patch 7.4.982.  Did you skip that one?
>
Hello!

FYI -- it was my script's problem -- the relevant loop is now...

for ptch in ${VIMVER}/../NewPatches/*.[0-9][0-9][0-9]
${VIMVER}/../NewPatches/*.[1-9][0-9][0-9][0-9] ; do
...
done

Thank you,
Chip Campbell

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

Folding patch updated for 7.4.1049

[Charles E Campbell]

I've attached the patch.

As a reminder: it makes folded lines more readable by doing some aligning.

Regards,
Chip Campbell

-- 
-- 
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.
*** eval.c.orig 2016-01-04 12:14:14.880933518 -0500
--- eval.c  2016-01-04 12:15:38.104291332 -0500
***
*** 11371,11376 
--- 11371,11380 
  char_u*r;
  int   len;
  char  *txt;
+ charfmt[40];
+ int nuw;
+ int padding;
+ unsignedrlen;
  #endif
  
  rettv->v_type = VAR_STRING;
***
*** 11404,11419 
s = skipwhite(s + 1);
}
}
!   txt = _("+-%s%3ld lines: ");
!   r = alloc((unsigned)(STRLEN(txt)
!   + STRLEN(vimvars[VV_FOLDDASHES].vv_str)/* for %s */
!   + 20/* for %3ld */
!   + STRLEN(s)));  /* concatenated */
if (r != NULL)
{
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
!   - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 11408,11429 
s = skipwhite(s + 1);
}
}
!   /* next two lines construct a format to be used for the folded region.
!* Example: assume nuw=5, then fmt becomes "+-%-5s%5ld lines: %*s"
!*/
!   nuw= number_width(curwin);  /* obtain log10(lastline) */
!   padding= STRLEN(vimvars[VV_FOLDDASHES].vv_str);
!   sprintf(fmt,"+-%%-%ds%%%dld lines:%%*s",(padding > nuw)? padding : 
nuw,nuw);
!   txt = _(fmt);   /* internationalize   */
!   rlen= (STRLEN(txt) - 11) + 2*nuw + ((padding > nuw)? padding : nuw) + 
STRLEN(s) + 10;
!   r   = alloc(rlen);
if (r != NULL)
{
+   if(padding > nuw) padding= nuw;
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
!   - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1),
!   padding," ");
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */