Re: [vim/vim] [netrw] Fix file move when g:netrw_keepdir=0 (PR #10757)

[Charles Campbell]

Alexandre Lepretre (Vim Github Repository) wrote:


@Matsa59  pushed 1 commit.

  * af9a9d2

Merge branch 'vim:master' into master




In looking over your patch, it looks like the problem was fixed earlier 
-- but the fix was put into a windows-only if-endif block. So, I've 
moved the older fix to handle all such actions (marked files move with 
g:netrw_keepdir == 1).


Please try netrw v172g (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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/44a99a43-0811-30e2-93fe-b2f0354bf606%40drchip.org.

Re: [vim/vim] [netrw] Fix file move when g:netrw_keepdir=0 (PR #10757)

[Charles Campbell]

Alexandre Lepretre (Vim Github Repository) wrote:


@Matsa59  pushed 1 commit.

  * 22bd830

Merge branch 'vim:master' into master

—
View it on GitHub 
 
or unsubscribe 
.
You are receiving this because you are subscribed to this 
thread.Message ID: 




Hello!

I'm netrw's maintainer; would you please send me a patch?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1984f79e-9a8a-44de-5adb-7b62739d2521%40drchip.org.

Re: how to get old versions of vim

[Charles Campbell]

Maxim Kim wrote:



On 27/08/2022 07:56, Charles Campbell wrote:


So, I thought what I'd like to do is to get vim 9.0 back (with no 
patches) and see if that worked. Then, if the plugin continues to 
misbehave, then I'd like to get vim 8.0. Once I have a version of vim 
where the plugin works I'd like to use git bisect to find the 
problematic patch. I realize that I'd have to learn more git. So, how 
to get vim 9.0, vim 8.0?




If you're ok with compiling vim then: (if you're sure v9.0. has no 
issues, if it has, choose older version tag)


1. git clone g...@github.com:vim/vim.git
2. git bisect start
3. git bisect bad
4. git bisect good v9.0.

build vim, check your plugin if it is bad: `git bisect bad`, if it is 
good: `git bisect good`


continue until commit that breaks your plugin is found.


Thank you, All! I'll give this a go when I've got the chance.
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a4504b87-ab01-73dd-b3a6-974af2cfe8a3%40drchip.org.

how to get old versions of vim

[Charles Campbell]

Hello:

I've got a plugin that I wrote years ago that I only just noticed is 
misbehaving; ie. it used to work properly but it no longer does.


So, I thought what I'd like to do is to get vim 9.0 back (with no 
patches) and see if that worked. Then, if the plugin continues to 
misbehave, then I'd like to get vim 8.0. Once I have a version of vim 
where the plugin works I'd like to use git bisect to find the 
problematic patch. I realize that I'd have to learn more git. So, how to 
get vim 9.0, vim 8.0?


I've traced the problem to visual mode stuff. Essentially, use visual 
mode to select some text, delete and move it to the end of file, operate 
on it, and move it back. When I do the commands that the plugin issues 
by hand, things work correctly. When the plugin does those same 
commands, instead of putting back the column of text vim forgets to use 
visual-block mode style insert (and visualmode() is still returning a 
ctrl-v before).


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/08c7f519-044f-7c56-d8f5-760d88d3d023%40drchip.org.

Re: RV: Fix netrw plugin issue using powershell #10931

[Charles Campbell]

miguel wrote:


References PR: https://github.com/vim/vim/pull/10931

Thanks for your time 

Thank you for the improvement! As you may surmise, I don't use 
powershell, so its really helpful to have folks who use something give 
feedback.


