Re: expand("%") and utf-8 characters in directory names
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/joe 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 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
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/joe 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 wrote: > 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 > sorry, I neglected to mention where you can find that version: http://www.drchp.org/astronaut/vim/index.html#SYNTAX_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: broken sytanx of vim.vim
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.
Re: [bug] a problem with an autocmd event and a server
Christian Brabandt wrote:
> Hi Charles!
>
> On Do, 26 Feb 2015, Charles E Campbell wrote:
>
>> Hello!
>>
>> I've attached a script which illustrates the problem.
>>
>> vim -u NONE -N prblm.vim
>> :so %
>> :q (in the gvim that's showing prblm.vim, NOT the remote gvim)
>>
>> Behavior:
>>
>> * a remote server gvim shows up (this happens)
>> * a message "verify its working" shows up in the server's message
>> line (this happens)
>> * both the client vim quits (this happens) AND the remote server
>> gvim quits (this does NOT happen)
>>
>> The remote server gvim should quit because of an autocmd VimLeave event:
>>
>>au VimLeave call RemoteSend(":qa!")
> You are missing the pattern for the VimLeave autocommand.
> I believe it works if you provide one (or *)
>
Thank you, Christian. Sorry about the noise. It was a late night brain
freeze
Thanks,
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.
[bug] glob won't list symbolic links that point to non-existing files
Hello:
Please try the following on a linux system:
mkdir PROBLEM
cd PROBLEM
ln -s file1 file2
Doing ls shows file2 exists (but it points to a non-existing file).
Fire up vim:
vim -u NONE -N
:echo string(glob("*"))
shows that glob() returns an empty string, whereas it should show
file2. "file2" is a symbolic link, which means that its a file that has
contents (which happens to be a path to a non-existing file).
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.
Netrw and Patch592 problem
Hello! Looks like patch#592 stops netrw from working with remote files: vim scp://hostname/ no longer works. Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Vim 7.4.579: wincmd range problem with manpageview plugin
Gary Johnson wrote: > I just updated to 7.4.579 on one of my Linux systems. With the > cursor over "printf" in a C file, typing K results in the following > error message. > > Error detected while processing function > manpageview#KMap..manpageview#ManPageView: > > > line 258: > E16: Invalid range: 3wincmd - > Press ENTER or type command to continue > > I'm using plugin/manpageviewPlugin.vim version 25b (Aug 06, 2012) > and autoload/manpageview.vim version 25k ASTRO-ONLY (Apr 05, 2013). > > Hello, Gary: Patch #565 introduced a problem in its attempt to error-check ranges; its being worked now. To demonstrate: try vim -u NONE :52wincmd v and you'll likely get an "invalid range" error message. 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.
echomsg problem
Hello:
I've found something peculiar. When I put :echomsg "GOT HERE" into
autoload/netrw.vim just before the "if v:version < 704..." test (line#25
with v153), no output appears. No output appears with a subsequent
:messages.
This difficulty means that an echomsg will show no output inside that
test, either. Consequently, a vim system with 7.4.52 showed no error
message when the user attempted to use netrw, even though a message via
echomsg was attempted by netrw. Its easy enough to simulate this issue
without reverting back to an old vim, by the way -- simply change the
test in line#25 to
if v:version < 704 && !has("patch999")
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: :wincmd bug
Bram Moolenaar wrote: > Sung Pae wrote: > >> On Thu 8 Jan 2015 at 05:15:55PM -0600, guns wrote: >>> On Thu 8 Jan 2015 at 03:06:45PM -0800, Amadeus Demarzi wrote: Using vim with patches 1-567 I get a range error when calling wincmd in certain contexts: vim -u NONE :split :wincmd+ # works as expected :2wincmd+ # also works as expected :3wincmd+ # throws the error: Invalid Range In fact, any value above 2 seems to throw this error. >>> Just a guess; I was planning on looking into it tonight. >> The problem is indeed introduced in 7.4.565. In particular: >> >> --- a/src/ex_cmds.h >> +++ b/src/ex_cmds.h >> @@ -1574,7 +1574,7 @@ EX(CMD_winsize,"winsize", >> ex_winsize, >> ADDR_LINES), >> EX(CMD_wincmd, "wincmd", ex_wincmd, >> NEEDARG|WORD1|RANGE|NOTADR, >> -ADDR_LINES), >> +ADDR_WINDOWS), >> EX(CMD_windo, "windo",ex_listdo, >> BANG|NEEDARG|EXTRA|NOTRLCOM, >> ADDR_LINES), >> >> I think the author of the patch forgot about: >> >> :wincmd + >> :wincmd - >> :wincmd < >> :wincmd > >> :wincmd n >> :wincmd s >> :wincmd v >> :wincmd | >> >> which all interpret the [count] as a number of lines, and not a number >> of windows. >> >> I suppose the preceding commands could be spared the bounds check, but >> as long as Ctrl-W commands are spared from the checks as well¹, I would >> advocate just reverting the hunk above. >> >> guns >> >> ¹ :execute "normal! 100\+" > Yeah, this is getting complicated. :wincmd can have different types of > ranges. Using the line count is actually also wrong. > There probably is no other solution than postponing the range check > until the argument has been parsed. That makes it difficult to give a > meaning to ":$wincmd". Depending on the argument it can mean the last > window or the maximum size. > Actually :wincmd <, >, and | are column oriented, not line oriented. So, sometimes its window oriented, line oriented, or column oriented. I guess that means we need new window commands that are buffer oriented and tab oriented just to make things maximally difficult! :) Regards, Chip -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.5
Bram Moolenaar wrote: > Marcin Szamotulski wrote: > >> On 04:17 Mon 08 Dec , Bram Moolenaar wrote: >>> Patch 7.4.542 >>> Problem:Using a range for window and buffer commands has a few problems. >>> Cannot specify the type of range for a user command. >>> Solution: Add the -addr argument for user commands. Fix problems. (Marcin >>> Szamotulski) >>> Files: src/testdir/test_command_count.in, >>> src/testdir/test_command_count.ok src/testdir/Make_amiga.mak >>> src/testdir/Make_dos.mak, src/testdir/Make_ming.mak, >>> src/testdir/Make_os2.mak, src/testdir/Make_vms.mms, >>> src/testdir/Makefile, runtime/doc/map.txt, src/Makefile, >>> src/ex_cmds.h, src/ex_docmd.c, src/ex_getln.c, >>> src/proto/ex_docmd.pro, src/vim.h, >> This patch is not available through ftp: >> ftp://ftp.vim.org/pub/vim/patches/7.4/ > Should be there now. > > And thanks for confirming that some people still use ftp :-). > I still use ftp (actually, curl, but that's a ftp user, too). That's because I have a script that uses it, so I simply type: getpatch 538-542 (for example); it gets the patches, applies them, builds vim. Chip -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch][Win32] Problem with very long file name
Ken Takata wrote: To avoid this problem, maximum length should be limited to MAX_PATH bytes. (If someone want to handle a file name which is longer than MAX_PATH bytes and shorter than MAX_PATH characters, he should set 'enc' to utf-8.) I wrote a patch to fix this problem. Please check the attached patch. Regards, Ken Takata As an English speaker and writer, I seldom would personally encounter this problem. However, doesn't utf-32 permit 4-byte characters, and wouldn't such characters in a sufficiently long filename still be problematic? 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: is not highlighted (syntax/vim.vim)
Charles Campbell wrote: Hello: Looks like I somehow omitted including it. Anyway, please try the attached syntax/vim.vim . Sorry about that, listers -- another case of my intending to respond to one person but spamming the entire list instead. Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
conceal, cchar, and combining characters
Hello:
I recently received a request that $\bar{a}$ be supported: ie. it should
be conceal-char'd and appear as a: a̅
So I tried
syn match texMathSymbol '\\bar{a}' contained conceal cchar=a̅
but this construct doesn't produce the desired output: instead, it shows
an "a" instead. Presumably that's because what appears after the "=" is
an a followed by a combining character, 0x0305.
I'm not sure if this is a bug or an extension request.
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: is not highlighted (syntax/vim.vim)
Kenichi Ito wrote: Hi Chip, I tried vim.vim v7.4-30 in your website, but is not highlighted. This patch fixes it. --- diff --git a/runtime/syntax/vim.vim b/runtime/syntax/vim.vim index e86611a..b9b815c 100644 --- a/runtime/syntax/vim.vim +++ b/runtime/syntax/vim.vim @@ -327,7 +327,7 @@ syn keyword vimMap mapc[lear] smapc[lear] syn keyword vimUnmapcu[nmap] iu[nmap] lu[nmap] nun[map] ou[nmap] sunm[ap] unm[ap] unm[ap] vu[nmap] xu[nmap] skipwhite nextgroup=vimMapBang,vimMapMod,vimMapLhs syn match vimMapLhs contained "\S\+" contains=vimNotation,vimCtrlChar skipwhite nextgroup=vimMapRhs syn match vimMapBang contained "!" skipwhite nextgroup=vimMapMod,vimMapLhs -syn match vimMapMod contained "\c<\(buffer\|expr\|\(local\)\=leader\|plug\|script\|sid\|unique\|silent\)\+>" contains=vimMapModKey,vimMapModErr skipwhite nextgroup=vimMapMod,vimMapLhs +syn match vimMapMod contained "\c<\(buffer\|expr\|\(local\)\=leader\|nowait\|plug\|script\|sid\|unique\|silent\)\+>" contains=vimMapModKey,vimMapModErr skipwhite nextgroup=vimMapMod,vimMapLhs syn match vimMapRhs contained ".*" contains=vimNotation,vimCtrlChar skipnl nextgroup=vimMapRhsExtend syn match vimMapRhsExtend contained "^\s*\\.*$" contains=vimNotation,vimCtrlChar,vimContinueskipnl nextgroup=vimMapRhsExtend syn case ignore --- Hello: Looks like I somehow omitted including it. Anyway, please try the attached syntax/vim.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. vim.vim Description: application/octetstream
Re: improved folding legibility [patch included]
Bram Moolenaar wrote:
Charles Campbell wrote:
Updated patch. The "optionsptch" patch will insert one line into the
options.txt help; I separated it out in case its not wanted.
Thanks, I'll put it in the todo list. I'll await comments for a little
while.
Hello!
I've attached an improved patch which adjusts the allocated size of the
fold text to handle the fold's +--- string, even if there's an awful
lot of folds.
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.
*** keep_eval.c 2014-09-10 10:50:35.997331712 -0400
--- eval.c 2014-09-12 14:28:55.766340893 -0400
***
*** 11030,11035
--- 11030,11039
char_u*r;
int len;
char *txt;
+ charfmt[30];
+ int nuw;
+ int padding;
+ unsignedrlen;
#endif
rettv->v_type = VAR_STRING;
***
*** 11063,11078
s = skipwhite(s + 1);
}
}
! txt = _("+-%s%3ld lines: ");
! r = alloc((unsigned)(STRLEN(txt)
! + STRLEN(vimvars[VV_FOLDDASHES].vv_str)/* for %s */
! + 20/* for %3ld */
! + STRLEN(s))); /* concatenated */
if (r != NULL)
{
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 11067,11088
s = skipwhite(s + 1);
}
}
! /* next two lines construct a format to be used for the folded region.
!* Example: assume nuw=5, then fmt becomes "+-%-5s%5ld lines: %*s"
!*/
! nuw= number_width(curwin); /* obtain log10(lastline) */
! padding= STRLEN(vimvars[VV_FOLDDASHES].vv_str);
! sprintf(fmt,"+-%%-%ds%%%dld lines:%%*s",(padding > nuw)? padding :
nuw,nuw);
! txt = _(fmt); /* internationalize */
! rlen= (STRLEN(txt) - 10) + 2*nuw + ((padding > nuw)? padding : nuw) +
STRLEN(s);
! r = alloc(rlen);
if (r != NULL)
{
+ if(padding > nuw) padding= nuw;
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1),
! padding," ");
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
Re: improved folding legibility [patch included]
Charles E Campbell wrote:
Bram Moolenaar wrote:
Charles Campbell wrote:
I find reading the folded lines to be less than ideal, as the extra
spacing required of the "+---"s varies and so lines: doesn't line up.
This patch makes all the +---... prefixes take up 5 spaces (using %-5s,
so it uses padding). By itself, this makes the folded sections, no
matter how deep, also line up; the patch now pads the beginning of the
folding titles with spaces indicating folding depth (and retaining the
+ marking).
I find the result to be more quickly legible.
It does look nicer. The 5 spaces is an arbitrary number, perhaps that
should be an option? Or perhaps we can use 'numberwidth'?
I see that numberwidth defaults to 4 and its a minimum width. Perhaps
I should use numberwidth and similarly use the qty of lines in the
buffer (ie. use the number_width() fun ction). I think that re-use
of numberwidth would be ok. I'll submit another patch soon (I've
written it, but I'm still testing it).
Updated patch. The "optionsptch" patch will insert one line into the
options.txt help; I separated it out in case its not wanted.
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.
*** keep_eval.c 2014-09-10 10:50:35.997331712 -0400
--- eval.c 2014-09-12 10:45:41.405368593 -0400
***
*** 11030,11035
--- 11030,11038
char_u*r;
int len;
char *txt;
+ charfmt[30];
+ int nuw;
+ unsignedrlen;
#endif
rettv->v_type = VAR_STRING;
***
*** 11063,11078
s = skipwhite(s + 1);
}
}
! txt = _("+-%s%3ld lines: ");
! r = alloc((unsigned)(STRLEN(txt)
! + STRLEN(vimvars[VV_FOLDDASHES].vv_str)/* for %s */
! + 20/* for %3ld */
! + STRLEN(s))); /* concatenated */
if (r != NULL)
{
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 11066,11088
s = skipwhite(s + 1);
}
}
! /* next two lines construct a format to be used for the folded region.
!* Example: assume nuw=5, then fmt becomes "+-%-5s%5ld lines: %*s"
!*/
! nuw = number_width(curwin); /* obtain log10(lastline) */
! sprintf(fmt,"+-%%-%ds%%%dld lines:%%*s",nuw,nuw);
! txt = _(fmt); /* internationalize*/
! rlen= (STRLEN(txt) - 10) + 3*nuw + STRLEN(s);
! r = alloc(rlen);
if (r != NULL)
{
+ int padding;
+ padding= STRLEN(vimvars[VV_FOLDDASHES].vv_str);
+ if(padding > nuw) padding= nuw;
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1),
! padding," ");
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
5246a5247
> This option also affects the display of folds.
Re: improved folding legibility [patch included]
Christian Brabandt wrote: Am 2014-09-10 17:02, schrieb Charles Campbell: Hello! I find reading the folded lines to be less than ideal, as the extra spacing required of the "+---"s varies and so lines: doesn't line up. This patch makes all the +---... prefixes take up 5 spaces (using %-5s, so it uses padding). By itself, this makes the folded sections, no matter how deep, also line up; the patch now pads the beginning of the folding titles with spaces indicating folding depth (and retaining the + marking). I find the result to be more quickly legible. Regards, Chip Campbell Could you show a screenshot of an unpatched vs. patched Vim? OK, please see http://www.drchip.org/astronaut/vim/before.png http://www.drchip.org/astronaut/vim/after.png Look at "lines" and how they do/do-not align. 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.
improved folding legibility [patch included]
Hello!
I find reading the folded lines to be less than ideal, as the extra
spacing required of the "+---"s varies and so lines: doesn't line up.
This patch makes all the +---... prefixes take up 5 spaces (using %-5s,
so it uses padding). By itself, this makes the folded sections, no
matter how deep, also line up; the patch now pads the beginning of the
folding titles with spaces indicating folding depth (and retaining the
+ marking).
I find the result to be more quickly legible.
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.
*** keep_eval.c 2014-09-10 10:50:35.997331712 -0400
--- eval.c 2014-09-10 10:53:02.878652619 -0400
***
*** 11063,11078
s = skipwhite(s + 1);
}
}
! txt = _("+-%s%3ld lines: ");
r = alloc((unsigned)(STRLEN(txt)
! + STRLEN(vimvars[VV_FOLDDASHES].vv_str)/* for %s */
! + 20/* for %3ld */
! + STRLEN(s))); /* concatenated */
if (r != NULL)
{
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1));
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
--- 11063,11082
s = skipwhite(s + 1);
}
}
! txt = _("+-%-5s%4ld lines:%*s");
r = alloc((unsigned)(STRLEN(txt)
! + STRLEN(vimvars[VV_FOLDDASHES].vv_str) /* for %s
*/
! + 30/* for %4ld and
padding */
! + STRLEN(s))); /* concatenated
*/
if (r != NULL)
{
+ int padding;
+ padding= STRLEN(vimvars[VV_FOLDDASHES].vv_str);
+ if(padding > 5) padding= 5;
sprintf((char *)r, txt, vimvars[VV_FOLDDASHES].vv_str,
(long)((linenr_T)vimvars[VV_FOLDEND].vv_nr
! - (linenr_T)vimvars[VV_FOLDSTART].vv_nr + 1),
! padding," ");
len = (int)STRLEN(r);
STRCAT(r, s);
/* remove 'foldmarker' and 'commentstring' */
Re: [patch] Fix netrw#NetrwBrowseX with `kdeinit` running, but no `kfmclient`
Daniel Hahler wrote: When there is a `kdeinit4` process, but `kfmclient` is not installed `BrowseX` fails to open an URL (it falls through to the last else block). This happened on a non-KDE system, where `kdeinit4` was installed/started for an unknown reason, but konqueror/kfmclient is not available. This patch also makes the `system()` call only when necessary (via a function), and will prefer `xdg-open` unconditionally also for potential KDE systems. After all, `xdg-open` is better aware of the current desktop environment and is designed for use cases like this. The old code was primarily meant to handle edge cases when `gnome-open` was used. I have left it as a fallback in case `xdg-open` might not be available. The patch is available in a branch at: https://github.com/blueyed/vim/compare/fix-netrw-with-kdeinit (which includes a commit to fix trailing whitespace). I am attaching the patch from the main commit (https://github.com/blueyed/vim/commit/b5e13acebc11c13290d3f3dd9940b1ab181f47a3). Thanks! I'll look into 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: small sh.vim patch
Gary Johnson wrote: On 2014-08-09, Charles E Campbell wrote: Gary Johnson wrote: set -o ignoreeof# Don't let Ctrl-D exit the shell. Hello, Gary: Are you actually using the old Bourne shell? This problem does not appear when using the Korn/Posix shell or the Bash shell. Try reading a bit of :help sh.vim . Hello, Gary: Please try the attached syntax/sh.vim. Thank you for your feedback, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. sh.vim Description: application/octetstream
Re: patch for small error in netrw docs
exatto wrote: Hi, I think I found a small mistake in the help docs for the netrw Explorer. In an example to set the default style for the explorer to the tree-style view in vimrc the value used is 4. Elsewhere the docs show the possible values to be only 1-3, with 3 for the tree-style view. So I changed it accordingly. I don't know if it is necessary to create a patch for such a small change, but here it is. Thank you for the patch; I'd actually already caught that one, though, a month or two ago. Try updating your netrw: http://www.drchip.org/astronaut/vin/index.html#NETRW , because there's bug fixes, too. Chip -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] syntax make.vim
matthias.hinkfo...@uni-rostock.de wrote: Hello list, the attached patch addresses 2 issues regarding comments in Makefiles: 1) a comment in a rule is not highlighted, e.g.: target1: # comment1 here, comment1 is not highlighted. 2) (Makefile-) comments in repipes destroy the highlighting of the recipe, e.g: target2: command1 # comment2 command2 here, command1 is highlighted while command2 is not. This is my first time hacking vim scripts. I don't even know if it has the correct syntax and style. Feel free to correct me. The patch applies to the file runtime/syntax/make.vim in the default brach of the hg repository. If you look at the top of the syntax/make.vim file, you'll find the maintainer's contact information (Claudio Fleiner). Please try to contact him with your patch. 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: odd character drawing problem
Tony Mechelynck wrote: On 17/07/14 21:55, Bram Moolenaar wrote: Charles Campbell wrote: The following line, when in a buffer that vim is displaying: m=⎣ℜ(b-a)⎦=1~1026 has the "script R" displayed correctly when the cursor is swept over it from right to left, but the "script R" is displayed incorrectly when the cursor is swept over it from left to right. I'm using: Scientific Linux 6.5 (Carbon) vim 7.4.372 set guifont=Monospace\ Bold\ 12 configure --with-features=huge --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-cscope Looks like a problem with the font: the character is wider than the display cell. Thus when drawing the character to the right of the "script R" it erases the rightmost pixels of it. Reminds me of a problem I've had in the past with a totally different font, and without doublewidth. Once upon a time I used Lucida (Lucida Console on Windows, Lucida Typewriter on Linux: I still used both platforms then); then I noticed that in bold Cyrillic I had the problem described: sweeping the cursor over the text made it look wrong when swept in one direction, right when swept in the opposite direction. On closer look, the bold Cyrillic glyphs of the Lucida font were apparently constructed by superimposing the unbold glyphs with a copy of themselves shifted laterally by one pixel, and thus the bold glyphs were one pixel wider than the normal-weight glyphs (and than the declared glyph-width of the font), which gvim "didn't like". So I found a different font (Bitstream Vera Sans Mono) which doesn't have this problem, and can AFAICT display Latin and Cyrillic with or without bold or italic (or, of course, underlined) with no problem. Dr. Chip, maybe you can find a different font, which has the glyph but not the problem? It may require some trial and error. I've been through all the fonts that have "mono" in their names on my system; each of them has the same problem that Luxi Mono has. Most of the rest look like they use double-spacing: i e . t h e y r e s e m b l e t h i s; although that does mean that the R shows up completely. I'll probably just make do with having that R look like an F most of the time. Thanks! Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
odd character drawing problem
Hello: The following line, when in a buffer that vim is displaying: m=⎣ℜ(b-a)⎦=1~1026 has the "script R" displayed correctly when the cursor is swept over it from right to left, but the "script R" is displayed incorrectly when the cursor is swept over it from left to right. I'm using: Scientific Linux 6.5 (Carbon) vim 7.4.372 set guifont=Monospace\ Bold\ 12 configure --with-features=huge --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-cscope 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: latex spell check disabled if set filetype=latex
Enno wrote:
Le mardi 24 juin 2014 19:16:44 UTC+2, DrChip a écrit :
Enno wrote:
Le vendredi 13 juin 2014 18:53:06 UTC+2, Charles Campbell a écrit :
Enno wrote:
Ok, I understand that spell checking is only activated after a
keyword, such as the \section{..} command. But why is it that
\begin{document} does not belong to these keywords? This disables
spell checking for example for letter document classes without any
sectioning. How to remedy this least intrusively?
Spell checking is activated for syntax regions. Most of the preamble
should not be spell checked. Spell checking *is* enabled for
\begin{document}..\end{document} (that's called a texDocZone by the
syntax highlighting), and it does work for the letter document classes
without sectioning.
Regards,
Chip Campbell
Hello,
there is c:\Program Files\Vim\vim74\syntax\tex.vim that says
" Maintainer: Charles E. Campbell
" Last Change: Mar 20, 2014
" Version: 81
" URL: http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX
However, in the test file
\documentclass{article}
\begin{document}
\end{document}
the spell checking errors are only detected in the comments between
\begin{document} and \end{document}, but not in the text itself.
This changes however, if a \section{...} command is added, for example.
Just tried it:
\documentclass{article}
\begin{document}
This is junkk . Loks like spell checkingx is woiking to mee!
% This is junkk . Loks like spell checkingx is woiking to mee!
\end{document}
Both the text and the comment were spell checked.
I used:
vim -u vimrc.spellchk abc.tex
and both files are attached. I also used syntax/tex.vim v81, which you
may get from my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX .
Regards,
Chip Campbell
Hello Dr Chip,
Thanks a lot for your patience that I am sorry to have abused: It turned out
that it was a Rainbow Parentheses plugin
(https://github.com/luochen1990/rainbow) that disabled the spell check between
\begin... and \end{document} but left it active otherwise.
Perhaps you ought to try my Rainbow highlighter:
http://www.drchip.org/astronaut/vim/index.html#RAINBOW .
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: latex spell check disabled if set filetype=latex
Enno wrote:
Ok, I understand that spell checking is only activated after a
keyword, such as the \section{..} command. But why is it that
\begin{document} does not belong to these keywords? This disables
spell checking for example for letter document classes without any
sectioning. How to remedy this least intrusively?
Spell checking is activated for syntax regions. Most of the preamble
should not be spell checked. Spell checking *is* enabled for
\begin{document}..\end{document} (that's called a texDocZone by the
syntax highlighting), and it does work for the letter document classes
without sectioning.
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 230 in vim: "Vim: Caught deadly signal SEGV"
Christian Brabandt wrote:
diff --git a/src/window.c b/src/window.c
--- a/src/window.c
+++ b/src/window.c
@@ -5650,7 +5650,10 @@ win_new_height(wp, height)
if (wp->w_height > 0)
{
if (wp == curwin)
- validate_cursor(); /* w_wrow needs to be valid */
+ /* w_wrow needs to be valid, might call win_new_height recursively... */
+ validate_cursor();
+ if (wp->w_height != prev_height)
+ return; /* recursive call already changed window size */
if (wp->w_wrow != wp->w_prev_fraction_row)
set_fraction(wp);
}
Hello, Christian:
Nice! It fixes the problem that I saw; when I bring up gvim with the
OP's .vimrc it now shows the status line and does not eventually crash
due to jkLG motions.
Regards,
Chip
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: "Vim: Caught deadly signal SEGV"
Charles E Campbell wrote: Bram Moolenaar wrote: Charles Campbell wrote: Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: "Vim: Caught deadly signal SEGV" http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where "junk.vim" has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim "separates" from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Hmm, apparently I was using an oddball version of vim that wasn't completely patched. So I've now rebuilt vim 7.4.320; using valgrind --log-file=gvim.out gvim -u junk.vim -U NONE macos The attached file contains the log. Vim crashed eventually, but it took a lot of j and k motions, sprinkled with the occasional L and G to get it. Would one of you tell me how best to apply gdb to gvim? I suppose I could run gvim and then attach gdb to it after its started. You have to run the GUI in the foreground. In gdb use "run -f". Looks like somehow the data structures allocated for the screen don't match with the screen size. That's weird. It probably matters what the terminal size is you start with. Was that 24 x 80? The terminal I used to kick off gvim was 253x37. I'm using vim 7.4.320 on a Scientific Linux 6.5 system. My configure command is: ./configure --with-features=huge --enable-gui=gtk2--enable-perlinterp --enable-pythoninterp --enable-cscope I tried this operation again with different initial terminal sizes. * terminal: 125x37 -- I get no status line and eventually I get a SIGSEGV * terminal: 50 x 20 -- I get a status line and haven't seen a SIGSEGV * I restored the terminal to 125x37, but this time I used the mouse to grab the corner and expand the gvim screen. I pull it down just one line and the status line appears, and I haven't been able to get it to core dump based on cursor movement. Regards, Chip -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Issue 230 in vim: "Vim: Caught deadly signal SEGV"
Charles Campbell wrote: v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: "Vim: Caught deadly signal SEGV" http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where "junk.vim" has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim "separates" from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches now... Chip OK, I attached to the gvim, moved the cursor about a bit, and got... (some of my comments are interlaced) Program received signal SIGSEGV, Segmentation fault. 0x0058a2c1 in char_needs_redraw (off_from=2241, off_to=5439488, cols=14) at screen.c:5487 5487&& ((ScreenLines[off_from] != ScreenLines[off_to] - That off_to looks suspicious, as there are only 4245 characters in the file I'm using... - (gdb) up #1 0x0058a699 in screen_line (row=26, coloff=0, endcol=14, clear_width=83, rlflag=0) at screen.c:5605 5605redraw_next = char_needs_redraw(off_from, off_to, endcol - col); - Its 27 rows by 83 columns; nothing obvious yet. I note that screen_line() computes off_to with off_to = LineOffset[row] + coloff; - (gdb) p row $8 = 26 (gdb) p LineOffset[row] $9 = 5439488 (gdb) p coloff $10 = 0 - Looks like LineOffset[] has a problem. I don't see where LineOffset is set up - (gdb) p LineOffset $11 = (unsigned int *) 0xf435e0 - Looks like a reasonable pointer. - (gdb) p LineOffset[0] $13 = 747 (gdb) p LineOffset[1] $14 = 830 (gdb) p LineOffset[2] $15 = 913 (gdb) p LineOffset[3] $16 = 996 (gdb) p LineOffset[row-1] $17 = 0 (gdb) p LineOffset[row-2] I'm going to pass on figuring out what LineOffset is all about. I've attached the file I've been using for testing. 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. Runtime Environments Mac OS X has two primary runtime environments: one based on the dynamic link editor, dyld, and the other based on Code Fragment Manager (CFM). OS X does not support ELF, and there's no dlopen, although the dlcompat library provides a limited compatibility layer (using native OS X functions) so that common Unix source can be compiled easily. CFM determines addresses for referenced symbols in executables at build time (a static approach). The executable format used is called PEF (Preferred Executable Format). dyld resolves undefined symbols at execution time. The executable format is Mach-O (Mach object-file-format). Mac OS X is natively a dyld/Mach-O platform - all system frameworks are built using dyld. In fact, the CFM/PEF environment is itself built on top of dyld/Mach-O. However, there exist provisions to call dyld code from CFM code. Moreover, if you wish to debug or trace a CFM application using GDB, you would need to use a Mach-O program called LaunchCFMApp: /System/Library/Frameworks/Carbon.framework/Versions/\ A/Support/LaunchCFMApp dyld/Mach-O is similar in many respects to ld.so/ELF, although they differ both conventionally and fundamentally. Some of these are: * Dynamic shared libraries on Mac OS X have the .dylib extension. The functionality of several traditional libraries (such as libc, libdl, libinfo, libkvm, libm, libpthread, librpcsvc, etc.) is provided by a single dynamically loadabl
Re: Issue 230 in vim: "Vim: Caught deadly signal SEGV"
v...@googlecode.com wrote: Comment #4 on issue 230 by brammool...@gmail.com: "Vim: Caught deadly signal SEGV" http://code.google.com/p/vim/issues/detail?id=230 The errors in the libfontconfig.so look like a library problem: reading 4 bytes where there are only 2. Because of alignment this probably does not cause a crash. The error below update_screen() is most likely what causes the crash. Can't see what happens there from this info though. I tried this problem out: gvim -u junk.vim -U NONE macos (where "junk.vim" has the two lines the poster mentioned) * used binary compiled from an older machine: gvim -u junk.vim -U NONE macos - got a crash and no status line - gdb doesn't track gvim after gvim "separates" from the console (ie. becomes its own process) - binary wasn't compiled for debugging and was stripped * recompiled vim for debugging and no stripping - no crash, has status line - valgrind reported no problems I'm going to go and update with the new patches 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. For more options, visit https://groups.google.com/d/optout.
Re: vimString breaks the syntax (syntax/vim.vim)
itchyny wrote: let m = 5 let y = 20 * (m / 4) + m / 4 let z = 10 for i in range(10) echo i endfor while i let i -= 1 endwhile Please try v7.4-30 which you can get from my website: http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM . Thank you for the report, 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] sh.vim 134 bash syntax: ${var/#from/to} not recognized anymore
G.raud wrote:
This bug is found in sh.vim Version 134 ASTRO-ONLY but _not_ in Version
132 ASTRO-ONLY (and _not_ in VIM 7.4.273 either):
$ cat >test.sh <<"EOF"
#!/bin/bash
${var/#from/to} # the hash char # inside the param expansion starts a comment
# Note: /#from/to is a string replacement anchored at the start
myfunc () {
:
} # seen as the end of the param expansion
myfunc () {
: # this function's name is highlighted
}
EOF
$ vim -u NONE -c ':syntax on' test.sh
Regards
Hello!
Please try the attached syntax file.
Thank you for your report!
Regards,
Chip Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
sh.vim
Description: application/octetstream
Re: sh.vim: Fix detection of bash shSubSh(ells) instead of using shCmdParenRegion, and allow functions in shSubSh
Charles Campbell wrote:
Dan Sanduleac wrote:
Hi,
I've noticed that syntax highlighting inside bash subshells is
lacking (comments are not rendered as such, for instance). Turns out
that was because the subshells were parsed as `shCmdParenRegion`
which is for stuff like `cat <<<(one-line command)`. Instead
subshells should be parsed as `shSubSh`.
I've also allowed function definitions to be contained in a shSubSh.
Example to demonstrate:
myfunction() {
# This subshell is mistakenly parsed as shCmdParenRegion
(
# comments don't render
# and this function definition isn't parsed as such
foo() { true; }
)
# This was and should still be a shCmdParenRegion
cat <<<(echo yes)
}
Hello!
Thank you for the patch and example. The "foo() { true; }" was still
not highlighting properly as a function; so I made some additional
changes. Please try the attached syntax file.
Regards,
Chip Campbell
Sorry about that, everyone -- I apologize for sending that attachment to
the entire list. Please, all: send your patches to the file's
maintainer, not to the list.
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: sh.vim: Fix detection of bash shSubSh(ells) instead of using shCmdParenRegion, and allow functions in shSubSh
Dan Sanduleac wrote:
Hi,
I've noticed that syntax highlighting inside bash subshells is lacking (comments are not
rendered as such, for instance). Turns out that was because the subshells were parsed as
`shCmdParenRegion` which is for stuff like `cat <<<(one-line command)`. Instead
subshells should be parsed as `shSubSh`.
I've also allowed function definitions to be contained in a shSubSh.
Example to demonstrate:
myfunction() {
# This subshell is mistakenly parsed as shCmdParenRegion
(
# comments don't render
# and this function definition isn't parsed as such
foo() { true; }
)
# This was and should still be a shCmdParenRegion
cat <<<(echo yes)
}
Hello!
Thank you for the patch and example. The "foo() { true; }" was still
not highlighting properly as a function; so I made some additional
changes. Please try the attached syntax file.
Regards,
Chip Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
sh.vim
Description: application/octetstream
Re: delete just left netrw buffer after opening file
Enno wrote: Le vendredi 23 mai 2014 10:42:55 UTC+2, Enno a écrit : Can one configure netrw so that when opening a file in netrw the just left netrw buffer is automatically deleted? For example type :e ., navigate to a file, hit . Then there is the netrw buffer, created by :e . that we just left, and has done its service. Is there an autocmd to delete it? Naive attempts under Gvim 7.4.282 and Windows 7 64 bit failed. This is, under netrw 1.53b. Another curiosity is that, inside a netrw buffer, the :bprevious is without effect, but :bnext works as expected. Hello, Enno: I'm not seeing any problem with :bp or :bn using netrw. I used both wide and tree listing styles, as I'm guessing that you typically use tree style, with netrw v149 and v153c. Please: * give a list of all netrw options you're using * try it with netrw v153c (http://www.drchip.org/astronaut/vim/index.html#NETRW) * give a sequence of commands that elicit the misbehavior Merci, 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: delete just left netrw buffer after opening file
Enno wrote: Can one configure netrw so that when opening a file in netrw the just left netrw buffer is automatically deleted? For example type :e ., navigate to a file, hit . Then there is the netrw buffer, created by :e . that we just left, and has done its service. Is there an autocmd to delete it? Naive attempts under Gvim 7.4.282 and Windows 7 64 bit failed. That's the default behavior. 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 219 in vim: Noticed 2 issues with netrw v151
v...@googlecode.com wrote: Comment #1 on issue 219 by denis.ka...@gmail.com: Noticed 2 issues with netrw v151 http://code.google.com/p/vim/issues/detail?id=219 I just encountered this myself. s:NetrwSafeOptions() seems like it's for strictly internal use and the comment in front of it mentions functions for saving and restoring user settings (though it erroneously calls the saving function NetrwSaveOptions() while the right name seems to be NetrwOptionSave()). The line that sets bt=nofile inside it was added in 657ade71d395, but that is also the changeset that commented out the line that saves bt inside s:NetrwOptionSave(). Also, line 87 (of runtime/autoload/netrw.vim) also sets bt=nofile, but this seems superfluous since s:NetrwSafeOptions() is called on the preceding line. Can anyone comment on this? See if http://www.drchip.org/astronaut/vim/index.html#NETRW fixes the issue. If not, please tell me exactly how to duplicate the problem. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: latex spell check disabled if set filetype=latex
Enno wrote: This inconsistency is also discussed in the comments of the thread opener on http://tex.stackexchange.com/questions/135337/how-to-set-up-spell-checking-with-vim If set filetype=plaintex, then spell checking in a tex file checks the text in the whole document for spelling errors. (This is, spelling errors are have a curly red underline.) If set filetype=latex, then spell checking in a tex file only checks the spelling in comments or erratically in some latex environments. This occurs in Gvim 7.4.285 and Windows 7 64 bit. The problem: avoid spell checking things that should not be spell checked. The preamble, for example, largely falls into this category. Math regions falls into this category. Etc. The solution: restrict spell checking to specific things, such as sections (actually, document, chapter, part, section, subsection, subsubsection, and others) User problem: has introduced new commands that are not recognized by syntax/tex.vim as things that should involve spell checking, and has not thought of writing after/syntax/tex/... to recognize spell checking in his/her new zones. Solution: user should write syntax recognition rules to enable spell checking in the region(s) of interest. 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 151 in vim: file management (copy/move) is broken on windows (netrw)
Enno wrote: Le jeudi 3 avril 2014 18:57:12 UTC+2, Enno a écrit : Le mardi 12 novembre 2013 20:22:59 UTC+1, v...@googlecode.com a écrit : Updates: Status: Accepted Owner: drc...@campbellfamily.biz Comment #1 on issue 151 by drc...@campbellfamily.biz: file management (copy/move) is broken on windows (netrw) http://code.google.com/p/vim/issues/detail?id=151 You need to find commands on your system that will copy and move files. cmd /c copy -and- cmd /c move worked under windows xp. Just set g:netrw_localcopycmd and g:netrw_localmovecmd to whatever works for you. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings I think more foolproof would be to use the COMSPEC environment variable. Something like this: s:cmd=$COMSPEC." /c " let g:netrw_localcopycmd=s:cmd."copy" let g:netrw_localmovecmd=s:cmd."move" let g:netrw_localmkdir=s:cmd."mkdir" let g:netrw_localmkdir=s:cmd."rmdir" Strangely, now it says, when trying to copy, **error** (netrw) g:netrw_localcopycmd not executable on your system, aborting Please try v152 of netrw; its using the COMSPEC environment variable (http://www.drchip.org/astronaut/vim/index.html#NETRW). The reason why you got the message you got is that netrw found that trying to execute "C:\Windows\system32\cmd.exe /c" failed, as I'd expect it would. That's all one command, by the way, with a ".exe" embedded internally. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [bug] sh.vim 134 syntax: backslash in sq string interpreted ('\' not recognized as a single backslash)
G.raud wrote: This bug is found in sh.vim Version 134 ASTRO-ONLY but _not_ in Version 132 ASTRO-ONLY (and _not_ in VIM 7.4.273 either). $ cat >test.sh <<"EOF" #!/bin/sh printf "%s" '\' starts a single quoted 'string' EOF $ vim -u NONE -c ':syntax on' test.sh Regards Hello! Just wanted to let you know that I've gotten your report -- I'm busy this week (finals) and so I won't be able to address this issue yet. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: VIM 7.4.244 Fails to Compile on Red Hat Enterprise Linux Server release 5.9 (Tikanga)
Bram Moolenaar wrote: Ed Brown wrote: I'm not an autotools expert by any stretch of the imagination. I've not included a patch. But here are the details: undefining HAVE_SMACK in config.h does fix the issue. ./configure --prefix=/usr/local --enable-perlinterp --enable-tclinterp --enable-pythoninterp --with-python-config-dir=/usr/local/lib/python2.7/config --with-features=huge gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -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/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/os_unix.o os_unix.c os_unix.c: In function ‘mch_copy_sec’: os_unix.c:2820: error: ‘XATTR_NAME_SMACK’ undeclared (first use in this function) os_unix.c:2820: error: (Each undeclared identifier is reported only once os_unix.c:2820: error: for each function it appears in.) os_unix.c:2821: error: ‘XATTR_NAME_SMACKEXEC’ undeclared (first use in this function) os_unix.c:2822: error: ‘XATTR_NAME_SMACKMMAP’ undeclared (first use in this function) make[1]: *** [objects/os_unix.o] Error 1 make[1]: Leaving directory `/users/wcadmin/eb15792/vim-7.4.244/src' make: *** [first] Error 2 Configure checks for the linux/xattr.h file to exist. Does yours not contain XATTR_NAME_SMACK, XATTR_NAME_SMACKEXEC and XATTR_NAME_SMACKMMAP? What does it define then? Or what other include file defines them? Scientific Linux 6.4 has three xattr.h entries: /usr/include/linux/xattr.h /usr/include/attr/xattr.h /usr/include/sys/xattr.h However, no file under /usr/include has the word "SMACK" in 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.
SL6.4: can't compile os_unix.c due to patch#238
Hello: I'm getting some compiler errors with Scientific Linux 6.4: os_unix.c|2879 error| 'XATTR_NAME_SMACK' undeclared (first use in this function) os_unix.c|2879 error| (Each undeclared identifier is reported only once os_unix.c|2879 error| for each function it appears in.) os_unix.c|2880 error| 'XATTR_NAME_SMACKEXEC' undeclared (first use in this function) os_unix.c|2881 error| 'XATTR_NAME_SMACKMMAP' undeclared (first use in this function) This is configured with: ./configure --with-features=huge --enable-gui=yes --enable-gui=gtk2 --enable-perlinterp --enable-pythoninterp --enable-rubyinterp 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] syntax highlighting for uniq()
LCD 47 wrote:
As the subject says, the new uniq() function should be highlighted.
/lcd
diff -r d96e8fbc3747 runtime/syntax/vim.vim
--- a/runtime/syntax/vim.vimTue Mar 25 18:24:23 2014 +0100
+++ b/runtime/syntax/vim.vimWed Mar 26 17:03:08 2014 +0200
@@ -73,7 +73,7 @@
syn case match
" Function Names {{{2
-syn keyword vimFuncName contained abs and argidx atan browsedir bufloaded
bufwinnr byteidxcomp changenr clearmatches complete_add copy count deepcopy
diff_filler escape executable expand feedkeys filter float2nr fnameescape
foldclosedend foldtextresult garbagecollect getbufvar getcmdline getcwd
getfsize getline getpid getreg gettabwinvar getwinvar has hasmapto histget hlID
indent inputdialog inputsave invert items len line localtime luaeval mapcheck
matcharg matchlist min mzeval or prevnonblank py3eval readfile remote_expr
remote_read rename reverse screenchar search searchpairpos serverlist setcmdpos
setloclist setpos setreg settabwinvar sha256 shiftwidth sin sort spellbadword
split str2float strchars strftime string strpart strtrans submatch synconcealed
synIDattr synstack tabpagebuflist tabpagewinnr taglist tanh tolower tr type
undotree virtcol wildmenumode wincol winline winrestcmd winsaveview writefile
+syn keyword vimFuncName contained abs and argidx atan browsedir bufloaded
bufwinnr byteidxcomp changenr clearmatches complete_add copy count deepcopy
diff_filler escape executable expand feedkeys filter float2nr fnameescape
foldclosedend foldtextresult garbagecollect getbufvar getcmdline getcwd
getfsize getline getpid getreg gettabwinvar getwinvar has hasmapto histget hlID
indent inputdialog inputsave invert items len line localtime luaeval mapcheck
matcharg matchlist min mzeval or prevnonblank py3eval readfile remote_expr
remote_read rename reverse screenchar search searchpairpos serverlist setcmdpos
setloclist setpos setreg settabwinvar sha256 shiftwidth sin sort spellbadword
split str2float strchars strftime string strpart strtrans submatch synconcealed
synIDattr synstack tabpagebuflist tabpagewinnr taglist tanh tolower tr type
undotree uniq virtcol wildmenumode wincol winline winrestcmd winsaveview
writefile
syn keyword vimFuncName contained acos append argv atan2 bufexists
bufname byte2line call char2nr col complete_check cos cscope_connection delete
diff_hlID eval exists expr8 filereadable finddir floor fnamemodify foldlevel
foreground get getchar getcmdpos getfontname getftime getloclist getpos
getregtype getwinposx glob has_key histadd histnr hostname index inputlist
inputsecret isdirectory join libcall line2byte log map match matchdelete
matchstr mkdir nextnonblank pathshorten printf pyeval reltime remote_foreground
remote_send repeat round screencol searchdecl searchpos setbufvar setline
setmatches setqflist settabvar setwinvar shellescape simplify sinh soundfold
spellsuggest sqrt str2nr strdisplaywidth stridx strlen strridx strwidth
substitute synID synIDtrans system tabpagenr tagfiles tan tempname toupper
trunc undofile values visualmode winbufnr winheight winnr winrestview winwidth
xor
syn keyword vimFuncName contained add argc asin browse buflisted bufnr
byteidx ceil cindent complete confirm cosh cursor did_filetype empty
eventhandler exp extend filewritable findfile fmod foldclosed foldtext function
getbufline getcharmod getcmdtype getfperm getftype getmatches getqflist
gettabvar getwinposy globpath haslocaldir histdel hlexists iconv input
inputrestore insert islocked keys libcallnr lispindent log10 maparg matchadd
matchend max mode nr2char pow pumvisible range reltimestr remote_peek remove
resolve screenattr screenrow searchpair server2client
A patch isn't quite the right way to do this, as that patch modifies
script generated automatically (look about three lines down from where
you edited syntax/vim.vim). I have another mod to make and will collect
them before I submit something to Bram.
Thanks,
C Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] add sortuniq() function
Bram Moolenaar wrote: I'm thinking of a kind of manifest that specifies these dependencies. When we standardize that it's still possible to use a choice of plugin managers. FWIW, GLVS (getscript) supports plugin dependencies. A number of my plugins have lines such as " GetLatestVimScripts: 1066 1 cecutil.vim in scripts other than cecutil which tell getscript that the current script also depends upon cecutil.vim. So is it better for the plugin writer to explicitly state such dependencies as getscript promotes, or is it better to have a centralized manifest with them. How will that manifest be maintained, updated, etc? Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [bug] sh syntax hl: several issues inside "subshell" code
G.raud wrote: To reproduce: $ cat >test.sh < Hello: I haven't fixed this yet, but I wanted to let you know that its on my todo list. 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] sh syntax hl: only 1st \" escaped if dq string to eval with assignement inside constructs
G.raud wrote: if true then eval $varname="\"\"" # comment highlighted as a string fi Hello! I haven't fixed this yet, but I wanted to let you know its on my todo list. Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Need support for opening files via HTTPS
Bohr Shaw wrote: ehttps://raw.github.com/tpope/vim-sensible/master/plugin/sensible.vim Hello! Please try netrw v151n, available from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW . For the "optional url redirecting"; you may disable netrw by putting let g:loaded_netrwPlugin= 0 into your .vimrc. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Patch 7.4.208
Bram Moolenaar wrote: Patch 7.4.208 Problem:Mercurial picks up some files that are not distributed. Solution: Add patterns to the ignore list. (Cade Forester) Files: .hgignore I suspect that this patch really shouldn't be in the patch list; there is no .hgignore file in the 7.4 source. The result was that patch asked for a "File to patch" (and there wasn't a file to be patched). 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: Error when opening file over ftp
Tony Mechelynck wrote: abo sv ftp://ftp.vim.org/pub/vim/patches/7.4/README Hello, Tony: My [Sent] folder isn't showing anything, but the message is marked as replied to. So, anyway, at the risk of repeating myself: I didn't notice any problem with netrw v151k with this (or with "view", btw). You may get it from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Test
celel...@gmail.com wrote: Looks like my previous message never arrived. Does google feel my hate through my keyboard? If this message is actually sent, sorry for annoyance. ^^ If this is your first time posting, your first message must be approved by a human. This process is in place to avoid spamming (and yes, there's a history involved). Consequently, there is likely to be a delay before a pair of eyes verifies that its not spam. Spammers' messages are blocked and their access dropped. Regards, and welcome to the list, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Error messages opening a .txt.gz file from netrw (didn't try opening locally).
Tony Mechelynck wrote: Using gvim 7.4.141 (Huge) for GTK2/GNOME2, changeset 2ca470c6096e g:loaded_netrw == g:loaded_netrwPlugin == 'v149' $VIMRUNTIME/plugin/gzip.vim dated 2010 Mar 10 While viewing ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-central-trunk-linux64/1389382240/ hit with the cursor on comm-central-trunk-linux64-bm01-universal-build1210.txt.gz (the only file in that directory) (or similarly in other non-softlink recent subfolders of the same parent) Error detected while processing function gzip#read: line 39: E19: Mark has invalid line number line 44: Error: Could not read uncompressed file press ENTER or type command to continue After dismissing the |hit-enter-prompt|, the file is then (AFAICT) correctly opened. (It is the log of a failed build of SeaMonkey, and I was looking for the reason of the failure, which is: wrong Python version, as seen at lines 1006 sqq.) Hello, Tony: I found the problem. The E19 was being issued by code in gzip.vim, which was misleading (I'd like to use "red herring", but I'm not sure all the readers will get that colloquialism). It was a problem with netrw, which I've now fixed in v151i. As usual, you may get a copy of netrw v151i from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW . Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Error when opening file over ftp
Tony Mechelynck wrote: The command abo sv ftp://ftp.vim.org/pub/vim/patches/7.4/README (in a script, at a point where another buffer is displayed in a window), or even :view (at the Vim command-line, when looking at that README file, to see if it has been modified), both give me **error** (netrw) ?Invalid command. in red (possibly Error or ErrorMsg highlight) followed on the next line by the normal "/tmp/vHg0s9d/3" [readonly] 231L, 14146C (or similar) in Normal highlight. The file is read into the window as if no eror had happened AFAICT. I'll try to give a little more debugging info than my usual. I don't know when it started happening but no later than 7.4.199. It still happens (as seen below) in 7.4.205. The above is from gvim (i.e. with GUI running), I've also tried to invoke "view ftp://ftp.vim.org/pub/vim/patches/7.4/README"; (without the quotes) in bash in both a konsole terminal and the no-X11 Linux console, and I get the same message. Hello, Tony: I didn't see any problem using your command above with v151h, which I've just put on my website (http://www.drchip.org/astronaut/vim/index.html#NETRW). If the problem persists, would you please send me the output of fgrep netrw .vimrc (that way I can get an easy-to-use set of netrw variables that you set). Also, please see :help netrw-debug . Thank you for your report! Chip Campbell P.S. I'm still looking at the problem you reported with netrw and gzip. I suspect its a problem with gzip.vim; more specifically, that netrw and gzip both use temporary files. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and 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: RFE: :noswapfile prefix
Tony Mechelynck wrote: RFE: I propose a :noswapfile (or something) prefix, working in similar fashion to the :verbose, :vertical, :top, :tab, etc. prefixes in front of another ex-command, and with the meaning: If that _subordinate_ ex-command opens a new buffer, we want 'noswapfile' set on that buffer. (If it doesn't, nothing happens, as with e.g. :vert :top or :tab when the subordinate command opens no new window.) Or maybe :0swapfile and :1swapfile prefixes. Rationale: Currently, “:setlocal noswapfile” prior to opening a new buffer would close the swapfile on the current buffer, not the new one; while doing it afterwards opens and closes a swapfile for the new buffer, which is less harmful but still not ideal. In particular, I notice that “directory” windows handled by netrw have swapfiles set on them: IMHO this is wasteful (and after a few crashes you may find yourself with a string of .swp, .swo, .swn, .swm, etc., for something which cannot ever need a recovery). Netrw saves selected user options, sets them to "safe" values for netrw to build its buffer, and then restores the user's options. That way when netrw is used to open a new file, the user's options are in effect. 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: Incorrect expansion of %?
Ingo Karkat wrote:
On 11-Mar-2014 15:14 +0100, Ben Fritz wrote:
Isn't this situation what shellescape() is designed for?
That's not saying shellescape() will work, but I think it's supposed
to work, unlike using a bare % which should always work for internal
Vim commands but will only work by accident in external commands.
No, shellescape() would be used in a mapping / command, like this:
shellescape(expand('%'), 1). With the 1 flag (for use with :!), a
literal % is properly escaped to \% so that Vim's special handling does
not apply.
% is handy for interactive use, like :!perl %
shellescape() is for use in a shell command argument being passed to the
shell. The documentation even shows an example of using a filter.
fnameescape() is for internal-vim use involving filenames (ie. avoid
having % have magic with exe when you don't want it to).
% is replaced with the current file name, just as it is typed. (see :he
_%).
So, if the current filename contains spaces, that's what you can expect
to see with the expansion.
The right way to do what the OP wants:
:exe "w !diff ".shellescape(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: [PATCH] yacc syntax highlighting correction: allowing comments in yaccRulesCluster
Yuri Vic wrote: Attached patch fixes the problem when vim fails to highlight comments between rules in yacc source. Thanks! I've included it on my website: http://www.drchip.org/astronaut/vim/index.html#SYNTAX_YACC 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] VIM 7.4 sh syntax hl: in string "x#x\$#x" second hash treated as a comment start
G.raud wrote: #!/bin/sh ls "#\$#" Thank you for the feedback; please try syntax/sh.vim v132, available from my website: http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: vim doesn't open some directories
Yuri wrote: On 02/26/2014 08:53, Charles E Campbell wrote: I suggest that you try things out with the latest netrw, which you can get from my website: Yes, this fixed the problem. Since you are the maintainer, I would like to ask if it is possible to not change directory to the folder that is opened with ":new mydir/"? Currently, it changes the current directory to mydir/ once some file from there is opened. I don't this this is generally a desired behavior. Opening a file is what users usually want. Yuri Hello! With g:netrw_keepdir= 0, :new somedir/ (where somedir previously existed) started up a netrw browsing window with .../somedir as the current directory. This behavior is correct. With g:netrw_keepdir= 1, :new somedir/ (where somedir previously existed) started up a netrw browsing window without having changed the currrent directory. This behavior is correct. When somedir did not previously exist, :new somedir/ did not create a new directory. Opening some file from that directory did not affect the current directory (leaving it as .../somedir when g:netrw_keepdir=0 and ... when g:netrw_keepdir=1). I'm not sure what you're asking for here; please elucidate! Thank you, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: what happened to luxi mono?
Hello!
I thought I'd share the "solution" to "what happened to luxi mono?",
just in case anyone else was being afflicted in a similar fashion:
* symptom: the font I prefer to use, Luxi Mono Bold 11, was no longer
available (I use a lot of math-oriented utf-8 characters, which Luxi
Mono supports well)
* Turns out that I wasn't getting gnome-gtk2 anymore during new
compiles; instead, I was getting motif, hence no luxi mono
* I get "automatic updates" on my system (Scientific Linux 6.4) (not
that I want them, its just the way It Has To Be on my government computer)
* fallback solution: I compiled vim on my home computer (SL6.3) and
brought the executable to work (via ftp, since we're not to use
flashsticks anymore)
* new symptom, just happened a day or two ago: I was not getting any vim
menus.
* tried a backup version of vim (also compiled on my home computer) from
a month ago -- it too exhibited the "no vim menu" issue. That vim
certainly didn't used to have that problem...
* all versions of vim tried had +menu and has("gui_running") was true
* got suspicious that auto-updating was involved, so I recompiled vim on
my work computer, which I haven't bothered to do for many months. It
successfully compiled with gtk and had menus!
So, thanks goes to whomever fixed the gtk system on SL6.4.
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/groups/opt_out.
Re: Error messages opening a .txt.gz file from netrw (didn't try opening locally).
Tony Mechelynck wrote: Using gvim 7.4.141 (Huge) for GTK2/GNOME2, changeset 2ca470c6096e g:loaded_netrw == g:loaded_netrwPlugin == 'v149' $VIMRUNTIME/plugin/gzip.vim dated 2010 Mar 10 While viewing ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-central-trunk-linux64/1389382240/ hit with the cursor on comm-central-trunk-linux64-bm01-universal-build1210.txt.gz (the only file in that directory) (or similarly in other non-softlink recent subfolders of the same parent) Error detected while processing function gzip#read: line 39: E19: Mark has invalid line number line 44: Error: Could not read uncompressed file press ENTER or type command to continue After dismissing the |hit-enter-prompt|, the file is then (AFAICT) correctly opened. (It is the log of a failed build of SeaMonkey, and I was looking for the reason of the failure, which is: wrong Python version, as seen at lines 1006 sqq.) Hello, Tony: I haven't found the source of the problem yet. As you know, I wrote netrw -- and Bram M. wrote gzip.vim. Netrw uses tempname() to hold the remote file locally in a /tmp directory. gzip.vim also uses tempname() to hold a copy of the compressed file and the decompressed file. tempname() returns the same directory (different file names) each time. I can quiet the first message by changing gzip.vim#85: execute "silent '[,']w " . tmpe_esc to execute "silent! '[,']w " . tmpe_esc Using DechoRemOn and Decho, tmpe_esc is good and the resutling file is readable. The very next line was a if !filereadable(tmp) test; it fails causing error message#2. In my test, netrw created 5.gz, gzip.vim created 10.gz, and then complained. I'm not sure what to do at the moment, but I wanted you to know that at least I saw your message. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [patch] vim does not open local directory
Cade Foster wrote: Problem: vim does not open local directory. Steps to reproduce: 1. run $ vim /etc/ Expected results: use netrw plug-in to list directory content. Actual results: 1. show error message "/etc/" Illegal file name 2. buffer remains empty. Hello! Please try netrw v150n -- I believe it fixes this problem. You can get it from: http://www.drchip.org/astronaut/vim/index.html#NETRW Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Crash while deleting directory
Lech Lorens wrote:
On 30-Dec-2013 Charles Campbell wrote:
Hello!
I'm using vim 7.4.131 (Huge version with GTK2-GNOME GUI), and
haven't used Dominque's patch. When trying your problem out, netrw
went up a directory, even though foo no longer existed; both
going-up-directory techniques worked ( on "..", and using
"-").
I then tried using
vim -u simple.vimrc
where contained the following two lines, only:
set nocp
filetype plugin on
Again, no problems. I don't think I can fix this problem thus far.
Do you have any netrw-associated settings that you could share?
Regards,
C Campbell
In the original post the following steps were mentioned:
1. cd /tmp && mkdir foo
2. vim
3. :e foo/
4. rmdir foo && touch foo
5. In Netrw choose .. to go up to /tmp
6. Open foo
Surprising as it may be, to experience problems with editing foo it is
essential to resist the temptation to stop after step 5 but go on end
try editing foo.
Hello!
OK, I see the problem. The solution:
:exe "bw ".bufnr("foo")
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/groups/opt_out.
Re: [patch] vim does not open local directory
Gary Johnson wrote: On 2013-12-30, Charles Campbell wrote: Cade Foster wrote: Problem: vim does not open local directory. Steps to reproduce: 1. run $ vim /etc/ Expected results: use netrw plug-in to list directory content. Actual results: 1. show error message "/etc/" Illegal file name 2. buffer remains empty. I'm unable to duplicate your problem. I'm able to duplicate this problem very easily using Vim 7.4.41 and netrw v149 on an Ubuntu 10.04 system. For example: $ cd /usr $ vim -N -u NORC share # Succeeds $ vim -N -u NORC /usr/share # Succeeds $ cd $ vim -N -u NORC /usr/share # Fails $ cd /tmp $ vim -N -u NORC /usr/share # Fails In short, it seems to open a relative path to a directory fine, and the absolute path to a directory when the current directory is in that path fine, but it does not open a directory given by its absolute path when the current directory is not in that path. I repeated my experiments using an older Vim installation, Vim 7.2.330 and netrw v136, and it always worked, so something appears to have broken between then and 7.4.41/v149. Please run the internal debugger (:he netrw-debug) and send me a trace. I will try to get that later today. I'll take a look when you get the trace. That entire sequence of commands worked for me. However, I'm using netrw v150n (its almost the same as v150m; it simply has an extra problem detection with a warning that should not affect this). Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [patch] vim does not open local directory
Cade Foster wrote: Problem: vim does not open local directory. Steps to reproduce: 1. run $ vim /etc/ Expected results: use netrw plug-in to list directory content. Actual results: 1. show error message "/etc/" Illegal file name 2. buffer remains empty. I'm unable to duplicate your problem. I don't like changing the s:vimentered logic -- causes problems, that's why its there. The "/etc" illegal file name message is issued by vim, and can't be worked around. Please run the internal debugger (:he netrw-debug) and send me a trace. Also: what o/s are you using and what settings? Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Crash while deleting directory
Dominique Pellé wrote: François Ingelrest wrote: On 26 December 2013 17:54, Dominique Pellé wrote: You need to: - build vim with -g -O0 - make sure vim is not stripped (uncomment #STRIP = /bin/true in vim/src/Makefile). Or run vim from the vim/src/. directory, as it is not stripped there. - start vim with gdb: $ cd vim/src $ gdb ./vim (gdb) run ... and when it crashes... (gdb) backtrace Vim doesn't crash when compiled with -g -O0 so I don't get a stack trace, although it's impossible to edit the buffer as Lech said. $ cd vim/src $ valgrind --log-file=valgrind.log \ --track-origins=yes \ --num-callers=50 ./vim Attached is the Valgrind log. Salut François I still cannot reproduce the bug somehow. Maybe it depends on some settings in your ~/.vimrc. Nevertheless, the error you find with valgrind is useful: [snip] Hello! I'm using vim 7.4.131 (Huge version with GTK2-GNOME GUI), and haven't used Dominque's patch. When trying your problem out, netrw went up a directory, even though foo no longer existed; both going-up-directory techniques worked ( on "..", and using "-"). I then tried using vim -u simple.vimrc where contained the following two lines, only: set nocp filetype plugin on Again, no problems. I don't think I can fix this problem thus far. Do you have any netrw-associated settings that you could share? Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Latest netrw doesn't work with multi-byte strings
mattn wrote:
On Thursday, December 5, 2013 1:18:17 PM UTC+9, Charles Campbell wrote:
mattn wrote:
Hi list.
Currently, vim bundle netrw v149. It doesn't work with multi-byte strings.
This problem occur in v149, 150j both.
Below is a patch for v150j.
--- autoload/netrw.vim.org 2013-11-29 09:51:50.637597900 +0900
+++ autoload/netrw.vim 2013-11-29 09:53:09.361597900 +0900
@@ -8608,7 +8608,7 @@
" get the list of files contained in the current directory
let dirname= b:netrw_curdir
- let dirnamelen = s:Strlen(b:netrw_curdir)
+ let dirnamelen = strlen(b:netrw_curdir)
let filelist = glob(s:ComposePath(dirname,"*"),0,1)
let filelist = filelist + glob(s:ComposePath(dirname,".*"),0,1)
" call Decho("(LocalListing) filelist=".filelist)
I'm sorry; I just noticed that you mentioned v150j. The s:Strlen()
function is (by default) using strdisplaywidth(); does this not work?
Please give me an example so I can test things out.
Thank you,
Charles Campbell
dirnamelen is used for:
let pfile= strpart(pfile,dirnamelen)
* autoload/netrw.vim:L8689
A second argument of strpart should be byte size not display width.
For example, directory name contains multi-byte like follow,
c:/[][][]/foo.txt
* [] is multi-byte.
let pfile = strpart(pfile, length_until_last_slash)
length_until_last_slash should be 10. if using s:Strlen(), it become 7.
So it display broken bytes in netrw.
- Yasuhiro Matsumoto.
Ok, please try v150k of netrw, available on my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW .
Regards,
C Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Latest netrw doesn't work with multi-byte strings
mattn wrote:
Hi list.
Currently, vim bundle netrw v149. It doesn't work with multi-byte strings.
This problem occur in v149, 150j both.
Below is a patch for v150j.
--- autoload/netrw.vim.org 2013-11-29 09:51:50.637597900 +0900
+++ autoload/netrw.vim 2013-11-29 09:53:09.361597900 +0900
@@ -8608,7 +8608,7 @@
" get the list of files contained in the current directory
let dirname= b:netrw_curdir
- let dirnamelen = s:Strlen(b:netrw_curdir)
+ let dirnamelen = strlen(b:netrw_curdir)
let filelist = glob(s:ComposePath(dirname,"*"),0,1)
let filelist = filelist + glob(s:ComposePath(dirname,".*"),0,1)
" call Decho("(LocalListing) filelist=".filelist)
I'm sorry; I just noticed that you mentioned v150j. The s:Strlen()
function is (by default) using strdisplaywidth(); does this not work?
Please give me an example so I can test things out.
Thank you,
Charles Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Latest netrw doesn't work with multi-byte strings
mattn wrote:
Hi list.
Currently, vim bundle netrw v149. It doesn't work with multi-byte strings.
This problem occur in v149, 150j both.
Below is a patch for v150j.
--- autoload/netrw.vim.org 2013-11-29 09:51:50.637597900 +0900
+++ autoload/netrw.vim 2013-11-29 09:53:09.361597900 +0900
@@ -8608,7 +8608,7 @@
" get the list of files contained in the current directory
let dirname= b:netrw_curdir
- let dirnamelen = s:Strlen(b:netrw_curdir)
+ let dirnamelen = strlen(b:netrw_curdir)
let filelist = glob(s:ComposePath(dirname,"*"),0,1)
let filelist = filelist + glob(s:ComposePath(dirname,".*"),0,1)
" call Decho("(LocalListing) filelist=".filelist)
Hello!
Please use netrw v150j on my website; this problem has been addressed
earlier.
http://www.drchip.org/astronaut/vim/index.html#NETRW
Regards,
Charles Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [PATCH] Asynchronous functions (settimeout, setinterval, and cancelinterval)
Bram Moolenaar wrote: Michael Henry wrote: I've been wondering about the use of CTRL-C regarding timers. There has been a lot of discussion on ways to regain control in the face of a runaway timer, which is of course an important consideration. I've been wondering, however, about any negative effects of accidental cancellation. If I understand correctly, when a user presses CTRL-C while a timer happens to be running, that timer will be canceled and not rescheduled. Can this happen accidentally when the user is pressing CTRL-C for other reasons (e.g., to abandon an ex-mode command he was typing)? Since timers might be running at arbitrary times, how can a user be sure it's safe to press CTRL-C without running the risk of canceling a timer by mistake? Should it require multiple CTRL-C presses in a row before aborting current and future timers, or is there some other way to make sure the user won't accidentally cancel timers that are operating properly? The problem with timers is that they repeat. I would think a first CTRL-C would "pause" a timer if it's clear that was the intention of hitting CTRL-C. As suggested, that the timer has been running for more than a certain time would work. Anything that's stuck must quit when CTRL-C is pressed. That's what it's for. But if the timer runs for a short time, but very often, it may still cause the user to hit CTRL-C to stop it. Perhaps we can detect that the user types CTRL-C twice in a row, then we know we need to cancel more than just the current operation. If there are multiple things that could be interrupted, a "what do you want to interrupt?" dialog could be used (although that's not really user friendly). I would prefer to have CTRL-C pause the timer instead of completely killing it. That gives a way to recover. E.g. if the timer uses a socket that is temporarily unavailable. Would require a "resume timer" command. Would a closely spaced pair of ctrl-c's be detectable and useful in cancelling timers? (ie. one ctrl-c would not suffice, but a doubly-hit ctrl-c would). Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [bug] netrw with netrw_liststyle = 3
Charles E Campbell wrote: Bruno Sutic wrote: Hi, I "discovered" netrw liststyle=3 aka tree style listing a couple days ago. (I love it!) Ever since, I've had a weird issue where I would open a file and it would be completely blank. I'll look into it (and I was able to duplicate it -- thanks for the good directions). Hello! I'm not sure if I replied to you on this yet -- please try v150j of netrw, available from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW . I believe that it fixes this problem (there was also a bugtracker entry on this same problem). Regards, Charles Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: VIM 7.4 BUG
Jorge Solis wrote: if I knew how to fix it, I would do it but my knowledge of vim programming are not too pro 2013/11/13 Jorge Solis mailto:m...@jorgesolis.be>> Hi Mr Campbell. It continued to happen with your vba file. The loss of line position is not a problem in the new tab but in the netrw tab... I meen if you hava a large list of files, maybe you want to open 2 in tabs but after open the first one you lose the line when come back in the netrw tab. that's really bored. Sorry for my english, Hava a nice day, regards from Belgium. 2013/11/9 Charles E Campbell mailto:drc...@campbellfamily.biz>> > > Hello! > > I didn't see this for awhile as the subject didn't mention netrw. Anyway, please try the attached netrw, v150j. > > What I saw: etrw+tree mode did retain line position when t was used to select a file. It did not do so in the new tab page when t was applied to a directory; that latter problem is what I addressed in the attached copy of netrw. > > Regards, > Charles Campbell Would you please provide an exact sequence of steps that evokes this problem. I've tried: vim -u NONE -N -c 'runtime plugin/netrwPlugin.vim' -c "let g:netrw_liststyle= 3" . :let g:netrw_liststyle= 3 :e . (move cursor to a directory name) t :tabn (cursor is where it had been) :tabn (cursor is where it had been) vim -u NONE -N -c 'runtime plugin/netrwPlugin.vim' -c "let g:netrw_liststyle= 3" . :let g:netrw_liststyle= 3 :e . (move cursor to a file name) t :e . :tabn (cursor is where it had been) :tabn (cursor is where it had been) Regards, Charles Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: What is the logic behind limiting the diff buffer count to 4?
ZyX wrote: On Friday, November 1, 2013 10:51:48 AM UTC+4, Nirk Niggler wrote: From structs.h: # define DB_COUNT 4/* up to four buffers can be diff'ed */ Is there a compelling reason to keeping the limit at 4 rather than upping it to a limit like 9? I do not know reason for 4 (though @LCD 47 suggested the one that makes sense), but what is the reason for limit equal to 9? I you want to raise it you must explain why. I recompiled vim with a DB_COUNT of 5, and that successfully worked to diff five files. I suspect that the DB_COUNT limit can be raised without difficulty. I suspect that with a bit of coding that the DB_COUNT could be made arbitrary (ie. dependent upon how many files are being requested for simultaneous diffing). 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/groups/opt_out.
Re: Syntax Highlighting Doesn't Work with Recursive `nextgroup` Across Newlines When Contained
Dan Doel wrote: On Thu, Oct 31, 2013 at 11:53 AM, Charles Campbell wrote: MMAMBMB # a b b # b b M At the time the syntax hilighter sees the "#" in "# b b", note that '#\=\s*\zsb' DOES NOT MATCH. However, the "M" syntax DOES MATCH, and so its highlighted as MyComment. Syntax highlighting is tricky. This does not explain why the bs in the second line are still not matched even when the comment rule is removed. Is it that the entire nextgroup is thrown away, because the # is not officially part of the B match, so it is counted as not matching? I note that removing the '#\=\s*\zs' portion from the B match: syn clear syntax match MyComment '#.*$' contains=A syntax match A 'a' nextgroup=B skipwhite skipnl syntax match B 'b' contained nextgroup=B skipwhite skipnl highlight default link A Type highlight default link B Error highlight default link MyComment Comment and using it on # a b b b b b also shows the "b"s on the second line without highlighting. What I think is happening is that MyComment matches to only one line which may contain A; once a newline is encountered, the MyComment match terminates, taking the A and B matches with it. I tried using the extend keyword, but that didn't affect the resulting highlighting. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [patch] 'undolevels' should be buffer-local
Christian Brabandt wrote: Hi Charles! On Do, 31 Okt 2013, Charles Campbell wrote: Please try LargeFile v5k. This version should retain undo history if your vim has persistent undo available. Its pretty new, so there may well be bugs with the undo history stuff. You may get a copy from my website: http://www.drchip.org/astronaut/vim/index.html#LARGEFILE May I ask, how you work around it? I use BufEnter and BufLeave events coupled with bufdo, rundo, and wundo. Regards, Charles Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [patch] 'undolevels' should be buffer-local
Ben Fritz wrote: On Tuesday, October 29, 2013 9:17:43 PM UTC-5, Samuel Ferencik wrote: It seems this got missed (back in 2010). Can we resurrect it, please? Yes, please! I actually have removed the LargeFiles plugin, because I kept losing all my undo history on files I already had open in Vim! I would add it back fairly quickly if it were able to only affect the buffer for the large file instead of every buffer in Vim! Hello, Ben: Please try LargeFile v5k. This version should retain undo history if your vim has persistent undo available. Its pretty new, so there may well be bugs with the undo history stuff. You may get a copy from my website: 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/groups/opt_out.
Re: bash syntax: incorrect highlighting of escaped double quote
Marvin Renich wrote:
The sh.vim syntax file does not recognize the escaped double quote
inside the double-quoted string in the following bash snippet:
---8<
#!/bin/bash
for r in $reqFields ; do
if [[ -z "${keys[$r]}" || "${keys[$r]}" == "\"\"" ]] ; then
missing="$missing $r"
fi
done
--->8
It looks like the shDoubleQuote region has a skip clause that is
supposed to handle this, but it isn't working for me. If you can't
reproduce this, I'll try to narrow it down more. b:is_bash is being set
correctly, and syntax list shDoubleQuote shows the expected contents.
How can you determine what syntax group is used for a particular
character?
Hello!
Please try v133 of syntax/sh.vim, available at my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_SH .
As for your question... I use my hilinks plugin (with :HLT!):
http://www.drchip.org/astronaut/vim/index.html#HILINKS .
Regards,
C Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Syntax Highlighting Doesn't Work with Recursive `nextgroup` Across Newlines When Contained
Dan Doel wrote: On Sunday, October 27, 2013 4:56:18 PM UTC-4, Christian Brabandt wrote: A workaround is something like this (which looks cleaner for me) syntax match MyComment '#.*$' contains=A,B syntax match A 'a' nextgroup=B skipwhite skipnl syntax match B 'b' contained nextgroup=B skipwhite skipnl This does something different, though. For instance, the original should not highlight the bs in the second row of: # a b b # c b b while the replacement will. I don't think the original should actually work as specified, since it would make sense to me for the nextgroups to be contained in the comment region, which is one line. But, even without the comment match, it doesn't work correctly; the \zs stops the pattern from matching for some reason, as noted, which doesn't seem right. (to make sense of my examples, please used a fixed width font) (am avoiding html to do this myself as that prompts screams and bewailings from some of the group) Now, including the OP's syntax highlighting: M: syntax match MyComment '#.*$' contains=A A: syntax match A 'a' nextgroup=B skipwhite skipnl B: syntax match B '#\=\s*\zsb' contained nextgroup=B skipwhite skipnl MMAMBMB # a b b # b b M At the time the syntax hilighter sees the "#" in "# b b", note that '#\=\s*\zsb' DOES NOT MATCH. However, the "M" syntax DOES MATCH, and so its highlighted as MyComment. Syntax highlighting is tricky. Regards, Charles Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: bash syntax: incorrect highlighting of escaped double quote
Peter Aronoff wrote: On Mon Oct 10/21/13 at 8:04, Ben Fritz wrote: On Monday, October 21, 2013 9:56:26 AM UTC-5, telemachus wrote: Can I ask what email you used to reach him? I've had luck in the past with the email address in the header of his plugins. But you need to remove the capital letters NOSPAM distributed through the email address to confuse email harvesters. Otherwise the address is not valid. When you said that, I thought "Oh, wow, how did I miss NOSPAM"? The good news is that I didn't. The bad news is that the maintainer for indent/sh.vim is not Dr. Chips. It's Nikolai Weibull. His email address doesn't have NOSPAM in it. Having said that, and I've asked this once before, what recourse do I have when nobody responds either here on the list or the maintainer? For what it's worth, here's my original mail and my question about contacting maintainers: https://groups.google.com/d/msg/vim_dev/WszUzmhaDGM/W31QcXPpKcMJ https://groups.google.com/d/msg/vim_dev/Q_KGrMevqW0/g2zLu-Set5AJ Try contacting Bram Moolenaar (:help moolenaar will give you his email). In the past in similar situations he's tried to contact the maintainer himself and then he's likely to ask you if you'd be willing to become the maintainer. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: VIM 7.4 BUG NetrwTree
Jorge Solis wrote: I can close NetrwTree in tree mode. There is a mesage that says the file has change, use :q! but that does not work too I think you're saying that there's a problem -- but I don't know what it is. Please give a sequence of actions that elicits the problem so that I may duplicate it. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Error when matching a null character with NFA engine
Bram Moolenaar wrote: Christian Brabandt wrote: On Do, 19 Sep 2013, Jonathon Merz wrote: With the new regexp engine, when searching for a null character using decimal/octal/hex character matches, all lines are matched instead of only the specified character. The attached .txt file (ok to attach I hope) has a null character (represented as "^@") in the first line. Using the new engine: \%#=2\%d0 Matches all lines in the file, but using: That doesn't match for me anything. \%#=1\%d0 matches only the null character as expected. The same goes for using \%o and \%x to match characters specified in octal and hex. This patch fixes it: Thanks! Guess what the bonus question is... Testy, testy, testy! :) 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/groups/opt_out.
Re: BufEnter and echomsg
Bram Moolenaar wrote:
Charles Campbell wrote:
I'm having a problem exemplified by the following code snippet: (lets
call this prblm.vim)
au BufEnter * sil! call Prblm(expand(""))
fun! Prblm(fname)
let g:junk= 1
echomsg "TESTING<".a:fname.">"
endfun
vsplit
Use vim -u NONE prblm.vim
:so %
:echo g:junk
At this point, we get E121 and E15. Expected.
:mess
No messages other than the error messages from before.
:enew
:echo g:junk
Note that g:junk is now equal to 1. OK so far...
:mess
The "TESTING..." message is missing, but since g:junk both exists and is
equal to 1, obviously the Prblm() function was called. (scientific linux
6.3; vim 7.4.25, huge).
Did you try putting "unsilent" before "echomsg" ?
No, first I heard of that command - and, naturally, it works. Thank
you! Glad it wasn't a vim bug.
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/groups/opt_out.
BufEnter and echomsg
Hello!
I'm having a problem exemplified by the following code snippet: (lets
call this prblm.vim)
au BufEnter * sil! call Prblm(expand(""))
fun! Prblm(fname)
let g:junk= 1
echomsg "TESTING<".a:fname.">"
endfun
vsplit
Use vim -u NONE prblm.vim
:so %
:echo g:junk
At this point, we get E121 and E15. Expected.
:mess
No messages other than the error messages from before.
:enew
:echo g:junk
Note that g:junk is now equal to 1. OK so far...
:mess
The "TESTING..." message is missing, but since g:junk both exists and is
equal to 1, obviously the Prblm() function was called. (scientific linux
6.3; vim 7.4.25, huge).
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/groups/opt_out.
Re: Alternate file with netrw buffer in Vim 7.4 - bug or change?
tooth pik wrote: On Mon, Aug 26, 2013 at 05:11:19PM -0400, Charles Campbell wrote: Bram Moolenaar wrote: Bruno Sutic wrote: The change supporting this was done on July 12, 2013; its for v150, which has not been released as yet. That was the "bugfix" that I was referring to; I think I misinterpreted what was said. That change is on my website as an alpha/beta version of netrw (v150f). http://www.drchip.org/astronaut/vim/index.html#NETRW is it? when I go there I see v150e... Sorry -- netrw v150f was marked "NOT RELEASED" -- so v150e was actually the latest version I'd made available. I've now released v150f onto my website; it contains a new option, g:netrw_altfile, which allows one to select the behavior of ctrl-^ vis-a-vis netrw. I'm hoping to get sftp to work properly before I release v150 "to the world", but as school is starting back up, and work is heating up, it may be a bit. 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/groups/opt_out.
Re: Alternate file with netrw buffer in Vim 7.4 - bug or change?
Bram Moolenaar wrote: Bruno Sutic wrote: Hi, I noticed a "new" behavior with vim 7.4 and netrw plugin. Alternate buffer command (normal mode C-^ key) works differently than in vim 7.3. Here are the steps how to see the difference: *vim 7.3* 1. /usr/bin/vim -u NORC -N (starting vim7.3) 2. :e Gemfile (open any random file) 3. :E(show netrw plugin buffer) 4. 5. C-^ (alternate buffer) At this point vim shows netrw buffer opened in step 3 *vim 7.4* (the same steps) 1. vim -u NORC -N (starting vim7.4) 2. :e Gemfile 3. :E 4. 5. C-^ At this point vim 7.4 shows 'Gemfile' file opened in step 2 What do you think is this a bug or new behavior? Thanks I also see this problem. I prefer the old way, I often go back to the directory view. I thought Charles had changed it... The change supporting this was done on July 12, 2013; its for v150, which has not been released as yet. That was the "bugfix" that I was referring to; I think I misinterpreted what was said. That change is on my website as an alpha/beta version of netrw (v150f). http://www.drchip.org/astronaut/vim/index.html#NETRW Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Alternate file with netrw buffer in Vim 7.4 - bug or change?
Bruno Sutic wrote: Hi, I noticed a "new" behavior with vim 7.4 and netrw plugin. Alternate buffer command (normal mode C-^ key) works differently than in vim 7.3. Here are the steps how to see the difference: *vim 7.3* 1. /usr/bin/vim -u NORC -N (starting vim7.3) 2. :e Gemfile (open any random file) 3. :E(show netrw plugin buffer) 4. 5. C-^ (alternate buffer) At this point vim shows netrw buffer opened in step 3 *vim 7.4* (the same steps) 1. vim -u NORC -N (starting vim7.4) 2. :e Gemfile 3. :E 4. 5. C-^ At this point vim 7.4 shows 'Gemfile' file opened in step 2 What do you think is this a bug or new behavior? That's the effect of a bugfix. C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Vim syntax file should not require interpreter support to highlight :{interp}<
James McCoy wrote: On Aug 21, 2013 1:42 PM, "Charles Campbell" mailto:charles.e.campb...@nasa.gov>> wrote: > > LCD 47 wrote: >> >> ..snip.. >> >> +1 for this. People routinely edit files that only make sense (and >> will only ever run) on remote servers. There are legitimate situations >> where editing a file has nothing to do with actually running it. >> > Except, if its embedded in vimscript, then it is intended to be executed by vim. But not necessarily *this* Vim, which is the point. The syntax is valid regardless of whether this Vim has been built to execute the syntax. Which again means: the writer of the script has no intention of testing it at the current time. Bad idea. Nonetheless, I've have posted a new version at my website and given a copy to Bram several days ago. -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Small addition to syntax/vim.vim
Bram Moolenaar wrote: Manuel Ortega wrote: As noted in an earlier thread, I discovered that most attributes to ":command" can be abbreviated. I discovered this only by accident, looking in syntax/vim.vim. Turns out, in that syntax file (a) there is no support for the attribute "-buffer" (for buflocal commands), and (b) trial and error indicates that the attribute "-buffer" CAN be abbreviated all the way down to "-b". So Dr. Chip, please add this attribute to the syntax file. And Bram, please note this in the docs about "-buffer" too. This is not really intended to work that way. It happens that because the code uses the length of the typed argument to compare that it happens to work. But I really would prefer everybody to use the whole name. One might call it a bug, but since some scripts rely on it we probably won't fix it. I have two (visIncr, vimball) that use -ra= and -na= ... so I'll make them use full names. Should I have syntax/vim.vim flag short option names as errors? 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/groups/opt_out.
Re: Vim syntax file should not require interpreter support to highlight :{interp}<
LCD 47 wrote: ..snip.. +1 for this. People routinely edit files that only make sense (and will only ever run) on remote servers. There are legitimate situations where editing a file has nothing to do with actually running it. Except, if its embedded in vimscript, then it is intended to be executed by 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: Two bugs in vim.vim syntax file
Manuel Ortega wrote:
There are at least two bugs in vim syntax highlighting. It occurs
when one leaves out optional spaces in a List or Dictionary.
For example:
let foo = ['one','two','three']
shows distractingly bizarre highlighting. The second and third
elements have only their first letter colored, and that color is
different from the color of the first element. No such problem exists
if there are spaces after *ALL* the commas. This problem is
relatively recent (like within the last few months sometime).
A similar problem for Dictionaries exists. For instance:
let foo = {'one':'Washington', 'two':'Lincoln'}
Here, the values are uncolored even though the keys are colored.
Also, the lefthand single-quotes for the values are uncolored, but
their righthand single quotes are colored. Both the keys and the
values should be colored. No such problem exists if there are spaces
after the colons.
The latter problem (or something VERY close to it) has been around for
a really long time.
The problem is discriminating between marks and strings. My "solution"
has been to reduce the number of items detected as marks and to favor
strings. Please try
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM .
Regards,
C Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Patch] Escape file names when reading files in Zip container
Cedric Bosdonnat wrote: Hello Charles, On Thu, 2013-08-01 at 14:56 -0400, Charles Campbell wrote: I believe that this issue has been addressed previously. You can get the latest zip plugin from my website: http://www.drchip.org/astronaut/vim/index.html#ZIP Indeed, that is fixed in your latest source. Do you know what is the process to get that in the official vim sources to have it picked by the linux distros? Yes. I update the scripts I maintain and post them on my website. Occasionally, after they've been there for awhile without complaints, I send them upstream. 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/groups/opt_out.
Re: Vim 7.4b not getting any syntax or other default files
Sazid Al Rashid wrote: Recently, I compiled Vim 7.4b with Python, Ruby, Lua, Perl and huge feature list. But, in Ubuntu 13.04, when I open Vim 7.4b, it complains that the syntax.vim file could not be loaded. Moreover, it did not load the other things, like-colorschemes and default plugins. Then, I copied the whole /usr/share/vim74b/ directory to /usr/share/vim74 and it worked! I don't know, if its a bug or because of the version number(vim74b)! Did you perhaps sometime in the misty past set up a "VIMRUNTIME" environment 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/groups/opt_out.
Re: [Patch] Escape file names when reading files in Zip container
Cedric Bosdonnat wrote: Hello, I'm editing OOXML files pretty often with vim and the zip plugin. However those have a [Content_Types.xml] file inside the zip that can't be opened. You'll find attached a simple patch against trunk to fix that problem by just escaping the name of the file to open in the unzip command. I believe that this issue has been addressed previously. You can get the latest zip plugin from my website: http://www.drchip.org/astronaut/vim/index.html#ZIP 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/groups/opt_out.
Re: Why C? If so how is the best way to have simple lists ?
David Larson wrote:
On Saturday, June 8, 2013 2:48:39 PM UTC-7, Bram Moolenaar wrote:
There are no options. Vim is written in C and I see no reason to
change. Perhaps, when Zimbu is "ready" I might consider rewriting some
pieces in Zimbu, but that's going to take several years during which no
bugs will be fixed and no new features will be added. For a similar
reason Elvis no longer exists...
Aack! Don't do that! We want VIM to stay alive. I personally am not willing to
see no advancement in VIM for several years just so that it can be ported to
Zimbu. (Perhaps that was your point...)
It seems somewhat safe to me if the file names were changed from .c to .cpp.
That would allow us to leverage basic libraries and simple OOP. We can steer
clear of the more esoteric and tricky features of the language.
I use some macros... (outofmem() can be removed; it checks if the
returned pointer is null, isses the failure message if so, and
terminates). These four macros presume that there are "nxt" and "prv"
pointers in the structure for linking.
#define double_link(structure,head,tail,fail_msg)
{\
structure *newstr; \
newstr= (structure *)
malloc(sizeof(structure)); \
outofmem((void *)
newstr,"%s\n",fail_msg); \
if(tail) (tail)->nxt=
newstr; \
else head =
newstr; \
newstr->prv= tail; \
newstr->nxt= (structure *)
NULL; \
tail = newstr; \
}
#define delete_double_link(structure,str,head,tail)
{ \
structure *old=
str; \
if(old) { \
if(old->prv) old->prv->nxt=
old->nxt; \
else head =
old->nxt; \
if(old->nxt) old->nxt->prv=
old->prv; \
else tail =
old->prv; \
free((char *)
old);\
} \
}
#define only_double_link(structure,newstr,head,tail)
{ \
if(tail) (tail)->nxt=
newstr; \
else head =
newstr; \
newstr->prv= tail; \
newstr->nxt= (structure *)
NULL; \
tail = newstr; \
}
#define only_delete_double_link(structure,str,head,tail)
{ \
structure *old=
str; \
if(old) { \
if(old->prv) old->prv->nxt=
old->nxt; \
else head =
old->nxt; \
if(old->nxt) old->nxt->prv=
old->prv; \
else tail =
old->prv; \
} \
}
Typical use:
struct ABC_str {
double something;
struct ABC_str *nxt;
struct ABC_str *prv;
} *abchd= NULL, *abctl= NULL;
double_link(struct ABC_str, abchd,abctl,"failed while attempting to
double-link an ABC_str");
struct ABC_str *abc;
delete_double_link(struct ABC_str,abc,abchd,abctl);
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/groups/opt_out.
Re: Vim slow after big count insert
Dimitar DIMITROV wrote: > > There is no use case > If you do something stupid by accident most vim operations can be > aborted by ctrl-c (exception: python, rbuy, .. scripts) Try to abort it you will see the success you have. > So there is still nothing to fix or talk about unless there is a use > case. > > Marc Weber I tried this problem with both 100iHello 100iHello In both cases ctrl-c worked just fine to break the operation. I used vim 7.4a.35 on a linux system when trying this. Regards, C Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Patch: Remove invalid keywords from syntax/vim.vim
Nikolay Pavlov wrote:
On Jul 14, 2013 9:36 PM, "Tony Mechelynck"
mailto:antoine.mechely...@gmail.com>>
wrote:
>
> On 07/14/13 17:40, glts wrote:
>>
>> Hi list,
>>
>> sent this to the maintainer in May. Now resending an updated patch to
>> the list. I removed some mistaken keywords from the vimCommand syntax
>> group, namely:
>>
>> DiffOrig
>> Man
>> Ren
>> TOhtml
>> XMLent
>> XMLns
>> bar
>> browseset
>> c
>> cmdname
>> comment
>> count
>> dwim
>> emenu*
>> errormsg
>> filename
>> get
>> index
>> let@
>> locale
>> mkdir
>> mv
>> nkf
>> quote
>> s@\n@\=\r"
>> star
>> synlist
>> xterm
>>
>> Please check.
>>
>> Some of the false positives are pretty strange, so I'd say it is
perhaps
>> not the best idea to mine these keywords directly from the help files.
>> Why not maintain them by hand?
>>
>> Best,
>>
>
> Some of them, including as :DiffOrig, Man, :TOhtml, etc., are
commands defined in standard plugins and described in the help.
:quote, :bar and :star are the helptags for :" (Vim comment) :|
(concatenating several commands on one ex-command-line) and :*
('compatible' equivalent of :@) respectively, due to the fact that Vim
translates " | and * to these words before looking up any help subject
in the tags file.
>
> These keywords are generated automatically from the Vim helpfiles,
rather than painstakingly searched for, because the automatic process
is much faster, and, though not perfect, much less error-prone than
maintaining the lists by hand.
I would suggest to maintain a list of exceptions in this case thus.
And filter out everything that does not match '^\l\+$'.
I've put syntax/vim.vim version 7.4a-1 up on my website:
http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM . I don't
intend to remove the documented standard-plugin commands that are in the
help (:TOhtml, etc).
As far as "why not maintain them by hand", I agree with Tony: very error
prone. Its easier to remove incorrect ones by filtering. Plus, it'd be
extremely tedious.
Thank you for your feedback!
Chip Campbell
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
warnings while compiling vim 7.4a.23
In file included from regexp.c:7918: regexp_nfa.c: In function 'addstate': regexp_nfa.c:3850: warning: 'save_lpos.lnum' may be used uninitialized in this function regexp_nfa.c:3850: warning: 'save_lpos.col' may be used uninitialized in this function regexp_nfa.c:3852: warning: 'save_ptr' may be used uninitialized in this function search.c: In function 'current_search': search.c:4512: warning: 'save_VIsual.lnum' may be used uninitialized in this function 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/groups/opt_out.
Re: vim stops
Manuel Ortega wrote:
1. command /usr/local/bin/vim -nNX -u NONE
Bram,
I looked at this and didn't remember offhand what the '-X' flag did.
No wonder: 'vim --help' has no entry for that flag. But ':h
startup-options' *does* say what the flag does. Please update the
output of 'vim --help'.
I shall now hunt for other discrepancies between 'vim --help' and ':h
startup-options'.
I think you wanted a new topic; irregardless, you appeared to have
"Replied" to an unrelated topic ("Re: vim stops). A better approach
with Seamonkey, for example, is (typically) to right click on the "To"
field and then to "compose mail to". Avoids losing your new topic in an
unrelated thread. You should investigate to find out what works best
with your email agent.
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/groups/opt_out.
Re: Patch 7.3.1301
Bram Moolenaar wrote:
Nikolay Pavlov wrote:
On Jul 4, 2013 10:25 PM, "Bram Moolenaar" wrote:
Nikolay Pavlov wrote:
It's the other way around: On MS-Windows you can do:
:e foo\$bar
That is editing the file "$bar" in directory "foo". On Unix this has
a
different meaning, editing file "foo$bar", thus not using $bar as an
environment variable. That's why test 97 won't work on MS-Windows.
I had a problem with expand(fnameescape('$HOME')): here '$HOME' is
assumed
to be ./$HOME and fnameescape() does not cope with this. Same for
./a$HOME:
it tries to edit either ./aC:... (which is impossible due to requirement
not to have colon in the filename) or ./a/$HOME. There is a bug here.
It's a problem, since:
:e $HOME
Means to expand the environment variable $HOME, while
:e \$HOME
Might mean editing the file "$HOME" in the current drive.
Backslash escaping just doesn't work here. Perhaps we should require
Windows style environment variables:
:e %HOME%
That's not backwards compatible though.
I would suggest different kind of escaping: $$ will mean a single $. Not
the best as it adds different meaning to $, but since backslash was
partially released from its regular meaning (escape character) it is the
best I can deduce.
Yeah, using $$HOME where $HOME is meant literally would probably work
best. But it's very difficult to make all pieces of the code, with
environment variable expansion and wildcard handling work properly.
I'll make it a todo item.
May I point out that, under both Korn shell and Bash, $$ expands to the
process pid; currently it appears to do nothing under vim, though.
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/groups/opt_out.
Re: Patch 7.3.1301
Bram Moolenaar wrote:
Nikolay Pavlov wrote:
It's the other way around: On MS-Windows you can do:
:e foo\$bar
That is editing the file "$bar" in directory "foo". On Unix this has a
different meaning, editing file "foo$bar", thus not using $bar as an
environment variable. That's why test 97 won't work on MS-Windows.
I had a problem with expand(fnameescape('$HOME')): here '$HOME' is assumed
to be ./$HOME and fnameescape() does not cope with this. Same for ./a$HOME:
it tries to edit either ./aC:... (which is impossible due to requirement
not to have colon in the filename) or ./a/$HOME. There is a bug here.
It's a problem, since:
:e $HOME
Means to expand the environment variable $HOME, while
:e \$HOME
Might mean editing the file "$HOME" in the current drive.
Backslash escaping just doesn't work here. Perhaps we should require
Windows style environment variables:
:e %HOME%
That's not backwards compatible though.
Removing $HOME as expandable under Windows to the environment variable
value would definitely break some plugins I have.
I think having %HOME% work under Windows would not be a problem, so
expand(fnameescape('%HOME%')) could work, too.
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/groups/opt_out.
Re: syntax problem in vim.vim: vimUserAttrbCmpltFunc
itchyny wrote: Hi list. There is a problem in vim.vim for |command-completion-customlist|. - command! -nargs=+ -complete=customlist,s: X call s:x() - The above example is looks like: https://f.cloud.github.com/assets/375258/752414/fb5dee78-e543-11e2-8fcd-b9ea89846ad6.png Expected: https://f.cloud.github.com/assets/375258/752415/ff719bc2-e543-11e2-97cd-f552f0139768.png While using a script function for custom completion is allowed (not documented; but can be executed as we expect), the syntax-group vimUserAttrbCmpltFunc does not. The `s:` is colored by vimUserCmdError. A patch is attached. Thanks. Please try syntax/vim.vim v7.3-26 , available at my website at http://www.drchip.org/astronaut/vim/index.html#SYNTAX_VIM . The problem: s:Xxxx was permitted (old rules for what was allowed to be a function name), but lower case such as s: was not. syntax/vim.vim is now updated to use \h instead of \u (ie. head-of-word) to recognize that first letter following the s:. Regards, Chip Campbell -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
