Re: GSoC Regexp engine
Ian Young wrote: I have a couple questions to start things off. First: I couldn't see much need for 'fuzzy matching' in Vim, but some of you are probably much better acquainted with regexp use cases than I am. Would this be a useful feature to have available? As you likely know, fuzzy matching hasn't been available in Vim. One place it has been useful is in suggesting spelling corrections; I myself used agrep in the engspchk.vim plugin to support fuzzy matching. Bram already has a spelling error suggestion feature, so I have no idea if the fuzzy regex would help with it or not. What I think could be more useful would be boolean logic for regexp. My LogiPat plugin provides this capability, but undoubtedly it'd be better if somehow it could be incorporated. The resulting patterns from LogiPat seem to me to be somewhat opaque. Regards, Chip Campbell
Re: A performance question (patch included)
John Beckett wrote:
A.J.Mechelynck wrote:
What about a different function to return, say, the number of
1K blocks (or the number of times 2^n bytes, with a parameter
passed to the function) that a file uses?
Yes, that's a much more general and better idea.
Since there's probably not much need for this, I think that
simplicity would be good. That is, have the function work in a
fixed way with no options.
Re Dr.Chip's LargeFile script: It occurs to me that another
workaround would be to use system() to capture the output of
'ls -l file' or 'dir file' (need an option for which).
Then do some funky editing to calculate the number of digits in
the file length. If more than 9, treat file as large.
I'm playing with a tiny utility to help the LargeFile script.
Bluesky: Its code (64-bit file size) could potentially be
incorporated in Vim. I'll post results in vim-dev.
(I've moved this over to vim-dev)
I've attached a patch to vim 7.1 which extends getfsize(); with the
patch, getfsize() takes an optional
second parameter which gives one the ability to specify a unitsize.
In other words,
getfsize(eval.c) - 478347 (after the patch)
getfsize(eval.c,1000) - 479 (truncated upwards)
I'll be awaiting Bram's input before making use of this in LargeFile.vim !
Regards,
Chip Campbell
*** src/o_eval.c2007-05-25 08:52:12.0 -0400
--- src/eval.c 2007-05-25 09:04:43.0 -0400
***
*** 7094,7100
{getcwd,0, 0, f_getcwd},
{getfontname, 0, 1, f_getfontname},
{getfperm, 1, 1, f_getfperm},
! {getfsize, 1, 1, f_getfsize},
{getftime, 1, 1, f_getftime},
{getftype, 1, 1, f_getftype},
{getline, 1, 2, f_getline},
--- 7094,7100
{getcwd,0, 0, f_getcwd},
{getfontname, 0, 1, f_getfontname},
{getfperm, 1, 1, f_getfperm},
! {getfsize, 1, 2, f_getfsize},
{getftime, 1, 1, f_getftime},
{getftype, 1, 1, f_getftype},
{getline, 1, 2, f_getline},
***
*** 10135,10142
{
if (mch_isdir(fname))
rettv-vval.v_number = 0;
! else
rettv-vval.v_number = (varnumber_T)st.st_size;
}
else
rettv-vval.v_number = -1;
--- 10135,10151
{
if (mch_isdir(fname))
rettv-vval.v_number = 0;
! else if (argvars[1].v_type == VAR_UNKNOWN)
rettv-vval.v_number = (varnumber_T)st.st_size;
+ else
+ {
+ unsigned long unitsize;
+ unsigned long stsize;
+ unitsize= get_tv_number(argvars[1]);
+ stsize= st.st_size/unitsize;
+ if(stsize*unitsize st.st_size) ++stsize;
+ rettv-vval.v_number = (varnumber_T) stsize;
+ }
}
else
rettv-vval.v_number = -1;
*** runtime/doc/o_eval.txt 2007-05-25 09:00:08.0 -0400
--- runtime/doc/eval.txt2007-05-25 09:06:19.0 -0400
***
*** 1615,1621
getcmdtype() String return the current command-line type
getcwd() String the current working directory
getfperm( {fname})String file permissions of file {fname}
! getfsize( {fname})Number size in bytes of file {fname}
getfontname( [{name}])String name of font being used
getftime( {fname})Number last modification time of file
getftype( {fname})String description of type of file {fname}
--- 1615,1621
getcmdtype() String return the current command-line type
getcwd() String the current working directory
getfperm( {fname})String file permissions of file {fname}
! getfsize( {fname} [,unitsize])Number size in bytes of file {fname}
getfontname( [{name}])String name of font being used
getftime( {fname})Number last modification time of file
getftype( {fname})String description of type of file {fname}
***
*** 2819,2827
getcwd() The result is a String, which is the name of the current
working directory.
! getfsize({fname}) *getfsize()*
The result is a Number, which is the size in bytes of the
given file {fname}.
If {fname} is a directory, 0 is returned.
If the file {fname} can't be found, -1 is returned.
--- 2819,2829
getcwd() The result is a String, which is the name of the current
working directory.
! getfsize({fname} [,unitsize]) *getfsize()*
The result is a Number, which is the size in bytes of the
given file {fname}.
+ If unitsize is given, then the file {fname}'s size will be
+ returned in units of size unitsize
Re: A performance question (patch included)
A.J.Mechelynck wrote: I'm not sure what varnumber_T means: will st.stsize (the dividend) be wide enough to avoid losing bits on the left? varnumber_T is int (long if an sizeof(int) = 3). st.stsize 's size depends on whether 32bit or 64bit integers are available. So, its possible to lose bits: pick a small enough unitsize and a large enough file, st.stsize will end up not being able to fit into a varnumber_T. After all, unitsize could be 1, and getfsize() will behave no differently than it does now. However, unitsize could be 100. My patch divides st.stsize by the unitsize first; presumably in whatever arithmetic is appropriate for working with st.stsize. Regards, Chip Campbell
Re: A performance question (patch included)
A.J.Mechelynck wrote: Yes, yes, but before the division, will it be able to hold the file size? (sorry, I meant st.st_size) Will mch_stat (at line 10134, one line before the context of your patch) be able to return huge file sizes? mch_stat is variously defined, depending on o/s. Under unix, that's the fstat function. This function returns a pointer to a struct stat; the member in question is: st_size. (off_t st_size;/* total size, in bytes */) So, st_size is an off_t. Under linux, an off_t is typedef __kernel_off_toff_t So, I suspect that st_size will be sized by the o/s to handle whatever size files it can handle. Someone with a 64-bit machine, perhaps, could examine this further? BTW, I'm also under the impression that ls itself uses fstat(), so its not likely to be any more informative. Regards, Chip Campbell
Re: possible bug with vim7 and the arrow keys
Viktor Kojouharov wrote: It turned out that these mappings broke the arrow keys in the terminal: inoremap expr Esc pumvisible()?\C-E:\Esc inoremap expr CR pumvisible()?\C-Y:\CR inoremap expr Down pumvisible()?\C-N:\Down inoremap expr Up pumvisible()?\C-P:\Up inoremap expr PageDown pumvisible()?\PageDown\C-P\C-N:\PageDown inoremap expr PageUp pumvisible()?\PageUp\C-P\C-N:\PageUp IMHO, if one is expecting to use vim (as opposed to gvim), mapping Esc causes trouble. That's because most terminals issue escape sequences (esc..something..) when special keys (such as the arrow keys, functions keys, etc), and that mapping of the esc key messes up the escape sequence. Besides -- how do you get out of insert mode? I realize one can use ctrl-o and norm!, but that seems painful. If you're not using normal mode or command mode, then you're missing a lot of vim. Regards, Chip Campbell
Re: VIM doesn't need new features?!?!
Peter Michaux wrote: And now I see that VIM doesn't need more features... http://www.vim.org/soc/ideas.php May I suggest taking a look at: http://vim.sourceforge.net/sponsor/vote_results.php Regards, Chip Campbell
Re: syntax/man.vim: manSubHeading is a bit too general?
Ian Tegebo wrote:
On 4/9/07, Nikolai Weibull [EMAIL PROTECTED] wrote:
The manSubHeading is defined as
syn match manSubHeading ^\s\{3\}[a-z][a-z ]*[a-z]$
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are recorded and compared with the data git keeps
where \t is a horizontal tabulation. I'm guessing that the actual
regex should be
^ \{3\}[a-z][a-z ]*[a-z]$
I hope nobody minds if I take this opportunity to ask a question about
vim's pattern matching.
After reading |pattern| I wonder if the following is more efficient:
syn match manSubHeading '^ \{3\}\l\l\?\l$'
(snip)
The pattern you've provided isn't matching the same thing.
The current one: start the line with exactly three spaces or tabs,
followed by a lower case character, followed by any number of
lower case characters or spaces, up to a lower case character
at the end-of-line.
example: spacetabspace aaa aa
Nikolai W's modifies that to start the line with exactly three spaces; the
rest is the same.
example: spacespacespaceaaa aa aaa
Yours: start the line with exactly three spaces, followed by two or three
lower case characters, which then terminates the line.
example: spacespacespaceaa
Do people find this to make a different for moderate file sizes, e.g.
the man page for 'less' being ~2000 lines?
Depends on the line lengths. Your pattern would terminate quite
quickly on each line, as only 5 or 6 characters may be at the beginning
of matching lines; anything more is a mismatch. The original and NW's
both examine the entire line; so if every line had 1GB of characters, these
two patterns would take considerably longer than yours.
Regards,
Chip Campbell
Re: syntax/man.vim: manSubHeading is a bit too general?
Nikolai Weibull wrote: On 4/9/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: In this case, by looking at syntax/man.vim, its: Gautam H. Mudunuri gmudunur AT informatica.com. Actually, this was actually the wrong maintainer. Gautam was the previous maintainer of this file. Nam SungHyun [EMAIL PROTECTED] maintains it now. Whoops -- yes, you're quite right. Sorry 'bout that... Chip Campbell
Re: syntax/man.vim: manSubHeading is a bit too general?
Nikolai Weibull wrote:
The manSubHeading is defined as
syn match manSubHeading ^\s\{3\}[a-z][a-z ]*[a-z]$
This will, however, match more lines than I think is intended. It
will, for example, match the line
\t returns are what are recorded and compared with the data git keeps
where \t is a horizontal tabulation. I'm guessing that the actual
regex should be
^ \{3\}[a-z][a-z ]*[a-z]$
but I'm not sure; I haven't been able to find a reference for the
display of manual pages.
Anyone have any insight into this issue?
I suggest bringing up syntax highlighting issues for a specific filetype
with the syntax highlighting file's maintainer.
In this case, by looking at syntax/man.vim, its: Gautam H. Mudunuri
gmudunur AT informatica.com.
Regards,
Chip Campbell
Re: 7.0.188 - problem with directory browser?
Denis Perelyubskiy wrote: in version 7.0.188 (I am on windows xp, us) nothing works when I select '..' when browsing a directory. has anyone seen this? is this something peculiar to my installation, a bug, or a feature? I suspect that you need a recent version of netrw. To get an up-to-date version of netrw, you'll also need to get an up-to-date version of vimball. So: 1) Get up-to-date versions of vimball and netrw: vimball: http://vim.sourceforge.net/scripts/script.php?script_id=1502 -or- http://mysite.verizon.net/astronaut/vim/index.html#VimBall (the mysite.verizon.net one will be the more recent version) netrw: http://vim.sourceforge.net/scripts/script.php?script_id=1075 -or- http://mysite.verizon.net/astronaut/vim/index.html#NETRW 2) Remove the old vimball plugin and install the new one: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/vimball*.vim autoload/vimball*.vim doc/pi_vimball.txt mv (wherever it was downloaded)/vimball.tar.gz . gunzip vimball.tar.gz tar -xvf vimball.tar Windows: Under Windows, check your runtimepath to determine where your vim 7.0's runtime directories are: vim :echo rtp :q The first directory is likely your personal plugins directory, the second one is your vim system directory. cd (to your vim system directory) del plugin\vimballPlugin.vim del autoload\vimball.vim del doc\pi_vimball.txt ren (wherever)\vimball.tar.gz vimball.tar.gz gunzip vimball.tar.gz tar -xvf vimball.tar 3) Remove system version of netrw: Linux: cd /usr/local/share/vim/vim70 /bin/rm plugin/netrw*.vim autoload/netrw*.vim doc/pi_netrw.txt syntax/netrw*.vim Windows: cd (to your vim system directory) del plugin\netrwPlugin.vim del autoload\netrw.vim del doc\pi_netrw.txt del syntax\netrw.vim 4) Install an up-to-date version of netrw: vim netrw.vba.gz :so % :q Regards, Chip Campbell
Re: BOF Vim 8 - EncryptLine
Matthew Winn wrote: Text editors don't do encryption and never should. How else would you ensure that you can have encrypted text _without_ the need to temporarily store a plaintext copy of the file? Pipe the text through to an external encryption tool, such as pgp. Assuming your o/s supports true pipes... Chip
for vim v8: how about keepundo ?
The idea would be to leave the undo list alone, so that when the undo table gets updated next it'll have a bigger change. Regards, Chip Campbell
Re: for vim v8: how about keepundo ?
Nikolai Weibull wrote: On 1/29/07, Charles E Campbell Jr [EMAIL PROTECTED] wrote: The idea would be to leave the undo list alone, so that when the undo table gets updated next it'll have a bigger change. What do you mean? From the very short description it sounds like your describing :undojoin. A keepundo would be more akin to the keepjumps, keepalt style of suppressing some update for the command which follows. Regards, Chip Campbell
Re: patch 182 and selectbuf [interferes with netrw plugin]
Denis Perelyubskiy wrote: Thanks. While I can't tell what went wrong by just eye-balling the patches, I did find that the problem results from netrwPlugin.vim. Basically, netrw registers this autocommand: au BufEnter .* silent! call s:LocalBrowse(expand(amatch)) When it is executed on a buffer switch, sometimes this amatch is emty. I've no idea why. If I remove the netrw plugin, things go back to normal. I did notice that netrw plugin changed recently... Can you give me an example? Also, what o/s are you using? The s:LocalBrowse() function checks if the name passed to it is a directory. Except for the Amiga, an empty string should be getting ignored (isdirectory() is zero). Regards, Chip Campbell
Re: .vimrc from URL
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: OK, with all that: vim -U NONE -c set nocp|so $HOME/.vim/plugin/netrwPlugin.vim -c so scp://HOSTNAME/.vimrc Rather than -U NONE (i.e., no gvimrc) shouldn't that be -u NORC (i.e., with small u: don't source $HOME/.vimrc but do source the global plugins)? I suggest the amended command-line below (with --cmd for early sourcing): vim -u NORC -N --cmd runtime plugin/netrwPlugin.vim --cmd source scp://HOSTNAME/.vimrc Sounds better! I'll put a note to that effect in pi_netrw.txt. Regards, Chip Campbell
garbage notes in vim.sf.net's tips section
Hello, Scott! I mentioned how there were lots of garbage notes that have been appended to nearly all tips; as an example, I gave out tip#1. I see that the garbage has been cleaned from tip#1, but tips #12-1393 also need cleaning. Seems like it needs some automation to do it, especially if the #() who obviously used a program/script to do it the first time repeats his/her vandalism. Regards, Chip Campbell
tip comment pollution
Hello! Looks like the spammers have been adding their pollution to the tips. Our (unfortunately) hardworking tip inspectors have been getting rid of new spamtips, but the spammers have now started using the Additional Notes process. I note that many of my own tips seem to have four or more pieces of garbage appended. As an example, consider tip#1: http://vim.sourceforge.net/tips/tip.php?tip_id=1 . Can our tip inspectors also elide this form of pollution? Regards, Chip Campbell
Re: Does 'man' syntax do its job?
Zvi Har'El wrote: I tried to use view with the 'man' syntax, for example on the file vimtutor.man obtained by GROFF_NO_SGR=y groff -Tascii -man $(man -w vimtutor) vimtutor.man (see http://www.math.technion.ac.il/~rl/etc/vimtutor.man) (this is not the file vimtutor.man in the vim distribution - the latter doesn't include embedded backspaces). I have the following problem: while the character before an embedded backspace is ignored (sort of: it is colored white), the backspace is printed as a ^H. I would expect the two characters to be skipped all together. (snip) Why would you expect that? Syntax highlighting is highlighting, not inline folding. Vim doesn't support inline folding. Vince Negri has provided a patch to vim's source (http://vince.negri.googlepages.com/) which permits inline folding, though. I've used that feature in AnsiEsc (http://vim.sourceforge.net/scripts/script.php?script_id=302) which highlights text using Ansi Escape sequences (while suppressing the escape sequences themselves). However, it is unrealistic to expect that man.vim would support Negri's unofficial patch; in fact, there's not many scripts that do. One natural use for such a feature would be to allow LaTeX files to be displayed using its embedded directives while suppressing the directives themselves, which would make for nice LaTeX editing. Unfortunately, IMHO, inline folding didn't get enough votes during vim 7.0's development, and Bram is uncomfortable with the idea of inline folding because it, naturally enough, suppresses information (Vince's patch typically folds all lines but the current one). At least, that's how I understand the state of things. Regards, Chip Campbell
Re: Does 'man' syntax do its job?
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: [...] Unfortunately, IMHO, inline folding didn't get enough votes during vim 7.0's development, and Bram is uncomfortable with the idea of inline folding because it, naturally enough, suppresses information (Vince's patch typically folds all lines but the current one). At least, that's how I understand the state of things. Regards, Chip Campbell Doesn't linewise folding also suppress information? Yet Vim has had that for quite some time. It is true that it doesn't make the folds disappear completely; rather, each outer closed fold is replaced by one line. That wouldn't work for inline folding; but maybe it could use the 'foldcolumn' or something to draw attention to the fact that something has been hidden. And BTW, the Hidden highlight group (guibg=bg guifg=bg) also suppresses whatever uses it, yet IIUC it is used a lot in helpfiles. I'm not sure about netrw, but the older Explorer plugin also used it to hide its sort key. That wasn't my objection; I rather like inline folding. Also, perhaps I may not have stated Bram's objection correctly, or perhaps I misunderstood it.After all, he does have the following note in the todo.txt: - Add 'hidecomment' option: don't display comments in /* */ and after //. Or is the conceal patch from Vince Negri a more generic solution? Vince Negri's patch could certainly be used to hide comments but leave the comment start designators visible. It basically allows one to extend syntax highlighting to include the conceal option, so one can specify things to inline conceal. Vince's folding patch supports the notion of conceallevel; taken from his patch to options.txt: 'conceallevel'Effect 0Text is shown normally 1Each block of concealed text is replaced with the character defined in 'listchars' (default is a dash) and highlighted with the Conceal highlight group. 2Concealed text is completely hidden unless it has a custom replacement character defined (see |syn-cchar|. 3Concealed text is completely hidden. Even conceallevel==3 isn't actually completely hidden; instead, the current line (the one the cursor is on and where presumably editing may occur) has its text shown normally (ie. no inline folding on the current line). Regards, Chip Campbell
Re: lost menu
scott wrote: has anyone else lost the ability to get a menu by entering :set guioptions+=m nothing happens i see 4: /usr/local/share/vim/vim70/menu.vim in :scriptnames... no glaring errors on build (7.0.178) i build with export CONF_OPT_GUI='--enable-gnome-check' in SUSE linux 10.0 I don't have any problems seeing a menu (I'm using Fedora Core 5, vim 7.0.1-178). For build options, I use ./configure --with-features=huge --enable-perlinterp I commented out my usual guioptions setting (set guioptions=abegmr) and put your (set guioptions+=m) in instead. So, it appears likely that there's a permission error associated with your being able to use gnome, since it works for you as root. Hmm, are you sure you're using the same vim as root that you are as a user? What does which vim say as user and as root? Why do you need the enable-gnome-check? In Makefile, there's a note: GNOME means GTK with Gnome support. If using GTK, then GNOME will # automatically be used if it is found. If you have GNOME, but do not want to # use it (e.g., want a GTK-only version), then use --enable-gui=gtk. so normally if you use GTK then GNOME will automatically be used, too. Also in the Makefile: # Uncomment one of these lines if you have that GUI but don't want to use it. # The automatic check will use another one that can be found # Gnome is disabled by default, it may cause trouble. ... #CONF_OPT_GUI = --enable-gnome-check which seems to indicate that the --enable-gnome-check is causing GNOME to be disabled, oddly enough. No Gnome, no menu. Regards, Chip Campbell
Re: swapping three columns in a file..
[EMAIL PROTECTED] wrote: How to swap the three columns in file without using substitute command? Let us say file with the following contents, A1 B1 C1 A2 B2 C2 Then after swapping the file content should be, C1 A1 B1 C2 A2 B2 There's visswap, which you can get from http://mysite.verizon.net/astronaut/vim/index.html#VISSWAP (and as mentioned in http://vim.sourceforge.net/tips/tip.php?tip_id=329) With it, you can a) visually select a column using visual blocks (ctrl-v and move cursor) b) press ctrl-y(sort of a yank) c) visually select another column using visual blocks c) press ctrl-x(exchange) Works with V and v (visually selected lines, visually selected characters), too. So: 1) swap columns A C 2) swap columns B A Regards, Chip Campbell
Re: v107m of netrw available -- needs testing!
scott wrote: i am running SUSE linux 10.0, my current vim is 7.0.178 i've tried this before in an attempt to get away from the way all these latest netrws reset my formatoptions for me I'm afraid that I don't see this problem. I've even tried it with your stated preference of fo=tcroqn. vim somefile :Explore somedirectory (select a file) and the resulting formatoption still has tcroqn (I put set fo=tcroqn into my .vimrc for testing). I also tried it using vim -g -c Explore and the formatoption's t was still retained. Are you sure you disabled/removed the older version of netrw? this one gives numerous errors: Error detected while processing function netrw#Explore: line2: E121: Undefined variable: b:netrw_curdir E15: Invalid expression: b:netrw_curdir line 68: E121: Undefined variable: curfile E116: Invalid arguments for function substitute(curfile,'^.*/','','e').'\','cW') E116: Invalid arguments for function search I've got this Explore bug fixed in v107n. And, about vimball: read :help usevimball to find out how to override the use of the runtimepath's first directory as the root for unpacking the vimball. Regards, Chip Campbell
problem with vim.sf.net
Since no one had mentioned it yet; the scripts appear to be inaccessible. Clicking on top rated yields: Can't open file: 'vs_scripts.MYI' (errno: 145) Regards, Chip Campbell
Re: Bug in netrw.vim
Victor Hsieh wrote: With vim 7.0 and netrw.vim version 98, I've encountered a problem when trying to vim http://somewhere/file.txt;. This patch will fix the problem: By the way, netrw is up to version 107a on my website. If you have a problem with netrw, its always best to get the latest version from my website and see if the problem has already been addressed (although e is still being used rather than e! in v107a). My website is: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs (see Network Oriented Reading, Writing, and Browsing for netrw). Regards, Chip Campbell
Re: Bug in netrw.vim
Victor Hsieh wrote: On 10/6/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Victor Hsieh wrote: With vim 7.0 and netrw.vim version 98, I've encountered a problem when trying to vim http://somewhere/file.txt;. This patch will fix the problem: This would silently let users overwrite their own work that they had not saved. I don't think this would be a good idea. In this case, explicitly open the url via vim http://...; can be detected, and there's no more risk. I suppose this is a possible solution :) Again, its not a good idea. Presumably the problem occurred because you edited the page. OK, so what I will do is make files obtained with the http://... format show up as readonly. At least you'll get an earlier notice that editing such files isn't a Good Idea. Netrw uses the trailing slash to determine whether to browse the remote directory or to bring it up for editing. Consider ftp://hostname/some/directory/ -- that trailing slash tells netrw to display directory contents, not attempt to edit a file called directory. Now, http://... normally uses wget, and there's no corresponding wput; hence, editing an http://... url is a read-only operation. So, if one tries to edit a directory with the http protocol (ie. wget), netrw does the best it can and brings it up using ftp. Of course, ftp is a read and write capable protocol, so one can really edit it. I know. But I just want to read the html code or so with my favoriate editor ;) I used to do it with vim6. Actually in most case, connecting to ftp://somewhere (when open http://somewhere) is not gonna work. Not if you don't have the username/password access to the site, 'tis true. I've put a no-browsing exception in for http://... . Please try v107b now on my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs see Network Oriented Reading, Writing, and Browsing Regards, Chip Campbell
Re: Autocommand-Event for Clipboard-Changed
Bram Moolenaar wrote: Suresh Govindachar wrote: Is it possible to add an autocommand-event for Clipboard Changed? Not really. This is not something that happens inside Vim. Polling for changes in the system is not really something I would like to add to Vim. Bram -- would you be willing to give out a bit of code that will send a remote message to vim? Some function, perhaps SendCmd2Vim(string). That way it'll be simple for folks to make their own external programs to send a command to vim via the already available remote vim stuff. Presumably the code snippet wouldn't be a Part of Vim itself; maybe something for vim.sf.net? Just an idea... Chip Campbell
Re: Autocommand-Event for Clipboard-Changed
Yegappan Lakshmanan wrote: Are you referring to a sample code similar to the xcmdsrv_client.c file under the $VIM/tools directory? This sample code shows how to send commands to a remote Vim from a C program in Unix systems running X-Windows. A similar sample code for MS-Windows is needed. Looks like Bram is a precognitive! Yep, that's what I meant. Regards, Chip Campbell
Re: Searching for selected text
Bram Moolenaar wrote: Matt Mzyzik wrote: I don't like this one more, but it's a good alternative: g/ g? Also, I feel that one day might do something in visual; at least visual line mode. g? is already used for rot13 encoding. g/ is scheduled to be used to search inside the selected area Hmm -- g/ sounds a lot like vis.vim's :S command for searching a visual block for a pattern. It works with V, v, and ctrl-v type visual blocks. Regards, Chip Campbell
Re: no winclose event
Bram Moolenaar wrote: Charles Campbell wrote: Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would almost do, but if two or more windows are open on the same buffer, then no event. WinLeave fires whenever one changes windows, which isn't what I want, either. Unless I'm misunderstanding the help for these two events. What would this event be used for? The WinResized event has also been suggested. It could be used to update the Window layout. It will also be triggered when a window is closed, since another window will get bigger then. Would it be sufficient to only have a WinResized event? Would these events also be triggered when closing the last window of a tab page? Also, if I may point out, concerning the patch I wrote: The WinClose event took but little extra code to install. Basically, a line to define an EVENT_WINCLOSE, a line to map WinClose to EVENT_WINCLOSE, and a single apply_event() call. OTOH, the patch portion for WinResize involved several more places. As is, there'll be at least two WinResize events when a ctrl-w= (all windows equal sized) is used (one for the vertical, one for the horizontal, resize). You're bound to get someone who wants a VertWinResize and a HorzWinResize (but we can ignore s/he, right?) :) . Plus, I didn't figure out where the mouse-drag resize occurred, so that'd be yet another apply_event(). Seems like that is buried in the gui*.c code, so several drivers would be affected. Not that I'd expect that it'd take but one or two apply_event() calls in each such file. I'm just pointing out that WinClose is simpler than WinResize. BTW, what function in gui_x11.c is doing the window-resizing due to mouse dragging? Curiosity is killing me! :0 Regards, Chip Campbell
no winclose event
Hello! Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave would almost do, but if two or more windows are open on the same buffer, then no event. WinLeave fires whenever one changes windows, which isn't what I want, either. Unless I'm misunderstanding the help for these two events. Regards, Chip Campbell
Re: Convert2HTML Again
Edward L. Fox wrote:
But we should change one thing before we include this patch into the
official version. In the patch file, line 97:
+execute normal! A\npre { font-family: courier; color: . s:fgc
. ; background-color: . s:bgc . ; }\e
Should be:
+execute normal! A\npre { font-family: Courier, monospace; color:
. s:fgc . ; background-color: . s:bgc . ; }\e
As W3C suggested, every font-family indication must finish with a
*GENERIC* font family name, possible values are serif, sans-serif
or monospace. So I added monospace here.
Since there's a fair amount of anti-Courier feelings, and undoubtedly no
matter
what font is selected someone won't like it, why not set things up to
default
to whatever but to be easily overridden in one's .vimrc. In other words,
if !exists(g:Convert2Html_font)
let g:Convert2Html_font= '...whatever font gets selected for a
default...'
endif
then later, when you're about to use it:
exe norm!
A\npre{font-family:.g:Convert2Html_font.';color:'.s:fgc.';background-color:'.s:bgc.;}\e
Regards,
Chip Campbell
Re: no winclose event
Charles E Campbell Jr wrote:
Just a suggestion -- I'd appreciate a WinClose event. BufWinLeave
would almost do, but if two or more windows are open on the same
buffer, then no event. WinLeave fires whenever one changes windows,
which isn't what I want, either. Unless I'm misunderstanding the help
for these two events.
I've attached a patch. It implements WinClose and WinResize. However,
I didn't find where the resizing occurs when a mouse is used to drag a
window frame, so that's a known bug. I'd do the documentation up but
I'd like to find out if Bram is receptive first.
Regards,
Chip Campbell
*** old_fileio.cc 2006-09-25 15:28:48.0 -0400
--- fileio.c2006-09-25 15:28:51.0 -0400
***
*** 7008,7015
--- 7008,7017
{VimEnter, EVENT_VIMENTER},
{VimLeave, EVENT_VIMLEAVE},
{VimLeavePre, EVENT_VIMLEAVEPRE},
+ {WinClose, EVENT_WINCLOSE},
{WinEnter, EVENT_WINENTER},
{WinLeave, EVENT_WINLEAVE},
+ {WinResize, EVENT_WINRESIZE},
{VimResized,EVENT_VIMRESIZED},
{NULL,(event_T)0}
};
*** old_window.cc 2006-09-25 15:00:05.0 -0400
--- window.c2006-09-25 15:48:15.0 -0400
***
*** 1587,1592
--- 1587,1595
win_equal_rec(next_curwin == NULL ? curwin : next_curwin, current,
topframe, dir, 0, tabline_height(),
(int)Columns, topframe-fr_height);
+ #ifdef FEAT_AUTOCMD
+ apply_autocmds(EVENT_WINRESIZE, NULL, NULL, FALSE, curbuf);
+ #endif
}
/*
***
*** 2068,2073
--- 2071,2077
return;
# endif
}
+ apply_autocmds(EVENT_WINCLOSE, NULL, NULL, FALSE, curbuf);
#endif
/*
***
*** 4534,4539
--- 4538,4546
msg_row = row;
msg_col = 0;
+ #ifdef FEAT_AUTOCMD
+ apply_autocmds(EVENT_WINRESIZE, NULL, NULL, FALSE, curbuf);
+ #endif
redraw_all_later(NOT_VALID);
}
*** old_vim.hh 2006-09-25 14:55:08.0 -0400
--- vim.h 2006-09-25 15:27:47.0 -0400
***
*** 1138,1145
--- 1138,1147
EVENT_VIMLEAVE, /* before exiting Vim */
EVENT_VIMLEAVEPRE,/* before exiting Vim and writing
.viminfo */
EVENT_VIMRESIZED, /* after Vim window was resized */
+ EVENT_WINCLOSE, /* after closing a window */
EVENT_WINENTER, /* after entering a window */
EVENT_WINLEAVE, /* before leaving a window */
+ EVENT_WINRESIZE, /* after resizing a window */
EVENT_ENCODINGCHANGED,/* after changing the 'encoding' option */
EVENT_CURSORHOLD, /* cursor in same position for a while */
EVENT_CURSORHOLDI,/* idem, in Insert mode */
Re: Hello! Well Met! And a possible bug. :-)
Mark Manning wrote: First you have to have a lot of open and close braces (}). ..snip.. Ok. So the problem happens when you delete sub b and then hit the dd key to delete the blank line between sub a's ending close brace and where sub b's starting line was. When you do this VIM pops up onto the end of the brace for sub a. The thing is, is that the cursor isn't _on_ the close brace - it is next to the close brace. So if you then do a % VIM pops to the middle of the file rather than to the open brace like it should do. (ie: Match braces.) Like I said - it's not a terrible problem, it doesn't crash VIM, it's just a what the heck!? kind of thing and it took me a while to realize that I was not doing something myself wrong and that it had more to do with how VIM treated the deletion of the other line and where it put the cursor afterwards. ..snip.. What does :echo ve show? Regards, Chip Campbell
Re: Help non-functional in 7.0.90
A.J.Mechelynck wrote: The wierdness appeared after installing the manpageview plugin from vim-online, and disappeared after removing it as well as versions of the netrw and vimball plugins which had become older than the default ones due to a runtime rsync. Don't know what _any_ of those had to do with not finding the help; and (I checked) my doc/tags files were OK -- anyway, regenerating them all using (internal) helptags changed nothing. Well, as I've mentioned, I have no problem with the :help command, and I certainly use manpageview all the time. Manpageview doesn't have any autocmds, so its not being invoked behind your back. The latest one defines five commands: Man [HORV]Man and a map for K. Regards, Chip Campbell
Re: text is gone
scott wrote: ok, so help me out here i've looked at filetype vim, and i see nothing that associates _.txt modules with ft=txt whether i enter my 'ai' modules with the script or by navigating to where they are and, with my bloody fingers typing 'gvim ai_200609.txt', still, inside the module, filetype is undefined are we only supposed to use vim for exotic languages? is 'text' deprecated? i thought it used to suffice to have an extension of .txt now the ground is shifting under my feet... - scott wrote again: excuse me this transcends ridiculous i am editing text, and i have gone around the bend to tell vim that i am doing so to have to create an entire text syntax, where NOTHING HAPPENS, seems against every premise that vim was built on why do i have to be surprised by 'cindent' when i am editing text? it is, after all, text, and i went out of my way to define these modules with the .txt extension, even here in linux -- specifically so he'd know why would cindent kick in if i'm not editing c? now you say *.txt is associated with nothing -- that goes far to explain why my search in filetype.vim for 'txt' was so fruitless, thank you i don't remember having this problem before -- before what exactly i'm not sure -- but i've been surprised with indenting behavior enough to go out of my way to turn every indenting feature off i can find, but still i get surprises now cindent is off, maybe i can still work...tab is easy to hit... forgive me, i have no bottom line -- no idea what i'm saying -- i'll shutup now Yep, nothing associates *.txt modules with ft=txt. That's because there is no syntax/txt.vim highlighting, at least as distributed. What highlighting should be done for a non-specific, arbitrary language? Keywords? Regions? Or did you intend to mean that you used a .txt suffix to avoid syntax highlighting, filetype plugins, etc? To answer your question about cindent -- are you sure you're not setting it yourself in your .vimrc? To find out where it was last set: :verbose set cin? There's also autoindent (short form: ai). If that's on, to find out where it was last set: :verbose set ai? Perhaps you can either remove these settings from your .vimrc if that's where they're set or remove any plugins that are setting them. What do you mean by entering your ai modules with the script? Chip Campbell
Re: Fixing cweb.vim
David Brown wrote: A.J.Mechelynck wrote: David Brown wrote: What I'm having difficulty with is figuring out what to put there. Is there a way of finding out what region a given part of the buffer is in? I'm not a specialist of these matters; but try help completion on synID Well, I did figure out how to get cweb working, by adding the line: syntax cluster texFoldGroup add=webCpart to cweb.tex. I figured this out by tracing through tex.vim by hand and by finding a group that nearly everything included. I still don't know how to debug these, but at least I got things working. That's the folding support stuff. Folks wanted to have syntax-based folding for LaTeX for things like sections, subsections, chapters, etc. Hence, these things had to be in foldable regions. Glad you figured it out! Chip Campbell
Re: Netrw and cindent
Benji Fisher wrote: A quick look at netrw.vba.gz (searching for swf) suggests that this may be the problem: fun! netrw#NetBrowseX(fname,remote) [snip] if a:remote == 1 set bh=delete bt=nofile noswf exe norm! \c-o redraw! endif call Dret(NetBrowseX) endfun All the other matches for swf involve either :setlocal or :let l: . I did not see anything suspicious with cin. Thanks, Benji F! I've uploaded a netrw v103i with the latest fixes to my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs , see Network Oriented Reading, Writing, and Browsing. Regards, Chip Campbell
Re: Netrw and cindent
Mark S. Williams wrote: I think I've uncovered an odd bug involving Netrw and the cindent local buffer option for Java files, where cindent is unset under certain conditions. I'm afraid that I don't see this problem; I tried both your examples. Please try v103f from my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs , see Network Oriented Reading, Writing, and Browsing. If this problem continues to occur, then its likely some setting or other plugin is interfering (the latter most likely via an autocmd). Regards, Chip Campbell
Re: modified 1.2.6.55 Tv1
Yakov Lerner wrote: On 8/7/06, Charles E Campbell Jr [EMAIL PROTECTED] wrote: Hello! What is the message about (given on the subject line and here: modified 1.2.6.55 Tv1). I get it when I'm using tags: vi -t sometag I grepped vim source, and found that strings 1.2.6.55 Tv1 do not appear in vim sources. Word modified, at the beginning of the string/message, only appears in the name of the 'modified' option. Is it possible that these messages come from the autocommand/plugin ? (in which case -V20 will expose the source). My suggestion can be naive, but does this appear with -u NONE, too ? Can you attach the tagfile and specific tagname to reproduce it ? I tried 'vi -t sometag' in the vim sources directory, but all I get is E426: tag not found: sometag Well, I should have mentioned that I did a recursive grep for Tv1 myself, albeit in my vim/ directory and in my .vimrc, and didn't find it. However, your suggestion (let's hear one for brute force!) nailed the culprit: CVSGetLocalStatus(), from cvscommand.vim. I don't know why that function is being executed on a every attempt to jump to a tag (without going through Bob H's code). Thank you, Chip Campbell
Re: Bug: Can't select bottom window by mouse-clicking
A.J.Mechelynck wrote: Can't select bottom window by mouse-clicking Happens every time. How to reproduce: 1. :set ch=2 wmh=0 wh= don't know if relevant 2. Open at least two horizontally split windows 3. Make some window current, other than the bottom one 4. Click the bottom status line. Actual result: Nothing happens. Expected result: Bottom window should become current, as with ^Wb Additional info: - Selecting by mouse works for any window other than the bottom one. - :version output: Hello! My gvim worked as expected (ie. the window associated with the clicked on status bar became current). I did it both with my usual settings and with gvim -u NONE -U NONE -N somefile Does it still happen when you try gvim with the -u NONE -U NONE -N arguments? (I'm using Huge version with GTK2 GUI... on a FC5 linux box) Regards, Chip Campbell
Re: Gvim for KDE
Stefan Karlsson wrote: By the way, is there anyone out there that is working on a KDE version? I have tried Kyzis a bit, but didn't really like it ... As I recall, the vim7 kde port was dropped because there was no maintainer for the port. I'm not a KDE user myself, so I'm not a candidate, but perhaps if you volunteered to do KDE port+maintenance, you might be able to get it back in. Regards, Chip Campbell
Re: question for charles (or anyone): netrw whacking t
Benji Fisher wrote: I think I see the problem. In $VIMRUNTIME/autoload/netrw.vim , in the function netrw#DirBrowse() , there are the lines if fo =~ '[ta]' set fo-=t set fo-=a echohl Warning echo '***warning*** directory browsing and formatoptions ta are incompatible' echohl None endif (I am not sure that I ever get to see that warning message.) I think that replacing :set with :setlocal will fix the problem. Remember, when dealing with a local option, :set changes both the local value and the global default; :setlocal changes only the value... I think it should be :let l:spell = ... Actually, I don't want to use local settings; just obstinate, I guess! What netrw v102h does (and its available at my website, http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs as Network Oriented Reading, Writing, and Browsing) is save global settings, make them netrw-friendly, do the browsing thing, restore the settings. Regards, Chip Campbell
Re: netrw plugin bug?
Alexei Alexandrov wrote: In Vim 7, there seems to be a bug in netrw plugin behavior. It looks like it wipes out clipboard register (mine is set to unnamed). That is, I yank something in one file, then I do, say, :e ., pick up a new file, open it with Enter and try to paste the text. A space will be pasted instead of previously yanked text. Please try the latest netrw, available at my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs see Network Oriented Reading, Writing, and Browsing I keep the latest versions of netrw, albeit somewhat alpha, on my website. Regards, Chip Campbell
Re: incorrect behavior of gzip.vim plugin?
Gary Johnson wrote: I was following Chip Campbell's advice in the vim list to download v100 of the netrw plugin when I discovered the following undesirable behavior of the gzip.vim plugin. I downloaded netrw.vba.gz, then opened it with view netrw.vba.gz and saw the following messages at the bottom of the screen: netrw.vba.gz [readonly][noeol] 260L, 67511C ~/.vim/netrw.vba [readonly] 7156L, 274745C Source this file to extract it! (:so %) Press ENTER or type command to continue I took a brief look at the file, then closed vim with :q When I did an 'ls' of the directory, I discovered that netrw.vba.gz had been replaced by netrw.vba! I didn't want to unzip the file, only look at it. I believe this is an error in the behavior of the gzip.vim script. The problem here is :so % doesn't source the buffer, it sources the underlying file. Thus the file must needs be gunzip'ed first. Vimball could be set up not to gunzip the file, but then sourcing it would fail. Regards, Chip Campbell
Re: source, runtime and all that
Zdenek Sekera wrote:
I also thought 'runtime' is somehow equivalent
to :source, except it is smart enough
to use 'runtimepath'. Using the same test above
(':runtime test.vim') I found this does *not*
fire up the autocmd while :source does.
Is this intentional or can it be considered a bug?
I'd guess it was intentional. The help for :source explicitly mentions
that using it triggers the SourcePre autocommand, and nowhere in the
help for :runtime does it mention doing so. OTOH, perhaps its an oversight!
Regards,
Chip Campbell
Re: netrw, winxp, and a problem...
Steve Hall wrote: Just assume all paths are Windows-hostile unless passed through such a wrapper. (I never see these errors on *nix, so I assume it's path related.) I'll try it! The unfortunate part is, I can't test it. Or rather, I can test to see if the wrapper introduces some new problem, but as I haven't been able to duplicate the problem others are having I can't do the test. Thank you! Chip Campbell
Re: Pattern questions
Zdenek Sekera wrote:
Sorry, I should have been clearer:
Note the placement of the '+' in my pattern, somewhere
in the middle, there it doesn't cause any problem:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_+-[\]/\]'
^
| here
The erroneous (in my judgement) patterns are (e.g.) are these:
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\+]')
if (char =~ '\m[;|?:[EMAIL PROTECTED]*(){}\\_-[\]/\\+]')
So the question is why is it OK to have '+' in the middle
and not at the end?
It has nothing to do with +, and everything to do with - . The - is a
range character,
more commonly seen with something like [a-z] (which stands for all lower
case characters).
You need to escape the minus sign (ie. \-).
Regards,
Chip Campbell
Re: [EMAIL PROTECTED]: vim7: formatoptions]
Benji Fisher wrote: Did you notice this thread on vim-dev? - Forwarded message from Thomas [EMAIL PROTECTED] - To: vim-dev@vim.org From: Thomas [EMAIL PROTECTED] Subject: vim7: formatoptions Date: Fri, 19 May 2006 13:48:51 +0200 I just realized that editing a directory removes t from formatoptions. E.g. set formatoptions+=rw fo = tcqrw e Foo fo = tcqrw e . fo = cqrw e Bar fo = cqrw This doesn't happen with the --noplugin switch so I'd assume that some standard vim plugin is causing this -- maybe netrw? Can somebody verify this? Netrw attempted to issue a warning about this problem, but apparently it gets wiped out before being seen. These two settings were problematical; I originally caught them as causing problems with the pluginkiller. The problem: netrw would hang. Anyway, I think I've worked around the two settings (fo=...ta...). Now, I must admit that I haven't done a comprehensive test of netrw and all its features with these two settings active. Please try the netrw v100j from my website: http://mysite.verizon.net/astronaut/vim/index.html#VimFuncs , see Network Oriented Reading, Writing, and Browsing. Regards, Chip Campbell
Re: netrw, winxp, and a problem...
A.J.Mechelynck wrote: Charles E Campbell Jr wrote: Hello, Tony! I've had several folks having a problem with WinXP and netrw. The problems seem to involve temporary files during attempts to use ftp; since temporary filenames are produced by tempname(), they're o/s dependent. Admittedly without having searched the source, I figure that these temporary files are in fact produced by the C function tmpnam() -- hmm, I did just do that search, and tmpnam() is used. Since that's a C-library function, these temporary files are presumably not only o/s dependent but compiler dependent. I generally compile my own vim using cygwin+gcc for Windows. I've never seen the problems these folks are having. So, last night I downloaded a copy of your compiled vim (7.0aa, perhaps patched to 213? - I don't recall exactly). I also installed my latest netrw, and used it in a dos (cmd.exe) window, and furthermore used vim -u NONE (also, set nocp and :so ..path-to-netrwPlugin.vim). I was hoping to finally see these problems, but I still was able to do remote browsing, readwrite and NreadNwrite without any problems. So, have you had any issues with remote browsing/ftp with netrw? Do you have any suspicions as to what the problem might be? What compiler do you use? Thank you, Chip Campbell Sorry, Dr. Chip, I can't help you there so I'm referring you to the vim-dev list: 1. As a rule, I don't edit over ftp, I edit my files locally and, when I'm satisfied with the result, I upload them with any available ftp client. If I want to make sure that my files look all right, I browse them with my favourite web browser (both locally with file: and remotely with http: or ftp; ) In essence, that's what netrw supports. Creation and opening of a temporary zero-length file with a unique name in a given directory is a well-documented system call on Dos-like systems; I wouldn't expect it to be compiler-dependent since the OS explicitly provides it. (I'm not familiar with specific Windows calls but there is a Dos system call for it since Dos 3 or maybe earlier.) I believe that cygwin does it differently, but even so, there's a possible compiler dependency concerning which directory the temporary file is made. If it works OK with your latest version of netrw, then maybe the trouble is that the version of netrw distributed with Vim 7.0 is _not_ the latest one? The latest is v100j, which I've just uploaded to my website. The distributed version is, alas, always likely to not be the latest one, except for a short window of time... Thank you, Chip Campbell
gvim + X + geometry + set line + cttrl-f + folding (whew!) : a bug
Hello! This one appears to be a ctrl-f (and ctrl-b) bug. Here's the setup: (using Linux,vim-7.0g, huge) .vimrc : set nocp .gvimrc : set lines=21 no .vim/ directory. Now, for the problem: gvim -geometry 139x22+0+4 netrw.vim 11jspace zcr 4jspace6k4j ctrl-f Note that the ctrl-f does not advance a page; instead, the cursor returns to the top line (which is a fold). Similar misbehavior happens with a ctrl-b. I have to use hit ctrl-e several times to move the folds off the top; then, ctrl-f works again. Regards, Chip Campbell
Re: Vim thinks a directory is an illegal filename on Windows
William S Fulton wrote: run: gvim . on Windows at bottom it will say, eg: C:\ Illegal file name on Solaris and Linux at the bottom it will say, eg: . is a directory The Unix message is less confusing. Can this for Windows versions as it still occurs in vim7.0f? Same message appears when doing :new . I haven't found any way to avoid these messages with netrw, so it sounds like an issue for Bram M. Regards, Chip Campbell
Re: probably known bug
[EMAIL PROTECTED] wrote: All, I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? Well, this one is more of a trade-off than a bug (speed vs accuracy). I suggest reading: :help syn-sync . Regards, Chip Campbell
Re: probably known bug
[EMAIL PROTECTED] wrote: On Fri, Apr 28, 2006 at 04:08:32PM +0200, Nikolai Weibull wrote: On 4/28/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I found a bug related to syntax highlighting, although I wouldn't be surprised if people already know about this. Simply, the syntax highlighting sometimes gets messed up and I have to refresh the window (with c-l) in order make the highlighting correct again. I have been experiencing this for a while. Is there an effort to fix this? The syncing could probably be better, but this problem is sometimes unavoidable. Knowing what filetype the problem occurs for would help in investigating the issue further. I don't know if sometimes it's unavoidable, but definitely sometimes it is avoidable. In my experience, it happened probably at least once with every filetype I've worked with. Just off the top of my head, it happened yesterday in a JSP file, and later in a Perl file. And it seems to happen a lot in HTML files. Well, I see a number of syn sync statements in syntax/html.vim, so Claudio Feiner has certainly tried to help out with this. Nick Hibma with perl, too. syntax/jsp.vim doesn't have any synchronization; probably the htmlTag and jspCommand regions therein could use them. Contact Rafael Garcia-Suarez about it. On your end, you could increase your syn sync minlines parameter (see :help syn-sync-minlines). Regards, Chip Campbell
Re: :for var in list
James Vega wrote: On Tue, Apr 25, 2006 at 02:21:07PM -0400, Charles E Campbell Jr wrote: I know this is a late date, but I think it would be helpful if for var in list ... endfor would complete with var= . For example where this might come in handy: for home in split(rtp,',') if isdirectory(home) | break | endif endfor This seems like a rather arbitrary imposition. There could be legitimate reasons for var getting the value in a loop (such as looping over the results from matchlist()) which would be confused by adding an additional loop with var = . I'm afraid I don't understand what you mean about adding an additional loop; I don't see where having the home variable take on an empty meaning (whether or []) when the loop terminates would have much to do with any additional loop. Its true that an any empty condition could be legitimately in a list, though. It still might be handy to have a standard setting (such as or []) at end-of-for-loop without a break. Regards, Chip Campbell
Re: :for var in list
Bram Moolenaar wrote: Charles Campbell wrote: I know this is a late date, but I think it would be helpful if for var in list ... endfor would complete with var= ... This for loop is like it is in Python, and it has proven to be very useful. It's easy to add something to the list if you want to loop over more things. E.g.: for home in split(rtp,',') + [''] if isdirectory(home) | break | endif endfor Looks like a good way to do it. Haven't used Python myself; probably will learn more Python using Vim's 7.0 language! Thank you, Chip Campbell
Re: netrw needs more keepjumps?
Hari Krishna Dara wrote: On Thu, 20 Apr 2006 at 9:58am, Charles E Campbell Jr wrote: Please try setting g:netrw_fastbrowse=0 in your .vimrc. Hopefully the jumplist will then be retained. Did you mean the value 2? Whoops -- yes, I meant 2. If you want the jumplist to work, you need places to jump to, which in turn means cached buffers. That's the way that netrw used to always work; the fastbrowse stuff is relatively recent, and to implement it netrw deliberately wipes out netrw buffers that aren't being currently displayed. So, its a trade-off for users to make. Hidden (ie. :ls won't display netrw buffers), but available, thereby making fast re-displays of previously seen directory listings. Also makes the jumplist useful. Versus: re-acquisition of a directory listing every time a directory is entered, so netrw's directory listing is up-to-date as of the display time (cursor leaving/entering will also cause netrw to update browser displays), but the jumplist is forgetful. Regards, Chip Campbell
Re: netrw 'filetype'
Hari Krishna Dara wrote: I am wondering if we can have netrw set the 'ft' of the buffer to 'netrw' at the end of generating the directory listing... Its already netrwlist; I named it that quite awhile ago so as to reduce the danger that someone might move syntax/netrw.vim atop plugin/netrw.vim. It seems like it'd be better for it to simply be netrw, so I'll do that. Couple of other comments about netrw: - In the vim7 beta2, netrw seems to generate bunch of 1 more line messages (I have report=0). Can we put a :silent in front of those lines that add lines, please? - The loaded_netrw variable is set to say v52, but it will be much easier to do version checks if it is just a number, such as 52. I don't see any benefit of prefixing the number with a v. Hmm --- I sent netrw v87 to Bram yesterday, and I've got a v88b that I've uploaded to my website. That b, by the way, shows one reason why the version isn't simply a number. Another reason: I have scripts that automatically update my website with the latest ASTRO-ONLY versions of my scripts, including updating the release version number shown on the website. Its safer to have that 'v\d\+\a*' pattern for such automated updating. Doing version checks just simply means doing the removal of the leading v and then comparing. (strpart(), substitute(), etc). Vim 7 beta2 has a much more recent version of netrw than v58. Do you happen to have an older netrw hanging around in your plugin directory? The newer netrw's work better with report=0. Regards, Chip Campbell
Re: netrw 'filetype'
Hari Krishna Dara wrote: This is exactly the reason, I didn't suspect this at all. I had netrw in my plugin directory for use with 6.3 Vim. Now, how do I make sure I can use the same plugin directory for both 6.3 and 7.0? I think the g:loaded_xxx variable should be different for these two so that we can control them independently. Since it took the role of explorer plugin in 7.0, how about using the loaded_explorer instead of loaded_netrw in 7.0 (unless there is a better solution)? Vim 7.0 introduces the notion of autoload -- basically only a small skeleton of code, generally just the user interface commands and maps, is present in the plugin. However, the commands and maps defined therein can call upon functions with the format funcfile#Function(...) If the function hasn't been loaded yet, then Vim 7.0 will attempt to source it in from the system's or user's autoload/ directories, using funcfile.vim to do so. Thus the user gains full functionality without having to pay a startup price by loading everything whether or not it gets used this time around. One problem: vim 6.x not only doesn't understand this, it complains about it. Hence, vim7.0 can understand and use vim6.x (and earlier) plugins, but plugins using vim 7.0's autoload will be incompatible with vim 6.x. Bottom line: there's no point. Netrw, now a vim 7.0 autoload-using plugin, just isn't compatible with 6.x. Attempts to use vim 6.x with 7.0-plugins is going to result in lots of errors. Regards, Chip Campbell