Currently, netrw v172f is on my website 
(http://www.drchip.org/astronaut/vim/index.html#NETRW), available for 
download, comments, etc. I have more things to work on with netrw, too.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/59a52763-405e-6cc9-1377-968fd81a7999%40drchip.org.

Re: [vim/vim] netrw opens empty buffer instead of actual file contents (#3276)

[Charles Campbell]

drakuno (Vim Github Repository) wrote:


Hello.

I am having this problem.

I followed the |h: netrw-debug| steps. You can find the results here: 
https://gist.github.com/drakuno/978224d0250ab3660c7ad83be4fcbbd7


An issue while debugging was that upon running |vim -u netrw.vimrc 
--noplugins -i NONE .| I got the following errors:


|Error detected while processing VimEnter Autocommands for 
"*"..function 
3_VimEnter[16]..1[1]..3_LocalBrowse[32]..script 
/home/drakuno/.vim/autoload/netrw.vim: line 56: E492: Not an editor 
command: DechoRemOn Press ENTER or type command to continue |

|Hello:

The problem here is that you don't have the Decho.vim plugin; that's the 
first step in :help netrw-debug. Did you download Decho.vba.gz, then 
type :so % ? It should put its components in your personal .vim/ 
directory automatically.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a0e8fd0d-76e3-4ebc-0e24-0b5a12d894b2%40drchip.org.

Re: syntax/vim.vim - support python << trim

[Charles Campbell]

Ben Jackson wrote:

Thanks, Bram, will do.

I just looked over your patch. Why is it necessary? syntax/vim.vim, 
without it, already handles


py3 

Re: [vim/vim] zipfile opens an empty buffer after 8.2.3468 (#8974)

[Charles Campbell]

Christian Brabandt (Vim Github Repository) wrote:


Okay, so how about the following patch. It checks, whether the 
filename starts with something that looks like a protocol specifier 
like |http:/| or in this case |zipfile:/| and in that case does not 
prepend the current directory to it (assuming a plugin will take care 
of reading this):


diff --git a/src/os_unix.c b/src/os_unix.c
index d192b6bcf..09e1f7d2f 100644
--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -2648,11 +2648,17 @@  mch_FullName(
 vim_strncpy(buf, fname, p - fname);
 if (mch_chdir((char *)buf))
 {
+ char_u *s = vim_strchr(fname, ':');
+
 // Path does not exist (yet).  For a full path fail,
 // will use the path as-is.  For a relative path use
 // the current directory and append the file name.
 if (mch_isFullName(fname))
 retval = FAIL;
+ // the filename begins with a protocol identifier like http://
+ // do not prepend the path to it, a plugin may handle it
+ else if ( s != NULL && *++s == '/')
+ retval = FAIL;
 else
 p = NULL;
 }

Looks like this patch works for me!

Thank you, Christian,

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/31e4fe3e-f8e4-3860-161b-0fa362fb64b2%40drchip.org.

Re: [vim/vim] zipfile opens an empty buffer after 8.2.3468 (#8974)

[Charles Campbell]

Christian Brabandt (Vim Github Repository) wrote:


Hm, the tar filetype come from this line in the plugin:

https://github.com/vim/vim/blob/master/runtime/autoload/zip.vim#L118

I don't think this is correct. For the other issue, let me have a 
quick look



Thanks! I'd completely forgotten about it (set ft=tar) and didn't do a 
search for it properly (I was looking for setf tar). Anyway, the reason 
for doing the setting is that the plugin is re-using Bram's tar file 
syntax highlighting. I've now changed that so it does a "setf zip" 
followed by a "run! syntax/tar.vim" to get the proper highlighting. The 
other issue is the important one and its what started misbehaving after 
I updated vim.


I've got to keep current on vim so as to keep syntax/vim.vim at least 
somewhat current (amongst other reasons).


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/7d7126ad-1692-03d3-425f-95ea728dffb7%40drchip.org.

Re: [vim/vim] runtime/syntax/vim: Fix vimOper ordinal. (#7966)

[Charles Campbell]

Bram Moolenaar wrote:

Tsuyoshi CHO (Vim Github Repository) wrote:

@tsuyoshicho  pushed 1 commit.

   * 419101f
 

 vim operator syntax fix



Hello, Tsuyoshi:

Unfortunately, github is telling me that it can't find your commit.
Would you please send a diff to me and an example illustrating the issue.

Adding ".diff" often helps.  Strangely, on github there is no button for
this.

https://github.com/vim/vim/commit/419101fb03dd48e8c73f9a419db666577311542e.diff

diff --git a/runtime/syntax/vim.vim b/runtime/syntax/vim.vim
index 1fd94752b79..25a4eb4698d 100644
--- a/runtime/syntax/vim.vim
+++ b/runtime/syntax/vim.vim
@@ -228,9 +228,9 @@ syn keyword vimAugroupKey contained aug[roup]
  " Operators: {{{2
  " =
  syn cluster   vimOperGroup
contains=vimEnvvar,vimFunc,vimFuncVar,vimOper,vimOperParen,vimNumber,vimString,vimType,vimRegister,vimContinue,vim9Comment
+syn match  vimOper "||\|&&\|[-+.!]"  skipwhite 
nextgroup=vimString,vimSpecFile
  syn match vimOper "\%#=1\(==\|!=\|>=\|<=\|=\~\|!\~\|>\|<\|=\)[?#]\{0,2}"  
  skipwhite nextgroup=vimString,vimSpecFile
  syn match vimOper "\(\"  
skipwhite nextgroup=vimString,vimSpecFile
-syn match  vimOper "||\|&&\|[-+.!]"  skipwhite 
nextgroup=vimString,vimSpecFile
  syn regionvimOperParenmatchgroup=vimParenSep  start="(" end=")" 
contains=vimoperStar,@vimOperGroup
  syn regionvimOperParenmatchgroup=vimSep   start="#\={" 
end="}" contains=@vimOperGroup nextgroup=vimVar,vimFuncVar
  if !exists("g:vimsyn_noerror") && !exists("g:vimsyn_noopererror")


Hello, Bram!

So it seems that its a changing of priority for the matching, as he 
simply moved a line to an earlier point in the file. I'd still like an 
example if the OP would please provide one so I can put it into my test 
suite.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a8150720-e9da-3cc1-7528-0a6db796029d%40drchip.org.

Re: [vim/vim] runtime/syntax/vim: Fix vimOper ordinal. (#7966)

[Charles Campbell]

Tsuyoshi CHO (Vim Github Repository) wrote:


@tsuyoshicho  pushed 1 commit.

  * 419101f

vim operator syntax fix



Hello, Tsuyoshi:

Unfortunately, github is telling me that it can't find your commit. 
Would you please send a diff to me and an example illustrating the issue.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ce025c64-cecc-9472-6cd3-759f39816b3c%40drchip.org.

syntax/vim.vim question -- should vim's heredocs be highlighted with comment support?

[Charles Campbell]

Hello,

Its been brought to my attention (thanks, Naruhiko Nishino) that vim's 
heredoc's syntax highlighting may not need to support commenting, either 
old-style or vim9 style. Some of the examples show vimL use, where 
comment support is nice, but other examples are just plain text. I'm 
leaning towards removing the comment highlighting support inside vim's 
heredoc syntax highlighting. Comments?


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/14f9f506-2bab-922d-e964-b5a6b6f388eb%40drchip.org.

after updating vim to 8.3.3132, getting seven error messages (E1208)

[Charles Campbell]

Hello:

Error detected while processing /home/cec/.vim/plugin/AsNeededPlugin.vim:
line   61: E1208: -complete used without -nargsline

I certainly didn't get these before, nor do I know what -nargsline is. 
The relevant line:


com! -nargs=0 -complete=command MakeANtags    call AsNeeded#MakeANtags()

OK, so what's -nargsline ?  :he nargsline shows nothing. Doing a grep 
nargsline  over the entire .vim/doc directory's *.txt files shows: nothing.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/57fba502-d5f5-73cb-560e-204902abdd06%40drchip.org.

are lambdas being used for legacy?

[Charles Campbell]

Hello:

I'm not knowingly using lambdas. I'm trying to debug some netrw code and 
I keep ending up with the following error:


." is a directory
Error detected while processing VimEnter Autocommands for "*"..function 
72_VimEnter[15]..1[1]..72_LocalBrowse[32]..netrw#LocalBrowseCheck:

line   26:
E171: Missing :endif
Press ENTER or type command to continue

There are no mismatched if-endif s in netrwPlugin.vim (LocalBrowse). The 
error appears to occur early in netrw#LocalBrowseCheck; early enough 
that I can visuallly verify that there aren't any mismatched 
if-elseif-endifs there, either. I have Decho-style debugging on in 
netrw.vim but not in netrwPlugin.vim.


It appears that the message is incorrect. By putting Decho()s into the 
code, I've narrowed down where the error appears to occur: redir @a . 
The command I'm interested in hasn't even run yet (ls!). Any hints?


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/b1c3fd18-b2cd-3f26-ee2c-c0450f6f0d59%40drchip.org.

Re: Insert non-rectangular selection

[Charles Campbell]

Maxim Kim wrote:



like a `zp` command, that does not add any trailing spaces.


Btw if you paste at the end of the `;text` no trailing spaces would be 
added.


Well, that messes with my own zp and zP maps, but no problem. I've also 
overridden p and P with them, so I can just eliminate zp and zP.


I've attached a compressed copy in case anyone is interested.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ebdf69e9-cea1-e010-b8be-3800e035ce4a%40drchip.org.


zmaps.vim.gz
Description: application/gzip

Re: [vim/vim] doc: ":tc" is no longer the abbreviation of ":tcl" (#8258)

[Charles Campbell]

lacygoill (Vim Github Repository) wrote:


did you detect this by luck or do you have an automated way of
finding whether the doc is inconsistent with the actual command
being run?

I guess it's a bit of both (luck + automated way). I'm rewriting the 
default Vim syntax plugin to get a better highlighting in Vim9 scripts 
(e.g. the types are not highlighted). In doing so, I'm trying to build 
programmatically the command responsible for the |vimCommand| syntax 
group. For the moment, this is what I have:


 #TODO: Whyis  `mapclear`in  `vimMap`while  `vmapclear`is  in  `vimCommand`?
 var  to_remove:list  = 75K.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9ab8305d-1df5-c04b-7be2-301c777207e0%40drchip.org.

vim help and netrw

[Charles Campbell]

Hello:

I have a tester for netrw which I was using to try to verify netrw 
before it gets sent out.


Its failing at an odd place; it issues a  key to obtain help. When I 
run the test with just the one script, the help shows 18 lines, a 
separator, 3 lines from the file, and a separator; the file shown is 
where I launched the help request. However, sometimes it shows 20 lines 
- separator - 1 line - separator, sometimes 19 lines - separator - 2 
lines - separator. Vim didn't used to be so mercurial about how many 
lines of help it showed. Is there an option now that I can set to tell 
vim how many lines of help I want shown?


FYI: the  key mapping to help:

nnoremap              :he netrw-quickhelp

I don't want to change that mapping as its part of 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a42ce4d2-38ba-9e9c-a470-2e0a551cdeb8%40drchip.org.

problem with a command that I didn't used to have

[Charles Campbell]

Hello:

A heads up...

I have my own script which runs latex called s:MakeLatex(early) . Note 
that it takes one parameter. However, recently, I run the command once 
and it works; the second time I get a "E118: Too many arguments for 
function: 127 MakeLatex . I set up a command "com! LatexFun fun! 
s:MakeLatex" so that I can see what MakeLatex looks like, and it has 
been redefined so that it no longer takes any arguments. No, there is no 
point at which MakeLatex redefines itself. I've found two places where 
that redefinition occurs:


   sil! cf errors
  sil! cope
  let b:coping= 1

It occurs during the "sil! cope"; removing the sil! shows (during the 
first try)


   Pattern not found: error:

Actually, there are two such error message lines, but after the first 
one the MakeLatex function has been re-defined to no longer accept an 
input argument. I've tried to make a simple example but haven't been 
able to do so so far, and I won't get back to trying to work on it until 
Monday at the earliest.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/385daf89-5e90-ce42-e96d-7b3b7a801e5e%40drchip.org.

Re: [vim/vim] Multi-line Comment Indenting With C -- incorrect initial spacing (#8118)

[Charles Campbell]

Bram Moolenaar (Vim Github Repository) wrote:


Closed #8118 .

Thank you, Bram! I've been suffering with that problem for years -- and 
it was just an option I set up years ago. I've now set that parameter to 
200...


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/831baf4d-1dee-9837-39f9-eddde86bbb2a%40drchip.org.

Re: [vim/vim] Multi-line Comment Indenting With C -- incorrect initial spacing (#8118)

[Charles Campbell]

cecamp (Vim Github Repository) wrote:


*Describe the bug*
Normally, a multi-line comment in C will show a new "*" at the correct 
indentation every time a carriage return is entered. However, that is 
not the case with the attached example file. Instead, extra (unwanted) 
spaces are prepended prior to the asterisk. Removing a line or two 
from the example file often shows no initial spacing.
(hopefully I've successfully attached cindent-prblm.c and bad.vimrc, 
because although nominally attached I don't see a confirmation list)


*To Reproduce*
Detailed steps to reproduce the behavior:

 1. vim -u bad.vimrc cindent-prblm.c
 2. Go to bottom of file: G
 3. Append to bottom of file: o
 4. You'll see that, instead of beginning with " * ", the line begins
with a number of unwanted extra spaces: " * "
 5. I will note that deleting a line in the comment area above
frequently changes the number of unwanted initial spaces,
sometimes yielding no initial spaces; ie. "* "

*Expected behavior*
It should start with " * " (or some number of spaces following the 
asterisk).

You can see what it should start with by

 1. vim -u bad.vimrc cindent-prblm.c
 2. Go to 4th line: 4G
 3. Append: o

*Environment (please complete the following information):*

  * Vim version [e.g. 8.1.1234] (Or paste the result of |vim --version|.)
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 16 2021 16:08:47)
Included patches: 1-2772
Compiled by c...@sphinx.fios-router.home

Huge version with GTK3 GUI. Features included (+) or not (-):
  * OS: [e.g. Ubuntu 18.04, Windows 10 1809, macOS 10.14]
Scientific Linux release 7.9 (Nitrogen)
  * Terminal: [e.g. GNOME Terminal, mintty, iTerm2, tmux, GNU screen]
(Use GUI if you use the GUI.)
gnome terminal 3.28.2


Well, that figures. Although I told the tracker to attach the two files, 
apparently it didn't. So I'll attach them now on the vimdev mailing 
list. Sorry about that...

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9fa977ec-b92a-af50-c095-2f5bc412de42%40drchip.org.
/* e
 *  A
 *  D
 *  V
 *
 *  T
 *  w
 *  Q
 *  o
 *
 * -
 * E
 * -
 *
 *⌠
 *⎮
 *⌡
 *
 *  ₓ
 *  I
 *  ᶜ
 * t
 *   c
 * -
 * A
 * -
 *   α
 *   φ
 *   n
 *
 * -
 * Performance: {{{2
filetype indent on
set cino=>s,e0,n0,f0,{0,}4,^-1s,:0,=s,g0,h1s,p2,t0,+2,(2,)20,*30
set fo=nroql2

Re: syntax/ratpoison.vim update

[Charles Campbell]

Bram Moolenaar wrote:

Magnus Woldrich wrote:


Attached is an updated ratpoison.vim syntax file. It's also here[0].

[0] 
https://github.com/trapd00r/vim-syntax-ratpoison/commit/873a2e465a314d5017a56c90d15f7bef18dbc43c

The patch doesn't apply to what I have, thus I got the file from github.
Note that the header has "Maintaner" instead of "Maintainer", I fixed
that.


Maybe along with the rat poison one gets a tan?
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f9128d17-a0ea-59f9-8eac-4324710afc47%40drchip.org.

Re: [vim] vim creates large swp files

[Charles Campbell]

Kirill Ryzhkov wrote:


Hi Vim developers!
I use vim on Linux all the time and found a problem with creating just 
huge swp files that can take up all the hard disk space.
If you open vim and copy a large text that can cause the linux console 
to hang and then you force close the console, after a couple of days 
the swp file size can reach hundreds of gigabytes. I have already 
encountered this problem twice and each time I had to look for where 
these swp files were created in which directory.

I am using vim version 8.0.1453.
Maybe there is a new version that fixes this bug ?

No, but since you're a linux user you can handle this problem yourself 
with a cron job.
Use  crontab -e  to edit the cron table commands. (cron is a daemon that 
runs at your specified times to do some work).

# # # # # /path/to/script

#1: minute (0-59)
#2: hour (0-23)
#3: day-of-month (1-31)
#4: month (1-12)
#5: day-of-week (0-6)

The shell script or command you have cron run can then check for size 
for those files which look like swap files, and if they're too big and 
too old; delete it.
For example:  ...time-spec-here..  /usr/bin/find "/home/username" -type 
f -name '*.sw[a-z]' -atime 3 -size 2G -exec "/bin/rm" "{}" ";"


Note, I haven't tested the above line, and instead of removing the file, 
you may want to move it to some directory instead (to see if the command 
is doing what you want).

Suggested reading: man crontab, man find. UAYOR.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/e7985590-7ed1-ec04-e8b7-4c66fcc4fded%40drchip.org.

Re: [vim/vim] netrw's "gx" functionality doesn't open URLs anymore in macOS (#4738)

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:


It seems that my patch has been (partly) included in the prerelease 
version: http://www.drchip.org/astronaut/vim/#NETRW.
If @cecamp  thinks it is ready for 
releasing, he will send the files to Bram. But he doesn't think it is 
ready?


That part of the update is ready; however, netrw is failing a test I 
have and I'm working on it.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/cf4c7a49-1ca3-2d83-c4ff-1e97559e01b0%40drchip.org.

Re: [vim/vim] Force help to open in current window. (#7534)

[Charles Campbell]

Pavol Juhas wrote:
I think this can work without opening/closing help, the trick is to 
set buftype=help.

Also :view is preferable so that the main help file opens as read-only.

$ vim
:view `=`
:setlocal buftype=help
:help grail


As a command, and using a modified method:

  com! -nargs=+ HE set bt=help|help 

then :HE topic will give one help on the requested topic in the current 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a9191d8f-af9f-35f0-4eb7-d78ab257e29b%40drchip.org.

Re: [vim/vim] netrw is slow over ssh (#7259)

[Charles Campbell]

Christian Brabandt wrote:

On Fr, 18 Dez 2020, Charles Campbell wrote:


Christian Brabandt (Vim Github Repository) wrote:

 As far as the clipboard goes: it copies the clipboard into a local
 variable, and only if the clipboard value has changed during the
 course of netrw's operation will netrw restore the clipboard value
 (thus avoiding having netrw always be the last one to modify the
 clipboard).

How about adding a configuration option to leave the clipboard alone if
set. This would solve two problems:

   * the clipboard won't be accessed at all if configured. That means,
 Neovim guys wouldn't have any problems, since the external
 clipboard provider may be slow.
   * It won't corrupt the clipboard in case of any non-text items in it.

People complaining could then set this variable and be fine.



The only problem -- something netrw does inadvertently modifies the
clipboard. That ends up with it being unexpectedly changed, which means
"clipboard won't be accessed at all" is not going to happen. Its like
history -- I don't want to change the history, but there's a lot of
operations that netrw does which change the history -- so there's a lot of
code to keep the history unchanged. I could have netrw optionally not
restore the clipboard, but I'm sure (because of earlier complaints) that
there will be a raft of new complaints. Well, I guess I'll put in
yet-another-option to prevent netrw from doing a save of the
clipboard (g:netrw_clipboard).

When would that happen, that netrw modifies the clipboard
unintentionally. Wouldn't that only be the case when the clipboard
option is set or the guioption includes a/A/p?
In looking over guioption a/A, I think that they would prevent the 
issue. As I recall, the problem occurrs with wide listings, because 
netrw does use visual selection to construct the columns internally. 
However, I wouldn't be certain that there's nothing else involved. I 
suppose that I could have netrw save guioption and safe-option a 
and A out.

(safe-option: what netrw uses while its constructing its display).



I suppose if the user explicitly uses "+y to paste to the clipboard in
netrw, that should be okay.


It'd be a help if vim itself had an option to leave something alone (ie.
setl leavealone="history:clipboard:jumps"); then netrw and other plugins
could set that, do their job, then unset it.

Wouldn't setting guioptions and clipboard option to a value that exclude
clipboard interaction be good enough?

There are NetrwKeepj commands all over the netrw code, and I'm not at 
all sure that it does that wherever needed even so, just to leave the 
jump table alone. I'll install the save guioption and see 
if that helps.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/acc1bba4-d6cc-8332-fda7-3d2e91fc1258%40drchip.org.

Re: [vim/vim] netrw is slow over ssh (#7259)

[Charles Campbell]

Christian Brabandt (Vim Github Repository) wrote:


As far as the clipboard goes: it copies the clipboard into a local
variable, and only if the clipboard value has changed during the
course of netrw's operation will netrw restore the clipboard value
(thus avoiding having netrw always be the last one to modify the
clipboard).

How about adding a configuration option to leave the clipboard alone 
if set. This would solve two problems:


  * the clipboard won't be accessed at all if configured. That means,
Neovim guys wouldn't have any problems, since the external
clipboard provider may be slow.
  * It won't corrupt the clipboard in case of any non-text items in it.

People complaining could then set this variable and be fine.


The only problem -- something netrw does inadvertently modifies the 
clipboard. That ends up with it being unexpectedly changed, which means 
"clipboard won't be accessed at all" is not going to happen. Its like 
history -- I don't want to change the history, but there's a lot of 
operations that netrw does which change the history -- so there's a lot 
of code to keep the history unchanged. I could have netrw optionally not 
restore the clipboard, but I'm sure (because of earlier complaints) that 
there will be a raft of new complaints. Well, I guess I'll put in 
yet-another-option to prevent netrw from doing a save of the 
clipboard (g:netrw_clipboard).


It'd be a help if vim itself had an option to leave something alone (ie. 
setl leavealone="history:clipboard:jumps"); then netrw and other plugins 
could set that, do their job, then unset 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2e6b1e0b-26ec-fe6d-2ed7-cd02bb8f078d%40drchip.org.

Re: How to create a syntax keyword at runtime?

[Charles Campbell]

  
  
Ron Aaron wrote:


  
  
  I explained exactly what I mean in the original post.
  
  
  Yes, of course I'm talking about a specific file type, but
the specific type is unimportant since it's something I'm
creating and not something in the vim syntax files.

What I intend is simply that if the user types in (the file
being created) something like:
  
  
      : foo bar ;
  
  
  Then "foo" becomes a syntax keyword. The criteria for
becoming a keyword in this context is that it is preceded by a
colon, and delimited by white-space. Thus 'bar' is not a
keyword, nor is ": foo".  Think of the leading colon-space as a
function declarator.

What I can't figure out is how to trap "foo" without trapping
the leading colon-space.
  

OK, as I said in my earlier reply, what you need is to have

 syn keyword colonDef foo

(or whatever you want foo to be highlighted as). The trick is to get
the : to trigger getting that new syntax statement. You can try
something like:
inoremap ; ;:call
InsertNewSyntax()a
  
  fun! InsertNewSyntax()
    if getline(".") =~ '^\s*:\s*\h\w*'
     let newsyn=
substitute(getline("."),'^\s*:\s*\(\h\w*\)\s*;','\1','')
     exe "syn keyword Statement ".newsyn
    endif
  endfunction

You could even make this part of your syntax file, even though it
isn't strictly syntax.  Every time you type a semicolon, the
function is called which checks to see if it can extract a word
from  : word ; and, if it can, it will install
that word as a new keyword.

Regards,
Chip Campbell


P.S. IMHO -- this topic would've better have to have been in
vim_...@googlegroups.com, as it isn't associated with developing
vim.
  




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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/5028cde4-248a-c91b-21f4-fa7b4492cf52%40drchip.org.

Re: How to create a syntax keyword at runtime?

[Charles Campbell]

Ron Aaron wrote:

Is this possible w/ vim's syntax highlighting?

On Wednesday, December 9, 2020 at 10:56:35 AM UTC+2 Ron Aaron wrote:

Hi all -

I want to have a keyword (user-defined function) highlighted by my
syntax file.

The code looks like this:

    :  foo  blah blah ;

In this case I want "foo" to be scooped up. What I'm doing now is
this:

     syn match colonDef "^\s*:\s\+\zs\S\+"

That highlights the correct thing (e.g. 'foo') where it's defined,
but I can't figure out how to get it to be highlighted elsewhere
in the code (e.g. when simply 'foo' appears without a leading colon).

How can I accomplish this?


What do you mean by "vim's syntax highlighting"? Assuming no filetype, 
say in a file called "joe.coffee", you could type


syn keyword colonDef foo
hi link colonDef Statement

and foo would be highlighted as Statement in your file.

Somehow I don't think you're really meaning "vim's syntax highlighting", 
but rather "vim's syntax highlighting for the XYZ filetype". Naturally, 
that missing information greatly affects things.  Syntax highlighting 
involves groups, containment, matches, regions, etc. My guess is that 
you want your modified "colonDef" highlighting to occur in some region 
defined by the filetype's syntax highlighting, but you've defined a 
match that is not contained in that region. To find out what that region 
is named, you could try my plugin: 
http://www.drchip.org/astronaut/vim/index.html#HILINKS and use :HLT!, 
move the cursor about, and you'll see a trace explaining what syntax and 
highlighting regions/etc are involved. Additionally, there's issues of 
priority involved, but often you can use "containedin=..." to get what 
you want.


Once you've done that, you could place a file in your 
.vim/after/syntax/XYZ.vim file the extra directions giving the 
additional highlighting you want.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/01ee4915-46e8-bb5a-df6c-ee6f008de599%40drchip.org.

Re: Patch 8.2.2068

[Charles Campbell]

  
  
Bram Moolenaar wrote:


  
Patch 8.2.2068
Problem:Transparent syntax item uses start/end of containing region.
Solution:   Do not change the startpos and endpos of a transparent region to
that of its containing region. (Adrian Ghizaru, closes #7349,
closes #7391)
Files:  src/syntax.c, src/testdir/test_syntax.vim



I wish there were startcontains=grouplist and endcontains=grouplist
for start=pattern and end=pattern in syntax highlighting.

As an example, consider heredocs in shell syntax:

cat <
      shHereDoc01
      this is   (testing trailing fgrep
  on cat line)
      a
  
      junky
      test  (--endtest--)
          $lookitup
  EOF  

 To support folding properly, we need cat through EOF to be in one
region. However, that | fgrep ... should be highlighted as regular
shell syntax. Currently its not because I cannot do both folding of
the entire heredoc and the shell syntax embedded in the start
pattern for the region.

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/483cf29f-91c2-be60-e470-8b0dd79b846c%40drchip.org.

unwanted escape sequences

[Charles Campbell]

  
  
Hello!

Recently, as in the last year or so, I've been getting unwanted
escape sequences; I've tracked down the issue to a simple operation:

vim -u NONE -U NONE
:q

and I get left with >4;m>4;2m.  My
system uses linux (Scientific Linux 7.9), xterm-256color, and
terminfo. In using infotmp xterm-256color I do not find any escape
sequences using that format. There are three that are close:
is2=\E[!p\E[?3;4l\E[4l\E>
  rmkx=\E[?1l\E>
  rs2=\E[!p\E[?3;4l\E[4l\E>

(ie. these are the only places in the infocmp output that show
\E> anywhere).

These unwanted escape sequences are normally just annoying, but they
have bothered some scripts I've written (bothered = as in caused to
fail).

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/64e9cae5-30d3-bb60-3891-142528e6702e%40drchip.org.

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

[Charles Campbell]

Charles Campbell wrote:

James McCoy wrote:
On Thu, Oct 22, 2020, 21:39 Charles Campbell <mailto:campb...@drchip.org>> wrote:


    I confess that I'm not a git master.  It'd be a help if you could
    send
    me a patch instead of a commit which I don't use


If you append ".diff" to a pull request URL, you get a diff you can 
download.  For example, https://github.com/vim/vim/pull/7188.diff


Cheers,
James




Hello:

Unfortunately:

   sphinx?   https://github.com/vim/vim/pull/7188.diff
   ksh: https://github.com/vim/vim/pull/7188.diff: not found [No such
   file or directory]
   sphinx?   https://github.com/vim/vim/pull/7188.patch
   ksh: https://github.com/vim/vim/pull/7188.patch: not found [No such
   file or directory]

Regards,
Chip Campbell


Well, that was dumb on my part.  Here's a new and updated problem:

git pull  https://github.com/vim/vim/pull/7188.diff
fatal: Not a git repository (or any parent up to mount point /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Again, I want to pull the diff/patch and not have it bother what I've 
got. I need to check it over, run it through my test suite, merge it 
with the latest netrw (at v171b at the moment).


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a6f119b3-420f-11b3-44b6-ed72675c0f3a%40drchip.org.

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

[Charles Campbell]

James McCoy wrote:
On Thu, Oct 22, 2020, 21:39 Charles Campbell <mailto:campb...@drchip.org>> wrote:


I confess that I'm not a git master.  It'd be a help if you could
send
me a patch instead of a commit which I don't use


If you append ".diff" to a pull request URL, you get a diff you can 
download.  For example, https://github.com/vim/vim/pull/7188.diff


Cheers,
James




Hello:

Unfortunately:

   sphinx?   https://github.com/vim/vim/pull/7188.diff
   ksh: https://github.com/vim/vim/pull/7188.diff: not found [No such
   file or directory]
   sphinx?   https://github.com/vim/vim/pull/7188.patch
   ksh: https://github.com/vim/vim/pull/7188.patch: not found [No such
   file or directory]

Regards,
Chip Campbell

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

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/29368858-9bf7-80c0-5f4d-218f6702%40drchip.org.

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

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:


Fix #4738 .
Since Netrw v165, the gx command had been broken at least on macOS and
MS-Windows. The platform-specific open commands support to handle a
remote URL directly, however, Netrw downloaded a file first.

Stop downloading a remote file when the viewer supports to handle a
remote URL.


Hello, K Takata:

I confess that I'm not a git master.  It'd be a help if you could send 
me a patch instead of a commit which I don't use, or inform me of the 
git command to download the file separately so I can diff and study it. 
I can see a nice pretty set of changes which is almost a diff, but I 
hate applying these things manually.  Iffy process, that.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/e3b5584b-ce15-8af7-e646-816305b17545%40drchip.org.

Re: [vim/vim] netrw's "gx" functionality doesn't open URLs anymore in macOS (#4738)

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:


I created PR #7188 .
@cecamp  Please check this.


I no longer have access to a Mac; I thus depend on someone to forward a 
patch to me which addresses the problem.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9f7cfd2b-1b93-58ed-83ea-5dfda04897a0%40drchip.org.

Re: [patch] fixed typos in doc of vim-8.2.1673

[Charles Campbell]

Dominique Pellé wrote:

Hi

Attached patch fixes typos in documentation
of Vim-8.2.1673.

I don't know, I rather like the idea of a re-tuned dictionary!  Like a 
guitar...

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/add44a98-c840-8c49-bb13-6264df78865c%40drchip.org.

A latex issue involving \text

[Charles Campbell]

Hello:

For some reason I just cannot find the email that involved the following 
problem:


   Correct syntax $math$ here
   $\text{(20, 25]}$
   Wrong syntax here...

Anyway, this is a problem with unwanted checking for matched 
delimiters.  I've now provided more selectivity for matching delimiter 
checking; one will be able to set


   let g:tex_matchcheck= '[({'

and get the default behavior; remove a delimiter and you won't get the 
associated matching-delimiter checking. In the case you've mentioned, 
try putting


   let g:tex_matchcheck= '[{'


along with the latest version of the syntax/tex.vim plugin 
(http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX).


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f5879ab2-2e9a-73a7-0645-d9c899552f72%40drchip.org.

matchit problems

[Charles Campbell]

Hello, Christian:

I see that you've picked up maintaining the matchit plugin.  I've been 
having problems with it recently -- problems that I didn't used to have.


* I used to be able to use the % key, in vimscript, to jump between if 
.. elseif ..endif
* I used to be able to bypass {{{3 in comments and still matchit-jump 
between matching {...}s.


To do these things I have in .vim/after/ftplugin, for vim:

   " Custom MatchIt Support: {{{1
   let b:match_words=
   
'\:\:\,\:\:\:\,\:\:\,\:\:\:\,\\)\@!\S:\,(:),\:\'


In .vim/ftplugin/c I have, for c:

" Custom Matchit Support: {{{1
let b:match_words=
   \ '\%(\:\:\,' .
   \ '\:\:\,'.
   \ 

and in .vim/ftplugin/syntax/c I have, for c:

   syn match    cFolding            "{{{\d\+" containedin=cComment
   syn match    cFolding            "}}}\d\+" containedin=cComment

   " modify matchit to exclude matching {}s and whatnot inside ChipDbg
   strings
   let b:match_skip='synIDattr(synID(line("."),col("."),1),"name") =~?
   "cComment\\|character\\|special\\|ChipDbg\\|cFolding"'

I verified this by not seeing the desired behavior with the current 
matchit and verifying that did work properly with the old matchit. For 
now, I'm using the Benji F's matchit...


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1fa14c4d-e579-b326-3298-3ad08c4845e1%40drchip.org.

Re: [vim/vim] Wrong syntax coloring (#6331)

[Charles Campbell]

Christian Brabandt wrote:

On Do, 25 Jun 2020, Charles Campbell wrote:

I think it is not about matchit itself, it was just an example. The
thing was when using a plugin manager like vim-plug and you want to
enable the matchit plugin, you use:

Plug 'k-takata/matchit.vim'

in your vimrc. And apparently, the ' is not detected as a string, but
rather as a mark command (or something similar). I am not sure if it
will be easy to fix however.

Oh -- Plug is a command set up by a plugin.  Yeah -- I don't see a good 
way to differentiate between marks and strings for it, either.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ceafee25-9fa0-ba49-3f44-4ab51310e40c%40drchip.org.

Re: [vim/vim] Wrong syntax coloring (#6331)

[Charles Campbell]

Charles Campbell wrote:

K.Takata (Vim Github Repository) wrote:


I can confirm that:
|'k| is shown as vimMark.
|-| is shown as vimOper.
|.| is shown as vimOper.
|vim| is shown as vimCommand.

@cecamp <https://github.com/cecamp> Could you check this?

BTW, |k-takata/matchit.vim| is now merged into |chrisbra/matchit|, 
and it is included in the official Vim repository.



I'll look into it.  However, I just got internet back today after a 
several day outage, and I'm busy for the next several days.

Well, I looked at

../vim/runtime/pack/dist/opt/matchit/plugin/matchit.vim
../vim/runtime/pack/dist/opt/matchit/autoload/matchit.vim

and neither 'k nor `k appear there.  Want to try to send me the errant 
plugin and tell me what lines are affected?  (I have 8.2.894)


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5707d88b-07b1-2af0-85d4-c74db06b9aa1%40drchip.org.

Re: [vim/vim] Wrong syntax coloring (#6331)

[Charles Campbell]

K.Takata (Vim Github Repository) wrote:


I can confirm that:
|'k| is shown as vimMark.
|-| is shown as vimOper.
|.| is shown as vimOper.
|vim| is shown as vimCommand.

@cecamp  Could you check this?

BTW, |k-takata/matchit.vim| is now merged into |chrisbra/matchit|, and 
it is included in the official Vim repository.



I'll look into it.  However, I just got internet back today after a 
several day outage, and I'm busy for the next several days.


I know I'm supposed to use "view it on GitHub" to reply to this, but 
GitHub wants a 6-digit verification code.  Unfortunately, it sends such 
to a no-longer-active email account I used to have, so apparently I've 
got to figure out how to fix that.


Also, the changes to matchit probably explain its no longer working 
correctly (for me).


In .vim/after/syntax/c/c.vim I have:

   syn match    cFolding            "{{{\d\+" containedin=cComment
   syn match    cFolding            "}}}\d\+"    containedin=cComment

and

   let b:match_skip='synIDattr(synID(line("."),col("."),1),"name") =~?
   "cComment\\|character\\|special\\|ChipDbg\\|cFolding"'

which was supposed to skip over comments and the {{{3 I sometimes have 
embedded therein.  It doesn't work, and so effectively the "%" operation 
no longer works well.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a17f8c0f-dc8f-55a3-2a02-cdbfdcceaa82%40drchip.org.

Re: [vim/vim] :help netrw-browse-maps show wrong mapping for netrw-c (#6266)

[Charles Campbell]

DiegoRenner (Vim Github Repository) wrote:


*Describe the bug*
In the output of :help netrw-browse-maps the keybinding to change the 
diretory to the current one is declared to be c.
In the output of :help netrw-c however it is said that the keybinding 
for this is now cd which seems to be correct.


*To Reproduce*

 1. Run vim
 2. Enter command :help netrw-browse-maps
 3. Check keybinding for netrw-c
 4. Enter command :help netrw-c
 5. Check keybinding for netrw-c

*Expected behavior*
:help netrw-browse-maps should show cd as the keybinding for
changing directory

*Screenshots*
From :help netrw-browse-maps
c Make browsing directory the current directory netrw-c
From :help netrw-c
netrw-c : This map's name has been changed from "c" to cd (see netrw-cd).
This change was done to allow for netrw-cb and netrw-cB maps.

*Environment (please complete the following information):*

  * Vim version 8.2.814
  * OS: 5.7.2-arch1-1
  * Terminal: st


Your environment should include information about which netrw you're 
using.  The latest one is netrw v170g, which you may get from my 
website: http://www.drchip.org/astronaut/vim/index.html#NETRW ; you'll 
find that address in :help netrw-debug .


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/758b7d17-304e-9c74-71f1-f655fe44a999%40drchip.org.

Re: [vim/vim] Distinguish between zg and zG, and zw and zW (#6140)

[Charles Campbell]

Christian Brabandt (Vim Github Repository) wrote:


How about:

diff --git a/runtime/doc/index.txt b/runtime/doc/index.txt
index 78d557f51..dded70d32 100644
--- a/runtime/doc/index.txt
+++ b/runtime/doc/index.txt
@@ -828,7 +828,7 @@  tag char  note action in Normal mode   
 ~
  |zD|   zD delete folds recursively
  |zE|   zE eliminate all folds
  |zF|   zF create a fold for N lines
-|zG| zG mark word as good spelled word
+|zG| zG temporarily mark word as good spelled word
  |zH|   zH when 'wrap' off scroll half a screenwidth
to the right
  |zL|   zL when 'wrap' off scroll half a screenwidth
@@ -837,7 +837,7 @@  tag char  note action in Normal mode   
 ~
  |zN|   zN set 'foldenable'
  |zO|   zO open folds recursively
  |zR|   zR set 'foldlevel' to the deepest fold
-|zW| zW mark word as wrong (bad) spelled word
+|zW| zW temporarily mark word as bad spelled word
  |zX|   zX re-apply 'foldlevel'
  |z^|   z^ cursor on line N (default line above
window), otherwise like "z-"
@@ -849,7 +849,7 @@  tag char  note action in Normal mode   
 ~
position the cursor at the end (right side)
of the screen
  |zf|   zf{motion} create a fold for Nmove text
-|zg| zg mark word as good spelled word
+|zg| zg permanently mark word as good spelled word
  |zh|   zh when 'wrap' off scroll screen N characters
to the right
  |zi|   zi toggle 'foldenable'
@@ -870,7 +870,7 @@  tag char  note action in Normal mode   
 ~
  |zuW|  zuWundo |zW|
  |zuG|  zuGundo |zG|
  |zv|   zv open enough folds to view the cursor line
-|zw| zw mark word as wrong (bad) spelled word
+|zw| zw permanently mark word as bad spelled word
  |zx|   zx re-apply 'foldlevel' and do "zv"
  |zz|   zz redraw, cursor line at center of window
  |z|  zsame as "zh"

As a minor point, it would be better english if it was "mark word as 
correctly spelled word" or "mark word as incorrectly spelled word".


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9b078c70-7097-201b-3f81-8d630c7a3927%40drchip.org.

Fwd: Vim syntax (variables)

[Charles Campbell]

Hello:

I don't know how my old (as in no longer active) email address remained 
in syntax/vim.vim, because I updated all of the syntax files with my new 
address. I just sent an updated syntax/vim.vim to Bram  with the correct 
email address. Just look at any of the other syntax files I maintain 
(tex.vim, etc) and you'll get the correct email address.


That said, your attachment looks pretty short -- I'll look it over, 
apply it, and run it through my test files.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/08d1bc6b-3018-4fc0-bcd5-c896058d60de%40drchip.org.

Re: git pull problems from vim repository

[Charles Campbell]

Tony Mechelynck wrote:

On Sun, May 17, 2020 at 9:40 PM Charles Campbell  wrote:

Hello:

I seem to have a problem doing git pull:

  fatal: Not a git repository (or any parent up to mount point /home)
  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM
not set).

Fortunately git clone https://github.com/vim/vim.git works, but that's a
lot more work.

Any suggestions on how to fix the git pull?
Chip Campbell

This kind of error happens when you aren't in the right repository:
ideally, the current repository should be, not the one which was
current when you cloned the master repo, but the one below that, which
you created by the clone operation and which contains subdirectories
src/ runtime/ etc. and IIUC .git/

I've had the equivalent error on Mercurial in the past. Usually a cd
to the appropriate top-of-the-clone directory fixed it.

If you are absolutely sure that you were in the _immediate_ parent of
src/ runtime/ .git/ etc. then I don't know.

Best regards,
Tony.

Thanks! -- my script which I run to do the updating (which included git 
pull) was, as you surmised, going to the wrong directory. Seems fixed now!

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6252e7b5-712f-bfbd-fe9a-2401da427253%40drchip.org.

git pull problems from vim repository

[Charles Campbell]

Hello:

I seem to have a problem doing git pull:

    fatal: Not a git repository (or any parent up to mount point /home)
    Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM 
not set).


Fortunately git clone https://github.com/vim/vim.git works, but that's a 
lot more work.


Any suggestions on how to fix the git pull?
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/e94fdf8b-020a-4019-01d4-077d5e8bd7a6%40drchip.org.

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

[Charles Campbell]

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


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


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


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


However, in this case the backslash is preceded by the double-quote 
which starts a string region.  The attempt to check for an odd/even 
number of backslashes fails, and thus the backquote is recognized 
incorrectly as beginning an in-string command rather than being 
escaped.  Not checking for that even/odd number of backslashes is 
obviously going to cause bad highlighting.  I need some way to check 
that a pattern is beginning with a backslash in a region, and thus can 
do without the odd-even preceding context checking.  I've asked Bram for 
something like a "startgroup=..." expression (similar to nextgroup=...) 
wherein I could do just that.


We'll see what happens...
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/05f04cbe-4d07-db26-901e-4138a1f36594%40drchip.org.

Re: On Windows - other tabs close when netrw explore navigates to a directory

[Charles Campbell]

More information would be helpful:

    * what/which binary is exhibiting the problem?
    * What is its version (:version)?
    * If you compiled it, how did you compile it (which compile-time 
options, which compiler)?
    * Is it for native Windows (usually gvim in that case), cygwin (vim 
or gvim), or what?
    * Please give a (hopefully small) sequence of instructions which 
exhibits the problem; start with vim -u NONE -U NONE or gvim -u NONE -U 
NONE (these command line commands avoid personal settings).

    * Please include any netrw specific settings you may be using
    * If it works with the NONEs, then try to track down which settings 
you have in your .vimrc and plugins along with a (small) sequence of 
instructions to exhibit the issue.


It is very difficult to fix a problem without enough information to 
duplicate the issue.  I'm having problems getting gvim/vim working as 
I'd like in a cygwin and native-windows setup so duplicating this for me 
is difficult as-is.


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/151a38c2-9e49-ff49-a784-e383223a585c%40drchip.org.

Fwd: Re: [patch] broken link pi_logipat.txt in runtime/doc/help.txt

[Charles Campbell]

 Forwarded Message 
From:   12 2016 <>
X-Mozilla-Status:   0001
X-Mozilla-Status2:  0080
X-Mozilla-Keys: 
Subject:Re: [patch] broken link pi_logipat.txt in runtime/doc/help.txt
To: vim_dev@googlegroups.com
References:

From:   Charles E Campbell 
Message-ID: <584f1c84.8070...@campbellfamily.biz>
Date:   Mon, 12 Dec 2016 16:54:12 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101
Firefox/43.0 SeaMonkey/2.40
MIME-Version:   1.0
In-Reply-To:

Content-Type:   text/plain; charset=ISO-8859-1
Content-Transfer-Encoding:  8bit



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] VIM highlights valid POSIX shell syntax as errorneous (#1147)

[Charles Campbell]

Andrew Shadura wrote:
>
> @chrisbra , why have you closed it? It is
> documented, yet it is wrong, and has to be changed.
>
>
"No need to quote RFCs or market  penetration statistics".  Clearly you
are a posix user; there are also many bash users.  In fact, there are
likely to be somewhat more bash users than posix users.  If
syntax/sh.vim can't automatically and correctly guess which shell type
is actually in use, it uses the old Bourne shell syntax.  This means
that posix/kornshell/bash users are likely to find things that are
highlighted as Errors -- which means they're thereby encouraged to look
it up in the documentation and telling syntax/sh.vim which one they want.

This complaint of yours is common; about 50% insist that I should use
bash as default (market penetration), about 50% insist, like you, that I
should use posix (rfc).  The default chosen is done to encourage folks
to make the correct decision for themselves.

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 cryptmethod uses SHA-256 for password-based key derivation (#639)

[Charles Campbell]

Bram Moolenaar wrote:
> My favorite example is when I have some text that I don't want my
> neighbor to read. Any encryption that Vim provides works for that.
> Also keep in mind that, no matter how strong your encryption is, there
> is always a weak point. Rembember key loggers? There never ever is
> 100% reliable encryption. So please don't overreact. 
We need quantum cryptography!  :)

Once quantum computers become available, all encryption will be for
nought.  (quantum cryptography, as I understand it, really only tells
you if someone is snooping on a communication intended to be secure; not
really useful for encrypting a file).

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 0/3] syntax: sh: heredoc fixes

[Charles Campbell]

Felipe Contreras wrote:
> Hello?
>
> Why hasn't this been fixed?
>
I don't read every message on the list, plus I've  been busy lately.  As
Nikolay Pavlov mentions, emailing me directly is the best way to get
things into the syntax files I maintain.  I suggest that you try the
latest version of syntax/sh.vim, which you can get from
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH.  Here
documents have been changed a bit since you made your patches; for
example, shHereDoc15 is the maximum heredoc type, which makes applying
your patches problematic.  Any changes one makes needs to pass my syntax
checking tests or, if one or more tests fails, the previous state needs
to be understood as to be in error and the new state as 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] propose vim as manpager that syntax highlights and follows symlinks (#491)

[Charles Campbell]

Nick James wrote:
>
> If I invoke vim without a file |vim| then type |:Man vim| I get |E492:
> Not an editor command: Man vim|. I /think/ this is expected.
>
> If I invoke vim without a file |vim| then type |:set filetype=man|
> followed by |:Man vim| it opens correctly. On my system (RHEL 6.5)
> |man| is at |/usr/bin/man|.
>
> It seems the issue is only when invoking via |tcsh|. I also gave it a
> quick test in |bash| with the same result.
>
>
With ManPageView
(http://www.drchip.org/astronaut/vim/index.html#MANPAGEVIEW) you'll get:

vim without a file, then :Man vim  : a manual page for vim  (tried this
with ksh, tcsh, bash, on a Scientific Linux, 6.7)
vim without a file, then :set ft=man, then :Man vim : a manual page for
vim  (tried this with ksh, tcsh, bash, on a Scientific Linux, 6.7)

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

Charles E Campbell wrote:
> 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).
>
I'd like to note that ManPageView, which can be run from within vim as
:Man, also supports help for php, perl, python, tex, and vim, as well as
the usual man pages.  One thing I like about its support for regular man
pages involves a map for  and , supporting man pages in
different "books".  Ie.
 for printf:  man 1 printf, man 1p printf, man 3 printf, and man 3p
printf  are all on my system.  I can do a man printf (which will bring
up manpageview interpreting the manpage), then shift-rightmouse until I
get to the printf help I want.

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

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
gcol.vimrc and repeat.

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.


gcolprblm.tar.bz2
Description: BZip2 compressed data

Re: Patch 7.4.1770

[Charles Campbell]

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.

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 hightlight breaks on "${VAR/FOO/\\[}" (#759)

[Charles Campbell]

Alexander Meshcheryakov wrote:
> "${VAR/FOO/\\[}"
>
> is a bashism to substitute |'FOO'| in |$VAR| with |'\['|
> vim fails to notice trailing double quote and the of a script becomes
> highlighted as doublequoted. Demo script to check highlighting:
>
> #!/bin/bash
> VAR1=FOOBAR
> VAR2="${VAR1/FOO/\\[}"
> echo "$VAR2"
Please try sh.vim v148-ASTRO-ONLY from
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH .

Thank you for the 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.

Re: Channel & job design

[Charles Campbell]

Charles Campbell wrote:
> Bram Moolenaar wrote:
>> Lcd wrote:
>>
>> There are also UNIX domain sockets (a.k.a. named pipes), which you get
>> essentially for free once you have the code for INET sockets. They are
>> as efficient as (unnamed) pipes. The code is already there, but it's
>> mutually exclusive with INET sockets. I don't think there is any
>> reason why the two can't coexist as separate mechanisms.
>> We can support that later.  As far as I know the main difference is how
>> you connect, after that it's basically the same.  Since we are using the
>> netbeans code it uses sockets.
>>
> At least on Unix and variants, there also are message queues.
>
The relevant functions:  msgget(), msgctl(), and msgop().  These produce
a messaging channel that is two-way (but not via internet, of course --
for that you'll need INET sockets).

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: Channel & job design

[Charles Campbell]

Bram Moolenaar wrote:
> Lcd wrote:
>
> There are also UNIX domain sockets (a.k.a. named pipes), which you get
> essentially for free once you have the code for INET sockets. They are
> as efficient as (unnamed) pipes. The code is already there, but it's
> mutually exclusive with INET sockets. I don't think there is any
> reason why the two can't coexist as separate mechanisms.
> We can support that later.  As far as I know the main difference is how
> you connect, after that it's basically the same.  Since we are using the
> netbeans code it uses sockets.
>
At least on Unix and variants, there also are message queues.

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] netrw remote delete

[Charles Campbell]

Carlos Pita wrote:
> Hi all,
>
> I'm getting this error message when trying to delete (pressing D) a file on a 
> remote directory:
>
> Error detected while processing function 
> 28_NetrwRemoteRm[32]..28_NetrwRemoteRmFile:
> line   60:
> E488: Trailing characters:   else if ret != 0
>
> Doing the same operation on a local directory works fine. Also, a remote 
> rename works.
>
Hello:

Please try v156e 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.

warnings and a hang

[Charles Campbell]

Hello:

I use

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

for configuring.  When I attempt to compile: (using gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-16))

if_perl.xs|53 warning| expected [error|warning|ignored] after '#pragma
GCC diagnostic'
if_perl.xs|55 warning| unknown option after '#pragma GCC diagnostic' kind
if_perl.c|2198 warning| expected [error|warning|ignored] after '#pragma
GCC diagnostic'

Vim builds, though, so I get 7.4.1583.  I don't use it as it still hangs
with pchk (http://www.drchip.org/astronaut/vim/index.html#PCHK), ever
since patch#866.

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

mattn wrote:
>
> Could you please try below?
>
> |$ vim -u NONE -N your.sh :syntax on ... move cursor into `--install`
> above ... :echo synIDattr(synID(line("."), col("."), 1), "name") |
>
> I get shOption.
>
>
I get shOption.  That's what --install is supposed to be highlighted as.
More fully:

SynStack:  shIf->shOption
HltTrace: shOption->shCommandSub->Special
fg<5> bg<-1>

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: special directory names causes Vim to display directories as if they were empty [Bug] (#657)

[Charles Campbell]

Jelly wrote:
>
> I discovered this whilst trying to use Vim's Netrw as my file manager
> (for more generic use).
> Me, including two other experienced users have successfully reproduced
> what seems to be a bug.
>
> *Reproducing the bug:*
>
> |$ mkdir "Foo [Bar]" && cd $_ $ touch a b c $ vim . |
>
> Result: Vim opens up with Netrw and displays an empty directory that
> contains only one item represented as a single dot (“.”).
>
> *The expected result:*
> Netrw should display the contents of the directory in this case the
> files [a, b, c].
>
>
I see the problem; I've fixed this one, but I still have a related
issue.  I will release a fix when I have one.

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

[Charles Campbell]

mattn wrote:
>
> try following on cursor at |--install|.
>
> |echo synIDattr(synID(line("."), col("."), 1), "name") |
>
> what do you get?
>
>
Using hilinks.vim, which gives rather more information, and with the
cursor on --install:

SynStack:  shOption   HltTrace:
shOption->shCommandSub->Specialfg bg

which is what its supposed to be.

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: Why "loadplugin" when there's already "loadplugins"?

[Charles Campbell]

Bram Moolenaar wrote:
> Right, the name is not ideal, but I could not think of a better one. I
> would also use "bundle" instead of package or pack, but plugin
> managers already use it and there could be a conflict. I hope that the
> new mechanism doesn't break existing behavior. Nikolay, you had quite
> a few comments on other solutions, let us know if you see something
> wrong with how packages and :loadplugin work. I hope the new mechanism
> can be used by plugin managers and make their work a bit easier. But
> they will also want to work with older Vim versions, might take a while. 
Alternate name: loadtrove

A trove is a collection of objects (ex. I found a trove of old baseball
cards).

I'm not sure its a better one or not -- I'll let y'all ruminate on it.

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

[Charles Campbell]

Josh Reichardt wrote:
>
> OS: |OS X 10.11.3|
> vim version: |7.4 (2013 Aug 10, compiled Feb 11 2016 11:34:55)|
> Info for filetype: |sh|
>
> To reproduce:
>
> |#!/usr/bin/env bash if ! which "xcode-select" > /dev/null; then echo
> "No xcode" else xcode-select --install fi |
>
> The select in xcode-select seems to be causing the problem? If I
> remove the --install flag the highlight error goes away.
>
>
Hello:

Please try v144 of syntax/sh.vim which you can get from my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH .

You'll need a vim v7.4 with patch#1141 for this update to affect the
highlighting, however.

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

[Charles Campbell]

mattn wrote:
>> The problem is that the cases of the variables are different.  So there's
>> no need to change the value "v3" to 1.
>> It seems that Dr. Chip's guards are based on the filenames.  So using
>> "loaded_logiPat" might be consistent.
> Yes, I know. So I said:
>
>   You may want to add logipat_version = 'v3'.
>
The problem here is that the plugin's name was changed -- and the
no-load variable uses weren't completely changed along with that.  When
I release v4 this will be fixed (see
http://www.drchip.org/astronaut/vim/index.html#LOGIPAT).

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

[Charles Campbell]

Bram Moolenaar wrote:
> Patch 7.4.1166
> Problem:Can't encode a Funcref into JSON.  jsonencode() doesn't handle the
> same list or dict twice properly.  (Nikolay Pavlov)
> Solution:   Give an error.  Reset copyID when the list or dict is finished.
> Files:  src/json.c, src/proto/json.pro, src/testdir/test_json.vim
>
I'm not sure which patch: 7.4.1166 or 7.4.1154, but I'm now getting:

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/libpng12 -g -O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=1   -o objects/crypt.o crypt.c
In file included from proto.h:98,
 from vim.h:1991,
 from crypt.c:13:
proto/json.pro:3: error: expected ')' before '*' tokenIn file included
from proto.h:98,
 from vim.h:1991,
 from blowfish.c:22:
proto/json.pro:3: error: expected ')' before '*' tokenIn file included
from proto.h:98,
 from vim.h:1991,
 from charset.c:10:
proto/json.pro:3: error: expected ')' before '*' token

In file included from proto.h:98,
 from vim.h:1991,
 from buffer.c:28:
proto/json.pro:3: error: expected ')' before '*' token

These errors look like js_read_T is not defined, and consequently cause
the compiling errors.

FWIW: I use scientific linux and I don't use json.

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.

Patch 866 Problem

[Charles Campbell]

Hello!

Bram asked me to send you my small script which evokes a problem I'm
having with Patch #866.  To use it:

vim -u NONE Hang.vim
:set nocp
:so %
:Hang

What happens: Hang sets up a remote gvim server which also sources
Hang.vim.  The server then gets told to call Hang#ToClient() which uses
server2client() to send the string "server's reply".  The :Hang command
has the client wait for a reply -- which, with patch#866, it doesn't
get.  Without patch#866, the communications work properly.  Hope you can
fix this!  RIght now I'm running a vim without patch#866 because a
script I use uses this type of communications procedure.

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.


Hang.vim
Description: application/octetstream

Re: Patch 7.4.960

[Charles Campbell]

Bram Moolenaar wrote:
> Patch 7.4.960
> Problem:Detecting every version of nmake is clumsy.
> Solution:   Use a tiny C program to get the version of _MSC_VER. (Ken Takata)
> Files:  src/Make_mvc.mak
>
Hi!  This patch isn't on ftp.home.vim.org yet.

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] comments inside parentheses mess up the syntax coloring of shell script (#487)

[Charles Campbell]

Christian Brabandt wrote:
>
> Please discuss this with the maintainer of the current indentation
> file. See Contributing.md
> 
>
>
I see no problems.  Try the latest syntax/sh.vim, which you can get
from:  http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH (v142).

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: proposed patch: Make syntax highlighting independent of 'iskeyword' setting

[Charles Campbell]

Christian Brabandt wrote:
> That is true with many patches however. It works only well, if
> contributors do use it. And a lot of syntax files need to be
> maintained, if only because the language evolves within times. Best,
> Christian 
Also because suggested syntax changes are occasionally ill-advised.  I
just got a suggestion, for example, that would have obliterated Bourne
shell syntax handling by conflating it with posix shell syntax.  And
there've been innumerable attempts to get a LaTeX package supported by
syntax/tex.vim (my position on that: its impractical to maintain
syntax/latex.vim with it supporting tens, hundreds, or thousands of
LaTex packages; instead, the best way is to set up small
after/syntax/tex/pkgname.tex files and publish them).

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 doesn't enter the directory symbolic link (#445)

[Charles Campbell]

yurivict wrote:
>
> When I view the directory (:new .), select symbolic link representing
> another directory, and hit Enter, vim still stays the original directory.
>
> vim-7.4.891 on FreeBSD-10.2
>
Hello!

I'm afraid that I don't see this problem.  (I use vim v7.4.891 with
Scientific Linux 6.7)

* please try the latest netrw
(http://www.drchip.org/astronaut/vim/index.html#NETRW which is at v154h)
* what netrw options, if any, are you using?
* what options are you using other than netrw ones?  acd, in particular,
can sometimes cause difficulties
* if the problem persists, please look at :help netrw-debug

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: Missing syntax highlighting in sh syntax inside the braces

[Charles Campbell]

Yuri wrote:
> I am seeing that '=' and '&&' elements aren't highlighted in this
> example.
> However, when when the braces are removed it highlights ok.
>
> filetype=sh, is_posix=1
> FreeBSD
>
> Yuri
>
>
> --- problem testcase: = and && aren't highlighted! ---
> #!/bin/sh
>
> myfunc() {
>   ([ ${myvar} = "YES" ] && aaa) ||
>   ([ ${myvar} = "NO" ] && bbb)
> }
>
> --- ok testcase ---
> #!/bin/sh
>
> myfunc() {
>   [ ${myvar} = "YES" ] && aaa
> }
>
Hello!

Please try the latest syntax/sh.vim which you can get from my website:
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: Issue 364 in vim: sh syntax highlight breaks on "'\$#'": everything after becomes shDoubleQuote

[Charles Campbell]

v...@googlecode.com wrote:
> a=b
> echo "'\$#'"
> c=d 
Hello!

Thank you for your feedback, and sorry it took awhile to get to it. 
Please try the latest syntax/sh.vim from my website to address this
issue: 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: netrw on windows+shellslash

[Charles Campbell]

mattn wrote:
> Hi.
>
> I wrote a patch to enable http/ftp/webdav access with netrw on 
> windows+shellslash. I'm using vim but not use cygwin or msys2. However, then 
> editing http file on vim, URL is displayed as:
>
>   http:\\example.com\foo.html
>
> So I want to use shellslash on windows too. Below is a patch to enable this.
>
> https://gist.github.com/mattn/0799137eea35ed4e789d
>
> Bram, I'm having one more idea to avoid this. It's keeping slash when the 
> buffer name seems to be URL. How do you think?
>
Hello, Mattn:

Would you just please send me the diff/patch directly?  You can find my
email address at the top of the netrw.vim plugin file.

Unless you can tell me how to get the diff off that github page...

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] Error detected while processing function 113_NetrwBrowseChgDir: (#442)

[Charles Campbell]

Aaron Goshine wrote:
>
> fchdir() to previous dir
> |Error detected while processing function
> 19_LocalBrowse[30]..netrw#LocalBrowseCheck[21]..28_NetrwBrowse[233]..28_PerformListing[220]..28_NetrwOptionRestore:
> line 86:
> |
>
>
It'd help me to help you if you used the latest release of netrw
(http://www.drchip.org/astronaut/vim/index.html#NETRW).  In the case
above with my copy of netrw.vim, line 86 is an endif -- which isn't
likely to be the issue.  Suggestions...

 * what were you doing to evoke this problem?  Try to come up with a
reproducible example.  Perhaps you can do something in vim's source
directory.  Please be explicit in your directions so I can try to
reproduce the issue.
 * what netrw-specific settings do you use, if any?  Which o/s?
 * does the problem happen when you use the netrw.vimrc file I've
attached?  (use  vim  -u netrw.vimrc --noplugins)
 * fchdir() -- is that a python thing?  What, exactly, does it do?
 * see  :help netrw-debug

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.
" start vim with:  vim -u netrw.vimrc --noplugins
set nocp
so $HOME/.vim/plugin/netrwPlugin.vim

Re: netrw on windows+shellslash

[Charles Campbell]

Nikolay Pavlov wrote:
> 2015-10-08 20:44 GMT+03:00 Charles Campbell <charles.e.campb...@nasa.gov>:
>> mattn wrote:
>>> Hi.
>>>
>>> I wrote a patch to enable http/ftp/webdav access with netrw on 
>>> windows+shellslash. I'm using vim but not use cygwin or msys2. However, 
>>> then editing http file on vim, URL is displayed as:
>>>
>>>   http:\\example.com\foo.html
>>>
>>> So I want to use shellslash on windows too. Below is a patch to enable this.
>>>
>>> https://gist.github.com/mattn/0799137eea35ed4e789d
>>>
>>> Bram, I'm having one more idea to avoid this. It's keeping slash when the 
>>> buffer name seems to be URL. How do you think?
>>>
>> Hello, Mattn:
>>
>> Would you just please send me the diff/patch directly?  You can find my
>> email address at the top of the netrw.vim plugin file.
>>
>> Unless you can tell me how to get the diff off that github page...
> There is “Raw” button in the top-right corner of the file contents
> pointing to 
> https://gist.github.com/mattn/0799137eea35ed4e789d/raw/eab15794ee2302a9ac371ff4971f56eb243896f9/gistfile1.diff.
>
Thank you, I think I've got it now.

Hmm, unfortunately I've got 28 out of 58 failed hunks.  I don't think I
can use this.  Mattn -- please get the latest netrw from
http://www.drchip.org/astronaut/vim/index.html#NETRW and try modifying that

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

[Charles Campbell]

Charles Campbell wrote:
> Bram Moolenaar wrote:
>> Patch 7.4.855
>> Problem:GTK: font glitches for combining characters
>> Solution:   Use pango_shape_full() instead of pango_shape(). (luchr, PR #393)
>> Files:  src/gui_gtk_x11.c
>>
>>
>> *** ../vim-7.4.854/src/gui_gtk_x11.c 2015-06-09 19:14:18.773373964 +0200
>> --- src/gui_gtk_x11.c2015-09-08 16:18:51.944711934 +0200
>> ***
>> *** 5063,5070 
>>   * done, because drawing the cursor would change the display. */
>>  item->analysis.shape_engine = default_shape_engine;
>>   
>> !pango_shape((const char *)s + item->offset, item->length,
>> !>analysis, glyphs);
>>  /*
>>   * Fixed-width hack: iterate over the array and assign a fixed
>>   * width to each glyph, thus overriding the choice made by the
>> --- 5063,5070 
>>   * done, because drawing the cursor would change the display. */
>>  item->analysis.shape_engine = default_shape_engine;
>>   
>> !pango_shape_full((const char *)s + item->offset, item->length,
>> !(const char *)s, len, >analysis, glyphs);
>>  /*
>>   * Fixed-width hack: iterate over the array and assign a fixed
>>   * width to each glyph, thus overriding the choice made by the
>> *** ../vim-7.4.854/src/version.c 2015-09-01 21:25:38.845874761 +0200
>> --- src/version.c2015-09-08 16:28:14.186863672 +0200
>> ***
>> *** 743,744 
>> --- 743,746 
>>   {   /* Add new patch number below this line */
>> + /**/
>> + 855,
>>   /**/
> Hello,
>
> After (attempting to) apply 855 (and 861):
> /home/cec/.SW/VIM/vim74/src/gui_gtk_x11.c:5067: undefined reference to
> `pango_shape_full'
>
> I did run configure, btw.  I'm using Scientific Linux release 6.7.
>
I'll further mention that I can no longer compile vim on my linux
workstation because of the undefined reference.  I see where use of it
is protected by a #ifdef HAVE_PANGO_SHAPE_FULL test, so presumably the
problem lies with the configure step.

So I slipped a

#undef HAVE_PANGO_SHAPE_FULL

just before the #ifdef and vim compiles again.

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 now crashes when opening large file:

[Charles Campbell]

Ben Fritz wrote:
> On Wednesday, September 9, 2015 at 6:10:24 AM UTC-5, Josh G wrote:
>> I keep getting crashes now when opening large file (4GB, 9GB).
>>
>> here was the last crash message details:
>> Problem signature:
>>   Problem Event Name:APPCRASH
>>   Application Name:  gvim.exe
>>   Application Version:   7.4.280.0
> The most recent Vim version is now 7.4.861. There have been multiple crash 
> fixes in the nearly 600 updates that have occurred since your version was 
> created. You might have better luck with the latest version. No guarantees, 
> though.
>
You might find the LargeFile.vim plugin of assistance in dealing with
large files, at least insofar as vim sluggishness is concerned.  You can
get it from http://www.drchip.org/astronaut/vim/index.html#LARGEFILE.

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

[Charles Campbell]

Christian Brabandt wrote:
> Hi Charles!
>
> On Mi, 09 Sep 2015, Charles Campbell wrote:
>
>> I'll further mention that I can no longer compile vim on my linux
>> workstation because of the undefined reference.  I see where use of it
>> is protected by a #ifdef HAVE_PANGO_SHAPE_FULL test, so presumably the
>> problem lies with the configure step.
>>
>> So I slipped a
>>
>> #undef HAVE_PANGO_SHAPE_FULL
>>
>> just before the #ifdef and vim compiles again.
> Did you update your source? Bram just committed a change.
>
>
Thank you!  Vim now compiles without my hack.

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

[Charles Campbell]

Bram Moolenaar wrote:
> Patch 7.4.855
> Problem:GTK: font glitches for combining characters
> Solution:   Use pango_shape_full() instead of pango_shape(). (luchr, PR #393)
> Files:  src/gui_gtk_x11.c
>
>
> *** ../vim-7.4.854/src/gui_gtk_x11.c  2015-06-09 19:14:18.773373964 +0200
> --- src/gui_gtk_x11.c 2015-09-08 16:18:51.944711934 +0200
> ***
> *** 5063,5070 
>* done, because drawing the cursor would change the display. */
>   item->analysis.shape_engine = default_shape_engine;
>   
> ! pango_shape((const char *)s + item->offset, item->length,
> ! >analysis, glyphs);
>   /*
>* Fixed-width hack: iterate over the array and assign a fixed
>* width to each glyph, thus overriding the choice made by the
> --- 5063,5070 
>* done, because drawing the cursor would change the display. */
>   item->analysis.shape_engine = default_shape_engine;
>   
> ! pango_shape_full((const char *)s + item->offset, item->length,
> ! (const char *)s, len, >analysis, glyphs);
>   /*
>* Fixed-width hack: iterate over the array and assign a fixed
>* width to each glyph, thus overriding the choice made by the
> *** ../vim-7.4.854/src/version.c  2015-09-01 21:25:38.845874761 +0200
> --- src/version.c 2015-09-08 16:28:14.186863672 +0200
> ***
> *** 743,744 
> --- 743,746 
>   {   /* Add new patch number below this line */
> + /**/
> + 855,
>   /**/

Hello,

After (attempting to) apply 855 (and 861):
/home/cec/.SW/VIM/vim74/src/gui_gtk_x11.c:5067: undefined reference to
`pango_shape_full'

I did run configure, btw.  I'm using Scientific Linux release 6.7.

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.

small problem with eval.c

[Charles Campbell]

Hello!

I just upgraded from patch level 841 to 854 -- and got two warnings. 
I've provided a trivial patch for the eval.c one and, as the misc

* eval.c|4412 error| 'i' undeclared (first use in this function)
* misc2.c|6265 warning| ignoring return value of 'fwrite', declared with
attribute warn_unused_result

I've "fixed" the latter warning by
   size_t throwaway;
  ...
  throwaway= fwrite(...

but I'm not sure that that approach is best (undoubtedly some compiler
will complain of an unused variable).

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.
*** old_eval.c  2015-09-03 14:07:20.254837390 -0400
--- eval.c  2015-09-03 14:07:31.604038517 -0400
***
*** 4407,4412 
--- 4407,4413 
break;
case 'i':   if (p[1] == 's')
{
+   int i;
if (p[2] == 'n' && p[3] == 'o' && p[4] == 't')
len = 5;
i = p[len];

another tooltip issue

[Charles Campbell]

Hello!

When I have a tooltip window appear, and then change workspaces (via
ctrl-alt-arrow under gtk/linux), the tooltip window appears in the new
workspace.  Moving the mouse about doesn't affect 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: Patch 7.4.840

[Charles Campbell]

Bram Moolenaar wrote:
> Patch 7.4.840 (after 7.4.829)
> Problem:Tooltip window stays open.
> Solution:   Send a WM_CLOSE message. (Jurgen Kramer)
> Files:  src/gui_w32.c
>
>
> *** ../vim-7.4.839/src/gui_w32.c  2015-08-25 12:21:23.583957205 +0200
> --- src/gui_w32.c 2015-08-26 23:10:03.847838259 +0200
> ***
> *** 4836,4841 
> --- 4836,4842 
>   delete_tooltip(beval)
>   BalloonEval *beval;
>   {
> + PostMessage(beval->balloon, WM_CLOSE, 0, 0);
>   PostMessage(beval->balloon, WM_DESTROY, 0, 0);
>   PostMessage(beval->balloon, WM_NCDESTROY, 0, 0);
>   }
> *** ../vim-7.4.839/src/version.c  2015-08-26 23:01:16.453676957 +0200
> --- src/version.c 2015-08-26 23:11:28.262906177 +0200
> ***
> *** 743,744 
> --- 743,746 
>   {   /* Add new patch number below this line */
> + /**/
> + 840,
>   /**/
>
While we're considering tooltip windows that stay open ...

I note that when having a tooltip window open in some file, then
switching workspaces (on a gtk-using linux box - scientific linux, so I
use ctrl-alt-arrow to change workspaces), the tooltip remains displayed
in the new workspace.  Been that way forever, though -- its not some
artifact due to this patch or anything.  Moving the mouse cursor about
in the new workspace doesn't clear the tooltip, either.

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: Question regarding :normal

[Charles Campbell]

Quinn Strahl wrote:
 On Wednesday, 26 August 2015 01:31:34 UTC-4, Justin M. Keyes  wrote:
 On Tue, Aug 25, 2015 at 10:00 PM, Quinn Strahl qstr...@gmail.com wrote:
 A difference in behaviour between :g and :rangenormal recently frustrated 
 me, and I wonder if it's up for debate:

 :g does a pass on matching lines and marks them before performing the 
 operation; this allows it to be generally undeterred by operations that 
 include addition/deletion of lines.

 :rangenormal does not do this, and as a result, it can get thrown off 
 by such operations. For (a trivial) example, on the hypothetical file:

 foo
 bar
 baz

 Performing :1,3normal yyp would produce the following result:

 foo
 foo
 foo
 foo
 bar
 baz

 Whereas the more intuitive result would be:

 foo
 foo
 bar
 bar
 baz
 baz

 There does exist a workaround, in the form of :rangeg/^/normal yyp -- 
 simply using :g in a way guaranteed to match every line in the desired 
 range -- but this is a bit of a compositional kludge.

 Would it be feasible to add the marking behaviour of :g to :normal, or is 
 that not worth implementing / a feature?
 Why do you want them to behave the same? They serve different
 purposes. Or rather, :g serves a purpose, and :normal is behaving in
 the typical way for a range command that performs edits/changes.


 Justin M. Keyes
 I have on many occasions run into situations where it would be very handy if 
 :normal worked the way :g does with respect to how it handles changes in 
 number of lines during operation, and I have not run into any case (nor can I 
 imagine one) where the current behaviour is favourable. It seems less 
 intuitive and less useful for it to behave this way.

Why not use

:[range]g/pattern/norm whatever

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: Gnuplot Syntax Patch

[Charles Campbell]

Josh Wainwright wrote:
 Hi Christian,

 Well, would you volunteer to maintain this syntax file?
 I haven't exactly volunteered, but am more than happy to do so. Is it
 back to this list that I send the updated file?

No, send your patches directly to Bram Moolenaar.  Tell him the
situation of non-contact with gnuplot's old mintainer, too.
(bram AT moolenaar DOT 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: minor bug in the LogiPat plugin for Vim

[Charles Campbell]

LCD 47 wrote:
 This has been mentioned on StackOverflow:  LogiPat sets
 g:loaded_LogiPat, but checks for loaded_logipat:

 http://stackoverflow.com/a/31695784

 Obvious fix below.

 Best regards,

 /lcd


 diff --git a/runtime/plugin/logiPat.vim b/runtime/plugin/logiPat.vim
 --- a/runtime/plugin/logiPat.vim
 +++ b/runtime/plugin/logiPat.vim
 @@ -36,7 +36,7 @@
  
   -
   Load Once: {{{1
 -if cp || exists(loaded_logipat)
 +if cp || exists(g:loaded_LogiPat)
   finish
  endif
  let g:loaded_LogiPat = v3

This bug has been fixed for quite a while -- but you need to get the
copy from my website:
http://www.drchip.org/astronaut/vim/index.html#LOGIPAT .  Bram picked up
the version from vim.sf.net.  I'll be submitting a more up-to-date
version soon, now that I'm back from a trip to Glacier National Park (USA).

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

[Charles Campbell]

Jean-François Bignolles wrote:
 Hello,

 Using different languages, I remarked that the Todo system (highlighting
 of special words inside comments) was currently a bit chaotic: some keywords
 are highlighted for one syntax, but not for an another one.

 (I won't talk here of syntax files which doesn't support this at all, syntax
 files which have special needs, i.e. syntax match / syntax region, etc.)

 Out of curiosity, I searched all the (uniques) lists of Todo keywords;
 currently there are about 40 (!) different variants:
 snip

OK -- assume that the user doesn't like the current list of Todo
keywords provided by c.vim; s/he wants LOOKATTHIS instead.  It isn't
that hard:

syn clear cTodo
syn keyword cTodo contained LOOKATTHIS

Place into .vim/after/syntax/c.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: expand(%) and utf-8 characters in directory names

[Charles Campbell]

Christian Brabandt wrote:
  Am 2015-04-20 18:28, schrieb Charles Campbell:
 I've attached a small tarball illustrating the problem I'm having with
 expand().

 gunzip jose.tar.gz
 tar xf jose.tar
 cd josé
 vi junk.vim
 :so %
 :echo x[4]
 :echo y[4]

 With the first echo, you'll see (using utf-8 for encoding)  e9.  This
 is the hex code for a é.  The second echo shows c3.

 :echo x

 shows /jose9/junk.vim

 :echo y

 shows /josé/junk.vim

 This problem has some definitely unwanted effects.  At least one person
 redid their home directory's name to avoid the accent, because netrw
 won't display it correctly (or use it correctly) because of this bug.

 That is an encoding issue. The 'é' in your tar archive is latin1 encoded
 while your Vim tries to read it as utf-8. BTW: How does the shell
 display it? Somehow the shell should know the encoding, so you might
 check the output of the locale command and try to use iconv() like this:
 iconv(expand(%:p), 'latin1', 'utf-8')

 BTW: There is a patch in the todo list, that should fix that issue.
 Search for 'systemencoding'
Hello, Christian:

Sorry for taking awhile to reply to this.  Looks like you're quite right
-- it was an encoding issue.   When I make a josé directory using
utf-8 it does show up with netrw correctly (with which I'm using utf-8).

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 to allow locking/unlocking the jump list

[Charles Campbell]

Carlo Baldassi wrote:
 Yes, I had that thought as well. However, as also clearly stated in the 
 documentation of lockmarks, the major drawbacks of this model are 1) not 
 adjusting for line insertions / deletions 2) the possibility of making the 
 command you're calling non-functional, it that command uses marks to jump 
 around internally (and even if it uses the jumplist, although I think that's 
 much less common.)

 The third patch I submitted after Justin's comments (the one which introduces 
 keepjumps! - but the name can be easily changed! - file name 
 lkjbang_patch.txt) actually solves all this, quite nicely in my opinion. 
 All operations inside keepjumps! work normally, and the state at the end is 
 restored as best as possible keeping track of insertions/deletions. Of 
 course, it comes at a slight cost in complexity/memory/speed. I could not 
 observe any noticeable difference in practice though. To me, its worst issue 
 is some code duplication, but it's not terrible.

 So that's actually my favourite choice at the moment (as I mentioned, I'd 
 even use that in place of the current keepjumps), and if the costs are 
 considered acceptable, I'd gladly polish that/rename/apply all required 
 changes.

 (Otherwise, I'm still reasonably happy with the simpler lockjumps version - 
 please let me know if there's anything I should do about that as well.)


Hello!

I'm wondering about how the patch(es) work -- is it a saverestore or is
it a prevent-any-modification?  I'm in favor of saverestore;
prevent-any-modification is certainly going to cause problems.

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 to allow locking/unlocking the jump list

[Charles Campbell]

Carlo Baldassi wrote:
 Hello!

 I'm wondering about how the patch(es) work -- is it a saverestore or is
 it a prevent-any-modification?  I'm in favor of saverestore;
 prevent-any-modification is certainly going to cause problems.

 Hi!

 The lockjumps patch (filename: lkjcmd_patch.txt) does a 
 prevent-any-modification to the jumplist. It works as the current 
 keepjumps, except 1) it's recursive 2) it doesn't lock marks. So it will only 
 cause problems with scripts which try to use the jumplist, e.g. by trying to 
 run `exe normal \c-o`. The lock is only for adding entries in the 
 jumplist; the jumplist is still updated in case of insertions/deletions. 
 (However, this will no longer be true if used in conjunction with lockmarks, 
 obviously.)

Which includes netrw and its netrw#BrowseX() function (ie. hit x with the 
cursor atop a special filename such as abc.pdf or use gx outside of netrw 
buffers). 


 The keepjumps! patch (filename: lkjbang_patch.txt) does a 
 save-and-restore. It acts on the same marks as the current keepjumps 
 implementation, plus the jumplist. It should not cause any problems to 
 running code, and keeps track of insertions/deletions in the backed-up list, 
 so that when it's restored everything should still make sense. Of course, 
 saving and restoring and keeping track of changes requires more internal work 
 than just locking up everything.

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: Wrong dollar sign red color highlighting in shell scripts

[Charles Campbell]

Yuri wrote:
 On 03/21/2015 02:08, John Little wrote:
 Indeed, that's ksh syntax; with ash it accepts it but includes an extra $ 
 character. The correct syntax with my ash is
 CR='\r'
 NL='\n'

 In this case flagging the $ as an error is useful, with my ash at least.

 In BSD Almquist shell, CR='\r' is literally backslash and r, and
 CR=$'\r' is carriage return char.
 This link suggests that this is the Bourne shell syntax:
 http://44acres.com/braindisc/?q=node/105 (search for $’string’ there )
 The same syntax works in bash, but this isn't posix syntax. So why vim
 flags it then, if it is Bourne shell syntax?


The Bourne shell supported by the syntax/sh.vim is the old Bourne
shell.  Although the link you gave earlier says its for the Bourne
shell, its just not the same one.

Another solution mentioned was to have syntax/sh.vim in posix mode. 
However, I was looking through the following link:

  http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

and don't see $'...' supported by posix.  I saw in looking through your
link that there was $..., too.  So, yes, its easy to get
syntax/sh.vim's posix mode to support that extra syntax, but its not
posix shell syntax, so I don't think it should be supported that way. 
Would setting   let g:is_bash=1  do the trick 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: runtime: zsh syntax: include Zsh options

[Charles Campbell]

Nikolai Weibull wrote:
 On Sun, May 10, 2015 at 6:47 PM, Daniel Hahler
 google-groups+2...@thequod.de wrote:
 I think it would be great if the Zsh options would be in the zsh syntax file,
 which would also allow for them to be used through syntaxcomplete#Complete.

 I am attaching a patch for this, but am unsure if it's good as it is:
 1. it should be linked to something else than Keyword maybe/probably, and/or
 use different colors?!

 2. it would be nice if it was only matched after setopt (but then also with
 no prefix, and multiple times - e.g. setopt localoptions noaliases).

 The list was generated using Zsh 5.0.7-dev-1.

 (I've tried to reach the maintainer directly about 3 weeks ago, but have not
 received a reply.)
 Hi!

 I’m pretty sure I’m not the maintainer anymore, but I don’t remember
 who took over and I can’t access the repository.  If I am, in fact,
 still listed as maintainer, please consider taking over the
 maintainership.

I got a abort: unknown revision 'vim74'! when I just tried to do an
update  (hg pull, hg update -C vim74), but the last time I did so (Apr
13, 2015, the syntax/zsh.vim file still had you, Nikolai, as maintainer.

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: expand(%) and utf-8 characters in directory names

[Charles Campbell]

Charles Campbell wrote:
 Christian Brabandt wrote:
 Hi Charles!

 On Fr, 27 Mär 2015, Charles Campbell wrote:

 Bram Moolenaar wrote:
 Charles Campbell wrote:

 I tried a directory named josé and found that netrw wasn't handling it
 well.  One of the reasons is expand(%), which is used to get the full
 path.  However, when in that directory, expand(%) shows
 /home/cec/joee9 instead of the desired /home/cec/josé .  Do I need to
 program around this or is this problem a bug with expand()?
 I don't see this problem.  What is 'encoding' set to?

 enc is utf-8.  By bisection of my .vimrc, I find that the following is
 enough in a .vimrc to cause the e9 to appear instead of é


 set nocp
 filetype plugin on
 set enc=utf-8
 In what filetype did you execute the expand() call?

 The filetype: netrw

 Try having a directory called josé with a file therein called one.

 vim -u (whatever you called the vimrc above)
 :echo expand(%:p)

 You'll see something like /home/cec/jose9/one

 With this, there's no filetype involved.

Hello!

I've attached a small tarball illustrating the problem I'm having with
expand().

gunzip jose.tar.gz
tar xf jose.tar
cd josé
vi junk.vim
:so %
:echo x[4]
:echo y[4]

With the first echo, you'll see (using utf-8 for encoding)  e9.  This
is the hex code for a é.  The second echo shows c3. 

:echo x

shows /jose9/junk.vim

:echo y

shows /josé/junk.vim

This problem has some definitely unwanted effects.  At least one person
redid their home directory's name to avoid the accent, because netrw
won't display it correctly (or use it correctly) because of this bug.

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.


jose.tar.gz
Description: GNU Zip compressed data

Re: Issue 321 in vim: syntax/tex.vim does not track braces inside \ensuremath{} blocks

[Charles Campbell]

v...@googlecode.com wrote:

 Comment #4 on issue 321 by ewtoo...@gmail.com: syntax/tex.vim does not
 track braces inside \ensuremath{} blocks
 https://code.google.com/p/vim/issues/detail?id=321

 I just checked again, and v.84 isn't working. I'd forgotten to prevent
 loading of my .vimrc last time using -u NONE. I'm getting the same
 error as I got when I started now. The first closing brace terminates
 the \ensuremath{} expression.

Please try v85 of syntax/tex.vim from my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX.

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

[Charles Campbell]

Ben Fritz wrote:
 On Friday, March 27, 2015 at 4:06:47 PM UTC-5, Bruno Sutic wrote:
 - lastly, it has been mentioned a couple times vim plugin community is
 already on github. The objective statement that proves this: github
 currently has 42,636 vim related repositories, bitbucket has only 1652
 (this is based on a simple search for vim on both github and
 bitbucket).
 Does this simple search include the automatically created mirrors that
 Vundle created for each and every vim.org plugin? Authors that have no
 presence on Github whatsoever nevertheless have their plugin on github
 due to this.

I don't think I'm in the curmudgeon group or in the excited group.

* I use the ftp site.  Will that continue? (mostly because I have
scripts that download and compile everything)  (ex.  upd 670-685  will
update vim with the given range of patches).
* I occasionally use mercurial to get the latest runtime.
* I'm pretty sure that a number of my plugins have been made available
via git; I had nothing to do with that.  So the simple search would
definitely be skewed as I see 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: expand(%) and utf-8 characters in directory names

[Charles Campbell]

Christian Brabandt wrote:
 Hi Charles!

 On Fr, 27 Mär 2015, Charles Campbell wrote:

 Bram Moolenaar wrote:
 Charles Campbell wrote:

 I tried a directory named josé and found that netrw wasn't handling it
 well.  One of the reasons is expand(%), which is used to get the full
 path.  However, when in that directory, expand(%) shows
 /home/cec/joee9 instead of the desired /home/cec/josé .  Do I need to
 program around this or is this problem a bug with expand()?
 I don't see this problem.  What is 'encoding' set to?

 enc is utf-8.  By bisection of my .vimrc, I find that the following is
 enough in a .vimrc to cause the e9 to appear instead of é


 set nocp
 filetype plugin on
 set enc=utf-8
 In what filetype did you execute the expand() call?

The filetype: netrw

Try having a directory called josé with a file therein called one.

vim -u (whatever you called the vimrc above)
:echo expand(%:p)

You'll see something like /home/cec/jose9/one

With this, there's no filetype involved.

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: expand(%) and utf-8 characters in directory names

[Charles Campbell]

Bram Moolenaar wrote:
 Charles Campbell wrote:

 I tried a directory named josé and found that netrw wasn't handling it
 well.  One of the reasons is expand(%), which is used to get the full
 path.  However, when in that directory, expand(%) shows
 /home/cec/joee9 instead of the desired /home/cec/josé .  Do I need to
 program around this or is this problem a bug with expand()?
 I don't see this problem.  What is 'encoding' set to?

enc is utf-8.  By bisection of my .vimrc, I find that the following is
enough in a .vimrc to cause the e9 to appear instead of é


set nocp
filetype plugin on
set enc=utf-8


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.

expand(%) and utf-8 characters in directory names

[Charles Campbell]

Hello:

I tried a directory named josé and found that netrw wasn't handling it
well.  One of the reasons is expand(%), which is used to get the full
path.  However, when in that directory, expand(%) shows
/home/cec/joee9 instead of the desired /home/cec/josé .  Do I need to
program around this or is this problem a bug with expand()?

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: broken sytanx of vim.vim

[Charles Campbell]

mattn wrote:
 let g:foo = 1

 The SynID of foo is not vimVar. Currently, it's vimIsCommand. IFAIK, it was 
 vimVar in few month ago. I'm thinking vimIsCommand is too generally pattern.

 syn match vimIsCommand\\h\w*\ contains=vimCommand
 syn match vimVar  \[bwglsav]:\K\k*\
 syn match vimVarcontained \\K\k*\


Please try syntax/vim.vim v7.4-16.

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.