Re: breakindent, take 2
On 5/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 5/29/07, Nico Weber <[EMAIL PROTECTED]> wrote: > > What do you think? I prefer (c) from implementation, efficiency and > > intuitivity perspective. > > I agree. Strongly. Yes, I agree with (c) , too. I suggested once new type of options to vim that behaved both like boolean, and numeric. But Bram rejected this. It's a pity because this would make for lesser number of options. Actually, the options that would be three-way boolean, and string, and numeric would be even better. An afterthought. A string-typed 'breakindent' option could work, too. Empty value=off, 0=on, +n, -n. Another advantage of string option is that you can add additional flags to it later, without multiplying number of new options ( a-la 'compatible', 'viminfo', 'giooptions' bag-of-flags ). Bram is always reluctant to add new options, so this can be a consideration. Yakov
Re: breakindent, take 2
On 5/29/07, Nico Weber <[EMAIL PROTECTED]> wrote: > What do you think? I prefer (c) from implementation, efficiency and > intuitivity perspective. I agree. Strongly. Yes, I agree with (c) , too. I suggested once new type of options to vim that behaved both like boolean, and numeric. But Bram rejected this. It's a pity because this would make for lesser number of options. Actually, the options that would be three-way boolean, and string, and numeric would be even better. Yakov
Re: Proposal: adding an extra hook into vim's search
On 5/28/07, Iain Murray <[EMAIL PROTECTED]> wrote: On 26/05/07, Iain Murray <[EMAIL PROTECTED]> wrote: > On 26/05/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > I believe you can achieve what you want using 'cmap ' cleverly. ... > I might still attempt a patch. Having the space replacement actually > appear is visually distracting and makes the resulting search string > hard to read. Having had a more detailed look at the code I'm bailing out of attempting this for now. Making the search history still work and be uncluttered of '\_s\+' seems fiddly. The natural way to do this seems to be making the magic types more flexible. The changes would be somewhat further reaching than I had initially anticipated and I wouldn't be happy doing it without there being consensus out there on a specification. Thanks again Yakov for the partial fix. I believe you can have uncluttered view of the regex AND incremental search at the same time using getchar() in vimscript, but that would be tons of vimscript programming. Yakov
Re: breakindent, take 2
On 5/14/07, Václav Šmilauer <[EMAIL PROTECTED]> wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-dev&m=109921292009721&w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the "ml_get(): invalid line number" error. I think it is caused by passing wrong line number thgouth the *chartabsize* & family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. I played with the patch. Works smoothly, I did not find any deficiencies. I have one wish though. It would be nice if I could specificy additional indent for continuation lines. You make indent for continuation line *EQUAL* to indent of the 1st screen line. Let's say you have 3 consequitive long lines with same indent, and each lines wrapped into 4 screen lines. With current 'breakindent' patch, you see 8 lines with *same* indent. It's not that easy to see beginning of each long lines. If breakindent would be numeric value N which meant assign indent K+N to continuation indent, where K is indent of the line itself. Current breakindent corresponds to N==0. But I'd probably prefer N=1 or N==2. Just my 2 cents Thanks Yakov ** nobreakindent line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=0 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line ** breakindent=2 line1line1line1line1 line1line1line1line line2line2line2line2 line2line2line2line **
Re: breakindent, take 2
On 5/14/07, Václav Šmilauer <[EMAIL PROTECTED]> wrote: Hello, I submit patch that implements the 'breakindent' feature. It is on vim todo list, since the moment I tried a few years ago (see e.g. http://marc.info/?l=vim-dev&m=109921292009721&w=1). Picture says what it's about (showbreak is aligned with first non-whitespace): http://beta.arcig.cz/~eudoxos/vim7/breakindent1.png http://beta.arcig.cz/~eudoxos/vim7/breakindent2.png I tried to address all Bram's comments he had to the original patch, like coding style, functionality in diff mode, selections etc. I had to change a few prototypes to pass line number. There is one bug and some (easily fixable) limitations: * BUG: there is some weird interaction with quickfix window, where very rarely there is the "ml_get(): invalid line number" error. I think it is caused by passing wrong line number thgouth the *chartabsize* & family routines (line in the main buffer interpreted as line in the quickfix window or something like that), but I am not sure. * No test case. This will be added once there is enough interest from developers (there _is_ documentation). * The bri_min variable is not exposed to userspace yet, is set to 20 in the code. If the rest is considered ready for inclusion, I will add a user-serrable variable for that. The patch is against current svn (vim7, rev. 288). Any comments are welcome. Nice feature. I hope Bram includes it. Yakov
Re: Proposal: adding an extra hook into vim's search
On 5/26/07, Iain Murray <[EMAIL PROTECTED]> wrote:
Hi,
Searching for "hello world" in vim doesn't match "hello\nworld".
This is annoying when editing documents. The solution is to
search for "hello\_sworld". But it is frustrating to type \_s
instead of a space in every search.
I have been getting around this by calling my own search function
(appended at the very end of this email). This issue has also
been discussed before:
http://bugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=256743
and the solution then was to use a vim-script function too.
The problem with vim-script hacks is that they do not provide
incremental searching. I often find myself doing an incsearch,
having it fail and then having to try again with my own search
function. It might be possible to re-implement incsearch in
vim-script, but why reinvent the wheel? I think it would be
better if I could hook into vim's existing interactive search
mechanisms. For reference, emacs has an option to change the
meaning of ' ' in its incremental regex search (obtained with
M-C-s), the option is set in .emacs with
(setq search-whitespace-regexp "[ \t\r\n]+")
I intend to write a patch for vim, if only for my own use. It
seems that I could do one of a few things:
- add an option to allow search strings to be filtered
through an arbitrary user function before being used
- add a string option that would replace ' ' in searches.
- add a Boolean option which offers one specific line-break
ignoring behaviour.
- extend the behaviour of the magic option (how?)
Which (if any) of these is likely to be adopted?
Perhaps these lines in doc/todo.txt are relevant? I don't really
understand them:
From xvim: Allow a newline in search patterns (also for :s,
can delete newline). Add BOW, EOW, NEWL, NLORANY, NLBUTANY,
magic 'n' and 'r', etc. [not in xvim:] Add option to switch
on matches crossing ONE line boundary.
Can anyone tell me what xvim is, what the acronyms stand for and
what the reference to magic options means?
Thanks for your time,
Iain.
" This is the search function I have been using:
function! MySearch()
let l:str = input('/')
let l:str = substitute(l:str," ",'\\_s\\+',"g")
let @/ = l:str
call histadd('/',l:str)
call search(l:str)
endfunction
I believe you can achieve what you want using 'cmap ' cleverly.
Does this following do what you want ? You toggle special behaviour
of space in searching with F2, and you have incsearch, too.
Special-space is off in the following example, you can make it on
by inclugint this line: call ToggleSpecialSpaceSearch()
" to set ;special space in search' on by default, do this:
" call ToggleSpecialSpaceSearch()
nnoremap :call ToggleSpecialSpaceSearch()
cnoremap (ToggleSpecialSpaceSearch())
func! ToggleSpecialSpaceSearch()
if exists('g:my_search') && g:my_search
cunmap
let g:my_search=0
echo 'space in search normal'
else
cnoremap
(getcmdtype()=='/'\|\|getcmdtype()=='?'?'\_s\+':' ')
let g:my_search=1
echo 'space in search special'
endif
return ''
endfun
Yakov
Re: A performance question (patch included)
On 5/25/07, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
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
Re: A performance question (patch included)
On 5/25/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Charles E Campbell Jr wrote: > 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 > 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? stat() on Linux has 32-bit st_size field (off_t is 32-bit). There is stat64() syscall which uses 'struct stat64' structure where st_size is 64-bit. By defining __USE_LARGEFILE64 at compile-time, stat() is redirected to stat64(). I don't know whether default Linux vim build defines __USE_LARGEFILE64 or not. Yakov
Re: Wish: col("^")
On 5/21/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
... get position of first non-blank character in the line.
If there is col("$"), there should also be col("^").
In some situations (e.g. :imap )
:normal ^
is not allowed.
... but you can call your function, remember position/columns,
do ':normal ^', get column, restore position, return the columns of the ^ ?
Yakov
Re: [Announcement] Subversion repository location changed
On 5/9/07, Edward L. Fox <[EMAIL PROTECTED]> wrote: If you had checked out a copy of the sources before, please run this command in your source root directory to switch into the current branch: svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 This switch command gives me error: $ cd vim7 $ svn info Path: . URL: https://svn.sourceforge.net/svnroot/vim/vim7 Repository Root: https://svn.sourceforge.net/svnroot/vim Repository UUID: 2a77ed30-b011-0410-a7ad-c7884a0aa172 Revision: 263 Node Kind: directory Schedule: normal Last Changed Author: edyfox Last Changed Rev: 263 Last Changed Date: 2007-05-06 23:13:56 -0400 (Sun, 06 May 2007) $ svn switch https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1 svn: 'https://vim.svn.sourceforge.net/svnroot/vim/branches/vim7.1' is not the same repository as 'https://svn.sourceforge.net/svnroot/vim' What am I doign wrong ? Yakov
Re: Vim version 7.1a BETA -- runtime files ?
On 5/8/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: Full diffs are attached. Diffs are produced by the script diff-vim-ftp-svn.sh, also attached. Re-sending attachments which came out zero-length in previous email. Yakov diffs Description: Binary data diff-vim-ftp-svn.sh Description: Bourne shell script
Re: Vim version 7.1a BETA -- runtime files ?
On 5/8/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 5/5/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Announcing: Vim (Vi IMproved) version 7.1a BETA > > I compared runtime files form ftp [1] and from svn [2]. > Both vims are labeled vim71a. But many runtimes are different. > In svn, many files are labeled 2007. In ftp, they are 2006 versions. > Why this difference in runtimes ? > > Yakov > [1] ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 > [2] https://svn.sourceforge.net/svnroot/vim/vim7 Do I need to hunt down the differences? Please give a specific example. What "label" are you talking about? At closer examination, differences turned out to be in $Id..$, $Revision..$ $Date...$ lines only, except for one file which has read differences: runtime/autoload/spellfile.vim -- see diffs below. By "labels" I meant the cvs $Id...$ keywords and other $..$ keywords. Full diffs are attached. Diffs are produced by the script diff-vim-ftp-svn.sh, also attached. diff -r --exclude=.svn /var/tmp/vim-untar/vim71a/runtime/autoload/spellfile.vim /var/tmp/vim-svn/vim7/runtime/autoload/spellfile.vim 3c3 < " Last Change:2006 Aug 29 --- " Last Change:2007 May 06 60a61 " Remember the buffer number, we check it below. 61a63 let newbufnr = winbufnr(0) 67c69,88 < g/^/d --- " Careful: Nread() may have opened a new window for the error message, " we need to go back to our own buffer and window. if newbufnr != winbufnr(0) let winnr = bufwinnr(newbufnr) if winnr == -1 " Our buffer has vanished!? Open a new window. echomsg "download buffer disappeared, opening a new one" new setlocal bin else exe winnr . "wincmd w" endif endif if newbufnr == winbufnr(0) " We are back the old buffer, remove any (half-finished) download. g/^/d else let newbufnr = winbufnr(0) endif 73c94 < bwipe! --- exe newbufnr . "bwipe!" 99,101c120 < if getline(2) !~ 'VIMsug' < echo 'Sorry, downloading failed' < else --- if getline(2) =~ 'VIMsug' 103a123,136 set nomod else echo 'Sorry, downloading failed' " Go back to our own buffer/window, Nread() may have taken us to " another window. if newbufnr != winbufnr(0) let winnr = bufwinnr(newbufnr) if winnr != -1 exe winnr . "wincmd w" endif endif if newbufnr == winbufnr(0) set nomod endif 105d137 < set nomod 109c141,142 < bwipe --- " Wipe out the buffer we used. exe newbufnr . "bwipe" diffs Description: Binary data diff-vim-ftp-svn.sh Description: Bourne shell script
Vim version 7.1a BETA -- runtime files ?
On 5/5/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I compared runtime files form ftp [1] and from svn [2]. Both vims are labeled vim71a. But many runtimes are different. In svn, many files are labeled 2007. In ftp, they are 2006 versions. Why this difference in runtimes ? Yakov [1] ftp://ftp.vim.org/pub/vim/unstable/unix/vim-7.1a.tar.bz2 [2] https://svn.sourceforge.net/svnroot/vim/vim7
Re: Vim version 7.1a BETA -- svn ?
On 5/6/07, Martin Krischik <[EMAIL PROTECTED]> wrote: Am Sonntag 06 Mai 2007 schrieb Yakov Lerner: > On 2007-05-05, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Announcing: Vim (Vi IMproved) version 7.1a BETA > > I tried to build vim7.1 from svn. But all I get from usual > svn location (https://svn.sourceforge.net/svnroot/vim/vim7), is > vim 7.0.236. Will vim7.1 be served at this localtion eventually ? That is probalby because the svn server is a mess. I have to disagree. The svn maintainer does valuable service to the community. The svn service is really stable, unlike the cvs server. I'd like to really thank the svn updater for keeping the svn updated. The reason why updates did not make it to svn was that cvs server was down, as Bram explained above. Yakov
Vim version 7.1a BETA -- svn ?
On 2007-05-05, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Announcing: Vim (Vi IMproved) version 7.1a BETA I tried to build vim7.1 from svn. But all I get from usual svn location (https://svn.sourceforge.net/svnroot/vim/vim7), is vim 7.0.236. Will vim7.1 be served at this localtion eventually ? Thanks Yakov
Re: wish: show search progress on slow searches
On 5/1/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 4/30/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > [This is development, removed the Vim maillist] > > Yakov Lerner wrote: > > > On 4/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > > On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > > > Yakov Lerner wrote: > > > > > > > > > Wish: when search is slow, show the progress line number > > > > > every second on the bottom line (like, 12345 of 9). > > > > > > > > What is slow? > > > To my taste, when something takes longer than 1-2 sec, > > > I'd prefer some visual feedback on the progress. > > > > > > > Checking if the second passed will make the search even slower. > > > > Checking time is quite slow on some systems (the check for CTRL-C > > > > suffers from this). > > > > > > Checking for time every several hundred (N) lines will probably not slow > > > the search perceptibly. N can be configurable, a parameter. > > > Some value between 10 and 1000 will probaby be reasonable. > > > > I think it's possibe to check for time, which searching, not too > > often and not too seldom, even without user-defined parameter. > > Adaptive algorithm with two counters will find the right rate or > > time-checking: > > > > - as we start search, we check time every 50 lines > > (N=50 is initial value of N). We maintain counter M. M is how > > many times we called time() between the seconds changed. > > M is checked and reset every second. M is checked as folllows: > > > > - If M is too high (M>10), then we adjust N by increasing it. > > If M is too low(M<10), then we adjust N by decreasing it. Ideally, > > we want to check time() ~10 times per second. (overhead of 10 > > calls to time() per second cannot he high, right ?) > > > > - if search progresses for several seconds, then N quickly converges > > to the "ideal" value (~10 checks/sec). > > > > - we start every search with same value of N (say, 50). If search > > is slow, then N will quickly converge to the "ideal" value for this regex, > > the value in which where time() is checked ~10 times per second. > > It will help for differences in speed for various patterns, but it won't > help for lines differing in length. Quite a few patterns with wildcards > depend on the line length a lot. > > It might work better to adjust to the delay caused by the time > function. This varies greatly between systems. When it's fast we can > check the time often, when it's slow it delays the search more and > should be called less often. How about using SIGALRM when search is progressing, every second ? SIGALRM handler would store time() into global var (and reload alarm(1)). The search would check the global var for changes, every line. It is cheap to check global integer (time_t) var, no ? What do you think about SIGALRM, Bram ? Yakov
Re: [patch] search() flag to not use smartcase
On 5/3/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > The patch adds flag to search() flag to not use smartcase. > '*' and '#' do not use smartcase, but search() always uses smartcase > (cannot be turned off). > When we use search() with @/ pattern that comes from * or #, > search() fails because of discrepancy in smartcase handling. > > Yakov > > --- runtime/doc/eval.txt.0002007-05-03 09:35:19.0 -0400 > +++ runtime/doc/eval.txt2007-05-03 09:36:21.0 -0400 > @@ -4086,6 +4086,7 @@ > 'n' do Not move the cursor > 'p' return number of matching sub-pattern (see below) > 's' set the ' mark at the previous location of the cursor > + 'S' do not use smartcase > 'w' wrap around the end of the file > 'W' don't wrap around the end of the file > If neither 'w' or 'W' is given, the 'wrapscan' option applies. Looks a bit inconsistent. Why not also add a flag to ignore 'ignorecase' and 'magic'? Yes. After I sent out a patch, I realized I can fix my problem by saving,clearing, and restoring the 'smartcase' option. Sorry. Yakov
[patch] search() flag to not use smartcase
The patch adds flag to search() flag to not use smartcase. '*' and '#' do not use smartcase, but search() always uses smartcase (cannot be turned off). When we use search() with @/ pattern that comes from * or #, search() fails because of discrepancy in smartcase handling. Yakov --- runtime/doc/eval.txt.0002007-05-03 09:35:19.0 -0400 +++ runtime/doc/eval.txt2007-05-03 09:36:21.0 -0400 @@ -4086,6 +4086,7 @@ 'n' do Not move the cursor 'p' return number of matching sub-pattern (see below) 's' set the ' mark at the previous location of the cursor + 'S' do not use smartcase 'w' wrap around the end of the file 'W' don't wrap around the end of the file If neither 'w' or 'W' is given, the 'wrapscan' option applies. --- src/eval.c.000 2007-05-03 09:07:52.0 -0400 +++ src/eval.c 2007-05-03 09:34:50.0 -0400 @@ -13813,6 +13813,7 @@ case 'b': dir = BACKWARD; break; case 'w': p_ws = TRUE; break; case 'W': p_ws = FALSE; break; + case 'S': no_smartcase = TRUE; break; default: mask = 0; if (flagsp != NULL) switch (*flags)
Re: wish: show search progress on slow searches
On 4/30/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: [This is development, removed the Vim maillist] Yakov Lerner wrote: > On 4/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > Yakov Lerner wrote: > > > > > > > Wish: when search is slow, show the progress line number > > > > every second on the bottom line (like, 12345 of 9). > > > > > > What is slow? > > To my taste, when something takes longer than 1-2 sec, > > I'd prefer some visual feedback on the progress. > > > > > Checking if the second passed will make the search even slower. > > > Checking time is quite slow on some systems (the check for CTRL-C > > > suffers from this). > > > > Checking for time every several hundred (N) lines will probably not slow > > the search perceptibly. N can be configurable, a parameter. > > Some value between 10 and 1000 will probaby be reasonable. > > I think it's possibe to check for time, which searching, not too > often and not too seldom, even without user-defined parameter. > Adaptive algorithm with two counters will find the right rate or > time-checking: > > - as we start search, we check time every 50 lines > (N=50 is initial value of N). We maintain counter M. M is how > many times we called time() between the seconds changed. > M is checked and reset every second. M is checked as folllows: > > - If M is too high (M>10), then we adjust N by increasing it. > If M is too low(M<10), then we adjust N by decreasing it. Ideally, > we want to check time() ~10 times per second. (overhead of 10 > calls to time() per second cannot he high, right ?) > > - if search progresses for several seconds, then N quickly converges > to the "ideal" value (~10 checks/sec). > > - we start every search with same value of N (say, 50). If search > is slow, then N will quickly converge to the "ideal" value for this regex, > the value in which where time() is checked ~10 times per second. It will help for differences in speed for various patterns, but it won't help for lines differing in length. Quite a few patterns with wildcards depend on the line length a lot. It might work better to adjust to the delay caused by the time function. This varies greatly between systems. When it's fast we can check the time often, when it's slow it delays the search more and should be called less often. How about using SIGALRM when search is progressing, every second ? SIGALRM handler would store time() into global var (and reload alarm(1)). The search would check the global var for changes, every line. It is cheap to check global integer (time_t) var, no ? Yakov
Re: wish: show search progress on slow searches
On 4/29/07, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Yakov Lerner wrote: > > > Wish: when search is slow, show the progress line number > > every second on the bottom line (like, 12345 of 9). > > What is slow? To my taste, when something takes longer than 1-2 sec, I'd prefer some visual feedback on the progress. > Checking if the second passed will make the search even slower. > Checking time is quite slow on some systems (the check for CTRL-C > suffers from this). Checking for time every several hundred (N) lines will probably not slow the search perceptibly. N can be configurable, a parameter. Some value between 10 and 1000 will probaby be reasonable. Yakov I think it's possibe to check for time, which searching, not too often and not too seldom, even without user-defined parameter. Adaptive algorithm with two counters will find the right rate or time-checking: - as we start search, we check time every 50 lines (N=50 is initial value of N). We maintain counter M. M is how many times we called time() between the seconds changed. M is checked and reset every second. M is checked as folllows: - If M is too high (M>10), then we adjust N by increasing it. If M is too low(M<10), then we adjust N by decreasing it. Ideally, we want to check time() ~10 times per second. (overhead of 10 calls to time() per second cannot he high, right ?) - if search progresses for several seconds, then N quickly converges to the "ideal" value (~10 checks/sec). - we start every search with same value of N (say, 50). If search is slow, then N will quickly converge to the "ideal" value for this regex, the value in which where time() is checked ~10 times per second. Yakov
Re: wish: show search progress on slow searches
On 4/29/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > Wish: when search is slow, show the progress line number > every second on the bottom line (like, 12345 of 9). What is slow? To my taste, when something takes longer than 1-2 sec, I'd prefer some visual feedback on the progress. Checking if the second passed will make the search even slower. Checking time is quite slow on some systems (the check for CTRL-C suffers from this). Checking for time every several hundred (N) lines will probably not slow the search perceptibly. N can be configurable, a parameter. Some value between 10 and 1000 will probaby be reasonable. Yakov
Re: vim 7.1?
The svn tree has all patches already inside, it does not matter how many patches are there. You just checkout and build. It's not that you need to download baseline and then 222 patches, no. Yakov On 4/27/07, Jonathan Smith <[EMAIL PROTECTED]> wrote: With the insane number of patches collecting against 7.0, and presumably the new features accumulating in the devel tree, is anyone thinking about when a 7.1 release might be made? -smithj
Re: coredump with match by lines-range (7.0.222); highlighting is not painted fully.
On 4/24/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Multi-line matches are not always displayed correctly. A match is searched for in the line where redrawing starts, which can be anywhere. Your pattern only matches when redrawing starts at or before line 4078. Maybe we need a pattern that matches at line >=N and at line <=N then ? (say \%123>l \%123
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote: On Tue, Apr 24, 2007 at 05:49:19PM +0200, Nikolai Weibull wrote: > On 4/24/07, Gregory Seidman <[EMAIL PROTECTED]> wrote: > >On Tue, Apr 24, 2007 at 10:49:49AM +0300, Ilya Sher wrote: > >> Robert Lee wrote: > >> [snip] > >> > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe > >> > using SpiderMonkey) so that people don't need to learn a new language > >> If I understand you correctly, you assume that > >> ECMAScript is the most popular language among > >> the people that wish to customize VIM. How > >> do you know the assumption is right? > >> [snip] > > > >Actually, I like the proposal for two entirely different reasons: > > > >1) the language specification comes from an international standards body > > So? In what way does this make it a good language? In what way does > this make it a good language to extend Vim with? Anyone can write a > standard. It doesn't mean that it's good or what is being > standardized will be, either. Where did anyone say that standardization made it a better language than any other? Most of what makes it a good language has been there since the earliest JavaScript implementations. Many of the issues that have made it difficult to work with in the past have been hammered out during standardization or were API issues rather than language issues. But even that isn't what standardization buys you. The main advantage is interoperability. If someone writes some excellent library for use in some Flash app, but is of use in some other environment that provides ECMAScript extension, you can just copy it over and use it. I'm capable of porting an algorithm in one language I know to another language I know, but that's a bit more work than copy and paste. > >2) there are lots of people working on efficient implementations, at least > > two of which are open source (SpiderMonkey and Adobe's Tamarin, though > > there seem to be some plans to convert SpiderMonkey to use Tamarin) > > SpiderMonkey is a terribly inefficient implementation, which is why > Tamarin will be used in future versions of Gecko. And I wouldn't say > that efficiency is the primary concern of a language/runtime engine to > use for Vim. I strongly disagree with that statement. Efficiency is certainly important for an editor. I don't want to sit and twiddle my thumbs while vim starts up or executes hooks on file read, nor do I want it to suck up a big chunk of memory while it's going about its business. In fact, what I'm asking it to do currently rarely takes much time, but it could be really nice to ask it to do a lot more and still not pay a huge time or memory penalty. Efficiency is definitely important. > >It is looking more and more like the world of scripting languages for > >application extension (as opposed to standalone scripting languages) is > >converging on ECMAScript and Lua, particularly for interactive apps. > > I'm sure Microsoft agrees with this sentiment. What does Microsoft have to do with anything? > >There's a lot to be said for following a path that leads to > >interoperability and code reuse. > > Yeah, follow-the-leader is everyone's favorite game. And just look at > all the libraries for both these languages. Application extension may > sometimes be restricted to the domain of the actual application, but > having an abundance of libraries certainly opens up for more > interesting possibilities. Vim already has Perl, Python, and Ruby interpreters for application extension, assuming you build it with the appropriate options. Any library available for any of these languages can be made available to the Vim runtime with minimal hassle. Are there lots of VimScript libraries that are outside the application domain? So how does replacing VimScript with ECMAScript prevent these interesting possibilities? Cool down. "vimscript replacing with EcmaScript" is not on the horizon, is not on the agenda, not going to happen. The only alternative to vimscript that Bram once contemplated was python, and it was decisively voted down by feature voting. (Python was considered at one point by Bram because Python is Bram's favourite language.) So do not worry, replacement of vimscript by the favourite language of some vim's random user is not going to happen. Yakov
Re: wish: allow a: in the function def
On 4/24/07, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 4/24/07, Andy Wokula <[EMAIL PROTECTED]> wrote:
> Thomas schrieb:
> > So maybe one could make vimscript search a variable foo as l:foo, a:foo,
> > (maybe also: w:foo, b:foo), s:foo, g:foo, and then throw an undefined
> > variable name error if none exists. Or so.
> Don't like the idea.
> In Vim script there is no need or possibility to declare variables.
> Now, if I forget to init a fun-local variable (happens often to me)
> Vim gives me a helpful error ("undefined variable").
And I have the same problem with a: prefixes for my arguments. Fine,
keep prefixes for g:, w:, and b:, but a: is just such an incredibly
nonstandard way of doing things.
In almost all languages parameters are treated the same as local variables.
"almost all languages" ? totally untrue. This is only true for in C
(and descendants).
Besides C and descentants, no other language treats function parameters
as local variables.
I actually like a:,l:,g:,b: etc prefixes. They are useful in practice
because in languages
like C++, people tend to invent project-specific suffixes and prefixes
to distinguish between method vars, local vars, etc.
Vim codifies this. I find this convenient.
"Incredibly nonstandard" ? Since when ALL programming languages
obey one and the same standard ? From forth to lisp to vb.net to perl ?
Where did you see common standard for all programing languages ?
This thing does not exist. There are families of related languages with
common features and spirit, yes, but where did you see "standard features"
that programming language must obey ? This is ridiculous statement.
There is no such thing.
Yakov
Re: replace VimScript (was: wish: allow a: in the function def)
On 4/24/07, Ilya Sher <[EMAIL PROTECTED]> wrote: Robert Lee wrote: > [snip] > Counterwish #2: Dump VimScript and replace it with EMCAScript (maybe > using SpiderMonkey) so that people don't need to learn a new language As a sarcastic joke, this sounds average. But seriously, vim having supprt for embedded perl,python,ruby, tcl and scheme interpreters, it is realistically to expect javascript interpreter added one day. Yakov
search() and smartcase
The search() doesn't seem to follow 'smartcase' (and this does not seem to be documented). Is it possible to have a flag to search() to obey the 'smartcase' ? Can it be included into todo ? Yakov
coredump with match by lines-range (7.0.222); highlighting is not painted fully.
I get coredump and repainting problem, trying to highlight range of lines with :match, as follows: vim -u NONE# this is v7.0.222 :set nocp :help search() " get some text. the line number is 4078 :match Search /\%4078l\_.*\%4200l/ " the range of lines 4078-4200 is highlighted here. So far, so good. Now, there are 3 problem here. 1. The whole match is not always highlighted: :set so=999 :4147 press UpArrow pressed. When you pass through the 4078-4100 range, you'll see that only first line is highlighted. If you press Down now, the range will be highlighted better. Ctrl-L fixes it. 2. I do not understand why only lines 4078-4102 are highlighted. Expected: lines 4078-4200 highlighted. 3. If I try pattern :match Search /\%4078l\(\n\|.\)*\%4200l/ and scroll down with ArrowDown, vim crashes with SIGABRT after several presses of ArrowDown. Yakov
wish: allow a: in the function def
wish: allow a: in the function definition line: function foo(a:line1, a:line2) This is currently not allowed. But it seems logical to allow it. Yakov
wish: collaboration of N vim instances editing same file
Hello Bram, Is it possible to add this item to the vim voting list ?: "collaboration of N vim instances editing same file" -- Ability of N instances of vim to absorb, merge and show changes to the same file made by other running vim instances [ either by reading other vim's swapfiles, or somehow else ] ? Can this be added to SOC ? Yakov
wish: show search progress on slow searches
Wish: when search is slow, show the progress line number every second on the bottom line (like, 12345 of 9). Maybe this can be done with plugin, I'm not sure. Maybe simply status line can be refreshed once in a second, temporarily setting line number to the current search position. Some regexes take half minute to several minutes time on multimegabyte file. It would be nice to see the progress numbers onscreen. Thanks Yakov
todo? (setting eol/noeol after :r !cmd ? )
Hello Bram, Maybe vim would better set &eol/&noel after ':r !cmd' also, no only after reading the file into buffer ? (that is, the condition whether input had final \n or not). As I can see currently, this piece of info is lost after ': !cmd' ? Yakov
Re: Bug: ":confirm w" only works once
On 2/28/07, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote: >> Hi, >> >> When editing a read-only file, ":confirm w" only works the first time >> you use it in a session. The second time you try to use it, you simply >> get an error message, as if you didn't use ":confirm". >> The same problem occurs when using ":set confirm". >> >> To recreate: >> >> $ echo Hello > hello.txt >> $ chmod 400 hello.txt >> $ vim -u NONE hello.txt >> :set nocompatible " or you won't be able to overwrite at all >> A, World >> :confirm w >> 'readonly' option is set for "qq". >> Do you wish to write anyway? >> (Y)es, [N]o: y >> A! >> :confirm w >> E505: "qq" is read-only (add ! to override) >> >> This is using 7.0.203, but it has been happening for quite a while. An >> old 6.3 does the same thing. > > You see this behaviour because the first :confirm w(or ':w!', > for this matter) resets the 'ro' option. This is the reason the 2nd > ':confirm w' doesn't ask anything. You can see yourself if you do > 'set ro?' before and after first ':confirm w'. >:set ro? > readonly >:confirm w > ... (Y)es, [N]o: y >:set ro? > noreadonly > > As you see, the 'ro' option has been reset. This is > the reason the following ':confirm w' does not ask for > the confirmation. > > AFAIK, vim always behaved this way -- that is, > the ':w!' would reset the ro flag. > > But notice that inserting text into 'ro' file does not reset the 'ro' > flag by itself. > It warns (modifying the readonly file). but the 'ro' flag remains. After > :w!, 'ro' flag is reset. > > Yakov > Why then does the second ":confirm w" give 'E505: "qq" is read-only (add ! to override)' ? Because file-on-disk has read-only permissions. But the 'set readonly?' option is off. Yakov
Re: Bug: ":confirm w" only works once
On 2/27/07, Michael Schaap <[EMAIL PROTECTED]> wrote: Hi, When editing a read-only file, ":confirm w" only works the first time you use it in a session. The second time you try to use it, you simply get an error message, as if you didn't use ":confirm". The same problem occurs when using ":set confirm". To recreate: $ echo Hello > hello.txt $ chmod 400 hello.txt $ vim -u NONE hello.txt :set nocompatible " or you won't be able to overwrite at all A, World :confirm w 'readonly' option is set for "qq". Do you wish to write anyway? (Y)es, [N]o: y A! :confirm w E505: "qq" is read-only (add ! to override) This is using 7.0.203, but it has been happening for quite a while. An old 6.3 does the same thing. You see this behaviour because the first :confirm w(or ':w!', for this matter) resets the 'ro' option. This is the reason the 2nd ':confirm w' doesn't ask anything. You can see yourself if you do 'set ro?' before and after first ':confirm w'. :set ro? readonly :confirm w ... (Y)es, [N]o: y :set ro? noreadonly As you see, the 'ro' option has been reset. This is the reason the following ':confirm w' does not ask for the confirmation. AFAIK, vim always behaved this way -- that is, the ':w!' would reset the ro flag. But notice that inserting text into 'ro' file does not reset the 'ro' flag by itself. It warns (modifying the readonly file). but the 'ro' flag remains. After :w!, 'ro' flag is reset. Yakov
Re: gvim, Windows NAS share of a unix file system, hard links
On 2/24/07, Nathan Coulter <[EMAIL PROTECTED]> wrote:
bug report
==
version:
VIM - Vi IMproved 7.0 (2006 May 7, compiled May 7 2006 16:23:43)
MS-Windows 32 bit GUI version with OLE support
problem:
Writing to a file on a windows share where the underlying filesystem
supports hard links, modifying a file using gvim (w command) causes the
file to
acquire a new inode. Contrast with the behavior of notepad.exe (file -
save), which
respects the hard link, keeping the inode intact.
Try ':set backupcopy=yes' in your vimrc.
Does this solve the problem ?
The default mode ('backupcopy=auto') is not guaranteed
to preserve the hardlinks. This is nota bug.
But ':set backupcopy=yes' shall preserve hardlinks. If
':set backupcopy=yes' breaks links, this would be a bug.
Yakov
Re: crash due to -fstack-protector false positive
On 2/24/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > -char_u di_key[1]; /* key (actually longer!) */ > +char_u di_key[]; /* key (actually longer!) */ I think this is c99 vs c89 difference. C99 allows x[] as last member of the struct, but c89 does not. As Bram mentioned, vim is written in c89, not c99. This won't work for standard C compilers, they will complain about unkown size for di_key. The problem is in the compiler, so fix the compiler. Or perhaps there is a way to silence the compiler? Yakov
Re: Vim 7 performance notes
On 2/4/07, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Alexei Alexandrov wrote:
> I'm doing some performance investigations of Vim code trying to
> understand whether there are any possibilities to improve it.
> Currently I've made the following observations (all investigations are
> done on Windows):
>
> Redundant work is done during regexp operations in syntax
> highlighting. On some files it is very noticable. The stack of the
> hotspot is ... > syn_current_attr > syn_regexec > vim_regexec_multi >
> vim_regexec_both > regtry > regmatch > ga_grow > alloc_clear > memset.
> So alloc_clear spends quite a few clockticks in lalloc() and memset().
> The reason for this is pessimistically big grow size for regset
> growing array:
>
> ga_init2(®stack, 1, 1);
>
> This is not very good: many regexp operations don't go deep -
> non-match is detected very quickly. But even one element on the stack
> will lead to allocating at least 1 bytes (which should be fast
> with good CRT memory allocator) and (worse) initializing these 1
> bytes with zeros (won't be that fast).
>
> One possible solution would be to keep regstack alive across calls to
> vim_regexec_both, but I'm not sure if it's can be done safely. What I
> did was replacing the grow size with smaller number and making the
> grow size for growing arrays dynamic with increase of 25%:
>
> --- regexp.c (revision 136)
> +++ regexp.c (working copy)
> @@ -3350,7 +3350,7 @@
> /* Init the regstack empty. Use an item size of 1 byte, since we push
> * different things onto it. Use a large grow size to avoid reallocating
> * it too often. */
> -ga_init2(®stack, 1, 1);
> +ga_init2(®stack, 1, 64);
>
> /* Init the backpos table empty. */
> ga_init2(&backpos, sizeof(backpos_T), 10);
>
> --- misc2.c (revision 136)
> +++ misc2.c (working copy)
> @@ -1905,6 +1905,7 @@
>
> {
> if (n < gap->ga_growsize)
> n = gap->ga_growsize;
> +gap->ga_growsize += (gap->ga_growsize >> 2);
> len = gap->ga_itemsize * (gap->ga_len + n);
> pp = alloc_clear((unsigned)len);
> if (pp == NULL)
>
> With this change I can see serious performance improvements, but I'm
> not sure if they are safe.
> Bram, does it look making any sense?
This is a tradeoff between allocating too much and allocating too often.
What works best completely depends on the implementation of malloc() and
free(). I know that there are many implementations where they are quite
slow. Then allocating larger chunks less often is better. On some
systems they are fast and the chunks can be smaller.
Gnu malloc (glibc) is exceptionally fast, iirc. It is possible
to benchmark the malloc speed during the ./configure time.
And auto-select the initital size depending on the results.
The procmail this similar technique in configure: It automatically
benchmarks it's own builtin strstr() vs system's strstr() and selects
the one which is faster.
Yakov
Re: (patch), global var that indicates default search direction
On 11/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > In addition to @/, this adds global variable that indicates > default search direction (1-forward, 0-backward). Good idea to make this available. I think the variable should be writable, so that when you set @/ you can also set the search direction. For the name: How about "v:searchforward"? Ok, I debugged the v:searchforward patch; it works. The variable is writable. The variable name is v:searchforward in this patch. The variable name feels OK. Took me time to find correct place to insert the line that's triggered by variable assignment. It works now. Yakov search-direction-patch Description: Binary data
Re: (patch), global var that indicates default search direction
On 11/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > In addition to @/, this adds global variable that indicates > default search direction (1-forward, 0-backward). > Doc patch is inluded. Good idea to make this available. I think the variable should be writable, so that when you set @/ you can also set the search direction. For the name: How about "v:searchforward"? I renamed variable to v:searchforward and made it writable. However, the varible writing does not work well although I propagate the to spats[0].off.dir, seemingly correctly. Anybody knows why writing to the var does not work ? Yakov vim-patch-searchdirection Description: Binary data
(patch), global var that indicates default search direction
In addition to @/, this adds global variable that indicates
default search direction (1-forward, 0-backward).
Doc patch is inluded.
The variable name, v:patdir, is not perfect. But I could not think
of better name. v:searchdir would be even worse ("search directories" ?)
Thanks
Yakov
vim-patdir-patch
Description: Binary data
wrong direction of 'n' -- when #,n are remapped and inside function
In the script below, where # and n are remapped,
n goes the wrong direction after #. To see:
vim -u NONE bad.bim
:so %
gg/bannn#n
-- the last n goes forward. we expect it to move backward.
But when script is rewritten to the form #2, then n after # works
correcty. Plain moving the 'silent! exe "norm!"...' out of the
function changes the behavior.
Yakov
-- bad.vim
" ba ba ba ba ba ba ba ba
:set nocp
nnoremap # :call Foo('#')
nnoremap n :call Foo('n')
func! Foo(cmd)
silent! exe "norm! " . a:cmd
endfun
" test sequence: gg/bannn#n
" expected: last 'n' to go backwards
" actual : last 'n' to go forward
Form 2 that works ok
- ok.vim ---
" ba ba ba ba ba ba ba ba
:set nocp
nnoremap # :silent! exe "norm! #"
nnoremap n :silent! exe "norm! n"
" test sequence: gg/bannn#n
" expected: last 'n' to go backwards
" actual : ok
Re: (patch), global var that indicates default search direction
On 11/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
The variable name, v:patdir, is not perfect. But I could not think
of better name. v:searchdir would be even worse ("search directories" ?)
v:direction maybe ?
Yakov
Re: buffer list count
On 11/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
All,
I am trying to keep track of the number of buffers in the buffer list.
I'm doing this with the following code:
autocmd BufAdd * let g:zbuflistcount += 1
autocmd BufDelete * let g:zbuflistcount -= 1
The problem is I found this to be very unreliable in some circumstances,
and I'm not sure why.
The most obvious one is "vim *.cs" where multiple files would be opened;
however, the "BufAdd" autocmd wouldn't run enough times.
One thing that I think could cause it, is problem/restriction of
nested autocommands. By default, nested autocommands are suppressed.
Thus if autocommand creates abufffer, then [nested] autotommands
will not be executed (unless plugin uses word 'nested' ).
I just use bufnr('$') in my statusline. Simple and fast approximation.
Yakov
vim: stack of modes (nested modes)
Vim can be in "stacked-mode", like insert -> -> :norm! is normal-mode inside-command-mode inside insert-mode. mode() function reports ony one mode, this is incompete info. It makes a difference whether we are in "command-mode inside insert-mode", or in "command-mode not inside insert mode". Currently, with mode(), script does not know this. Is it possible to add function to make script aware of the whole stack of modes vim is currently in ? Yakov
Re: Is always guaranteed to be the same as and is always guaranteed to be unique?
On 11/8/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: and is always guaranteed to be unique? No. Namely, unnamed buffers are problem here. Some autocommands that use can be invoked on unnamed buffers (I had such case). In this case, you have to use . As long as buffer is not unnamed and is full pathname and not basename relative to current dir, I supposed it will be unique. I suppose is full pathname when buffer != unnamed. Yakov
Re: avoiding unneeded buffer scrolling
On 11/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: It bothers me how when switching between tabs (gt) or switching between buffers (:bn, :bp), sometimes a buffer will end up being shifted/scrolled up/down within its window. For the occasions that I want to shift the buffer I have keys like "zz" to do this manually. I don't want this to happen automatically. Is there any way to avoid this automatic "shifting" that I'm talking about? Yes, Matt, there is. Try http://www.vim.org/tips/tip.php?tip_id=1379 "Tip #1375: preserve screen *visual* line when switching buffers" Yakov
script able to detect +NUM commandline option ?
Whether Bram thinks it's useful to store this info in some v:variable (so script can know it) ? Within last year, there were requests how script can know whether vim had +NUM option on command line. Yakov
Re: gVim 7 Win32 Maximize bug report
On 11/2/06, Steve Hall <[EMAIL PROTECTED]> wrote: From: dotpanic dotpanic homelinux.org, Thu, November 02, 2006 6:11 am > > I'm pretty new to this mailing list and I hope I'm posting at the > right place. I just want to report a simple bug, easy to reproduce. > > I have only tested it on Windows. > > Open vim, write a single 1 characters line (filled with blanks > for example), and just maximize the window. > > On my PC, I get the following error: > > Vi Improved - A Text Editor has encountered a problem and needs to > close. We are sorry blabla... > > The details are: > AppName: gvim.exe AppVer: 7.0.262.0 ModName: gvim.exe > ModVer: 7.0.262.0 Offset: 0012c053 > > Is the problem reproducible on your configurations? I don't see it, but Vim has always had a weakness with long lines. For me, the line takes more than 5 seconds to refresh on any movement, so there is obviously some heavy duty processing going on somewhere. Just curious, where does one download Vim 7.0.262 ? :) Time machine ? Yakov
Re: gVim 7 Win32 Maximize bug report
On 11/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hello, I'm pretty new to this mailing list and I hope I'm posting at the right place. I just want to report a simple bug, easy to reproduce. I have only tested it on Windows. Open vim, write a single 1 characters line (filled with blanks for example), and just maximize the window. On my PC, I get the following error: Vi Improved - A Text Editor has encountered a problem and needs to close. We are sorry blabla... The details are: AppName: gvim.exe AppVer: 7.0.262.0 ModName: gvim.exe ModVer: 7.0.262.0 Offset: 0012c053 This problem was reported for Windows vim and fixed in the patch ~month ago. But what is 7.0.262 ? Isn't ~ 158 the last patch number for vim7 ? Yakov
Re: Bufnext and bufprev problem
On 11/1/06, Ryan Phillips <[EMAIL PROTECTED]> wrote:
Hi all.
I have just noticed a problem with bufnext and bufprev with two
(plus+) different files open within (g)vim.
Attached my vim --version for review.
OS: Linux, Ubuntu Edgy
Steps to reproduce:
* Create a file ~140 lines long with A'S, TEST_A
* cp TEST_A TEST_A_2
* vim TEST_A TEST_A_2 --noplugins
* In buf #1 scroll to a line number > 30. I selected 38 to be at
the top of my terminal. (I have line numbers turned on)
* :bn # to go to TEST_A_2
* :bp # to return to Buf #1
The first buffer has jumped N lines forward within the file. N
appears to be a constant 22 for me. Can anyone else reproduce this?
You can try the following commands in your vimrc, which
remove the screen repositioning:
" when switching buffers, preserve window view
if v:version >= 700
au BufLeave * let b:winview = winsaveview()
au BufEnter * if(exists('b:winview')) | call winrestview(b:winview) | endif
endif
I posted this as tip (http://vim.sourceforge.net/tips/tip.php?tip_id=1375)
Yakov
Re: Bufnext and bufprev problem
On 11/1/06, Ryan Phillips <[EMAIL PROTECTED]> wrote: I have just noticed a problem with bufnext and bufprev with two (plus+) different files open within (g)vim. Attached my vim --version for review. OS: Linux, Ubuntu Edgy Steps to reproduce: * Create a file ~140 lines long with A'S, TEST_A * cp TEST_A TEST_A_2 * vim TEST_A TEST_A_2 --noplugins * In buf #1 scroll to a line number > 30. I selected 38 to be at the top of my terminal. (I have line numbers turned on) * :bn # to go to TEST_A_2 * :bp # to return to Buf #1 The first buffer has jumped N lines forward within the file. N appears to be a constant 22 for me. Can anyone else reproduce this? If I try your testcase with 'vim -u NONE', then current line becomes vertically centered around after :bn,:bp. The current line number is not changed, but the screen visual line is changed. The autocommand trick to disable this jumping was posted couple of months ago on this list. Another option to disable this jumping is to use 'set scrolloff=999'. Yakov
Re: syntax region match with braces
On 10/31/06, Виктор Кожухаров <[EMAIL PROTECTED]> wrote:
Hello,
I'm working on a syntax file for .edc files. The problem before me is
that I want to use a different syntax file for a "script" part. I've
created the syntax file for the script syntax, and I've read how yto use
"syn include".
The real problem is, that in the .edc files, scripts are located within:
script {
SCRIPT HERE
}
,however, the scripts themselves can also have {} braces. I've written
the following, but it only uncludes the script syntax upto the first "}"
brace, and I have no idea how to make it end on the _matching_ "}" brace
instead:
---
syn include @edcEmbryo syntax/embryo.vim
unlet b:current_syntax
syn region edcScript start="\\s*\n*\s*{" end="}"
[EMAIL PROTECTED],edcScriptTag
syn keyword edcScriptTagcontained script
---
So the question is, if I have:
script {
if (foo) {
bar;
} else {
baz;
}
}
how do I make vim use the script syntax all the way up to the closing }
brace for the "script"?
1. Maybe this can fix the problem: namely, using this inclusion method
mentioned in ':help syn-include' :
:runtime! syntax/embryo.vim
:unlet b:current_syntax
, instead of using 'syn include'. Does this help ?
If this won't help, how about two less probably possiblities:
2. Just for the sake of experiment, does the problem go away
when you modify the 'syn region' to this:
syn region edcScript start="\\s*\n*\s*{" end="^}" ...
I realise this is not the proper final fix, but just to see what makes the
problem. Without (1) and (2), I think vim
has egg-and-chicken problem trying to determine where
@edcEmbryo ends.
3. Does something change if you comment out the 'syn keyword ... script'
statement ?
One less probably suspicion is that that 'keyword script' badly interacts with
pattern containing 'script' with 'region ... start="\...
This seems less probale because you say that beginning of edcScript
region matches correctly.
Yakov
Re: unsychronized vimdiff panes
On 10/23/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > In vimdiff mode, when you resize xterm vertically, 2 panes > become desynchronized, and stay desynchronized until you > press an arrow key. > The active pane is repositioned according to resizing, but the other > pane is not. And they get out of sync. To see this, choose two large > files and position it somewhere in the middle. I don't see it. Please give a more specific example. 0. open xterm. you can make it wide and tall. 1. cd $VIMRUNTIME/doc # in shell 2. vimdiff -u NONE version6.txt version6.txt 3. :set nu:set nu 4. 50% 5. with the mouse, grab lower border of xterm window and change height of xterm window either x2 times smaller or x2 times taller, whatever your display allows it. 6.While holding mouse button, notice how active pane is repositioned with the resize, but the other pane is not repositioned. 7. release mouse button. now two panes became desynchronized. if you press arrow key, the other pane jumps into place. Yakov
Re: escape() and '
On 10/23/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 10/23/06, Mikolaj Machowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I understand that escape() was primarily designed to escape strings when
> passing to system functions, but personally I never used that and in
> didn't noticed such use in various scripts but very often it is used to
> escape various charaters in Vim's own regexp matching or passing one
> string to some other Vim command.
>
> Hence is the problem: when escaping ' with escape(), character is
> prepended with \ which doesn't make sense when passing it to other Vim
> command because proper way to escape it in Vim is doubling it with
> another '. Example::
>
> :echo escape('as''df', )
There should really be a third, optional, parameter to escape() where
you can specify what character to use for escaping.
I'd suggest that 3rd arg for escape(), if it's neeed (well you
always can brute-force escape things using substitute()), it would
be code of the context (1-5) for which escaping is destined. Because
Vim has at least 4-5 different escaping rules in different contexts:
1) escaping rules for double-quoted strings
2) escaping rules for single-quoted strings
3) escaping rules for :-command-line
4) escaping rules for regexes
5) escaping rules rules for rhs of the mapping.
Escaping would be different for each of those contexts.
Yakov
unsychronized vimdiff panes
In vimdiff mode, when you resize xterm vertically, 2 panes become desynchronized, and stay desynchronized until you press an arrow key. The active pane is repositioned according to resizing, but the other pane is not. And they get out of sync. To see this, choose two large files and position it somewhere in the middle. Yakov
Re: the plugin startup check
On 10/20/06, Peter Hodge <[EMAIL PROTECTED]> wrote:
--- Yakov Lerner <[EMAIL PROTECTED]> wrote:
> Almost every plugin begins with this check:
> if exists("g:plugin_name") | finish | endif
> let g:plugin_name = 1
> I understand this tries to save time if vim tries to load plugins 2nd time.
> But aren't plugins loaded only at vim startup ? Does vim *ever*
> ever try to load plugins 2nd time ? In which situation can vim load
> plugin 2nd time (except for some manual command) ?
>
> Yakov
>
I think it is because you may have a copy of the plugin in $VIMRUNTIME as well
as in your .vim folder. In this way, your .vim copy is sourced first (well,
according to 'rtp'), sets the g:plugin_name variable and when the $VIMRUNTIME
plugins are sourced, and it sees the variable and prevents loading that copy of
the plugin also.
Ok, I found the description in usr_41.txt, at "NOT LOADING".
Thanks
Yakov
the plugin startup check
Almost every plugin begins with this check:
if exists("g:plugin_name") | finish | endif
let g:plugin_name = 1
I understand this tries to save time if vim tries to load plugins 2nd time.
But aren't plugins loaded only at vim startup ? Does vim *ever*
ever try to load plugins 2nd time ? In which situation can vim load
plugin 2nd time (except for some manual command) ?
Yakov
svn vs rsync vs ftp
Of different current methods to access vim sources (svn, ftp, rsync, etc) which one is fastest to be updated when new patch is issued, and also has most reliable/fast server ? Yakov
Re: [PATCH] cygwin: Trouble recognizing absolute path
On 10/13/06, Corinna Vinschen <[EMAIL PROTECTED]> wrote:
Hi,
I got a report on the Cygwin mailing list that the following message
appears when trying to open /etc/hosts in vim:
E303: Unable to open swap file for "/etc/hosts", recovery impossible
What happens is this:
/etc/hosts is by default a symbolic link which points to the hosts file
in the Windows system directory. The symbolic link is created as a link
to the DOS path, for instance:
$ ls -l /etc/hosts
lrwxrwxrwx 1 corinna None 37 Oct 13 18:32 /etc/hosts ->
c:\WINDOWS\system32\drivers\etc\hosts
I bet you can solve the problem by relinking /etc/hosts to
/cygdrive/c/windows/system32/drivers/etc/hosts.
This is how it *should* be linked.
It surprises me very much that your cygwin recognizes backslashes in
pathnames. I was under impression that cygwin does not recognize
backslashes in pathnames .. forward slashes as path separators.
I mean, I tried 'ls c:\windows' in cygwin and it does not work ..
strange is it issue of version of cygwin ? I saw even
weirder differences in cygwin behaviour ... fat32 vs ntfs differences...
Yakov
By stracing vim I found that vim was trying to create a swap file
called "/tmp/c:\WINDOWS\system32\drivers\etc\hosts".
Cygwin is mostly treated as Unix target in vim, which is basically
correct. However, since Cygwin allows POSIX paths as well as DOS paths,
there are both types of absolute paths.
Below is a patch which works for me, though I'm not sure if it's
complete enough to catch all cases. There's code for OS2 in os_unix.c
which I reused, plus a new definition in mch_isFullName for the absolute
path on Cygwin.
I'd be grateful if the below or a more feasible patch which solves the
above problem, could be applied to vim.
Thanks in advance,
Corinna
--- os_unix.c.orig 2006-10-13 18:40:34.898586400 +0200
+++ os_unix.c 2006-10-13 19:01:44.398373000 +0200
@@ -2213,7 +2213,7 @@ mch_FullName(fname, buf, len, force)
intforce; /* also expand when already absolute
path */
{
intl;
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
intonly_drive; /* file name is only a drive letter */
#endif
#ifdef HAVE_FCHDIR
@@ -2236,7 +2236,7 @@ mch_FullName(fname, buf, len, force)
* and then do the getwd() (and get back to where we were).
* This will get the correct path name with "../" things.
*/
-#ifdef OS2
+#if defined (OS2) || defined (__CYGWIN__)
only_drive = 0;
if (((p = vim_strrchr(fname, '/')) != NULL)
|| ((p = vim_strrchr(fname, '\\')) != NULL)
@@ -2369,7 +2369,15 @@ mch_isFullName(fname)
(strchr((char *)fname,'[') && strchr((char *)fname,']'))||
(strchr((char *)fname,'<') && strchr((char *)fname,'>')) );
# else
+# ifdef __CYGWIN__
+/* POSIX and DOS paths are possible. */
+return (*fname == '/' || *fname == '~'
+ || (isalpha (fname[0]) && fname[1] == ':'
+ && (fname[2] == '/' || fname[2] == '\\'))
+ || (fname[0] == '\\' && fname[1] == '\\'));
+# else
return (*fname == '/' || *fname == '~');
+# endif
# endif
#endif
}
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Re: :diffsplit | verbose set fdm?
On 10/13/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 10/13/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: >> Benji Fisher wrote: >> > While replying to a post on the vim users' list, I noticed a >> slight >> > problem. The diff commands set some options, but this is not reported >> > with "verbose set". For example >> > >> > :e foo.txt >> > :set fdm=marker >> > :diffsplit bar.txt >> > :wincmd w " back to foo.txt >> > :verbose set fdm? >> > foldmethod=diff >> > :only >> > :verbose set fdm? >> > foldmethod=manual >> > >> > --Benji Fisher >> > >> >> Since you entered the built-in command which changed the 'fdm' option >> at the >> keyboard, there is no script or modeline to 'verbose'ly report. Or is >> the file >> actually not "manual"ly folded at the last step? I don't understand in >> what >> way the "actual behaviour" differs from the "expected behaviour". > > The copy of command itself could be remembered > to be printed later by 'verbose set fdm?', like this: >Last set from interactive, 33 commands ago ':diffsplit bar.txt' > Or the first 80 chars of the command, in case it was too long > (single vim command half million characters long was discussed > recently on the list ... although it was not typed interactively on > vim command line ... ) > > Alternatively, 'Last set from' could refer to command number as it > appears in the :history (commands are numbered there). But if that > command was too long ago that it dropped from history, you can't > see it using :history. > > Just my 5c > > Yakov > Maybe; but IMHO that would be a "request for enhancement", not a "bug". I thought Benji meant that Vim was not behaving as advertised. Benji used word "problem" not word "bug". Literally speaking, vim behaves per doc here because ':help set-verbose' mentions When the option was set by hand there is no "Last set" message. But I share Benji's judgement. When command sets option indirectly, it's always kind of surprise, and I'd prefer ':verbose set xyz' to show exactly which by-hand command did it. This would be helpful in cases of indirect option switching. Yes this is change request. But I feel it makes sense. Yakov
Re: :diffsplit | verbose set fdm?
On 10/13/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Benji Fisher wrote: > While replying to a post on the vim users' list, I noticed a slight > problem. The diff commands set some options, but this is not reported > with "verbose set". For example > > :e foo.txt > :set fdm=marker > :diffsplit bar.txt > :wincmd w " back to foo.txt > :verbose set fdm? > foldmethod=diff > :only > :verbose set fdm? > foldmethod=manual > > --Benji Fisher > Since you entered the built-in command which changed the 'fdm' option at the keyboard, there is no script or modeline to 'verbose'ly report. Or is the file actually not "manual"ly folded at the last step? I don't understand in what way the "actual behaviour" differs from the "expected behaviour". The copy of command itself could be remembered to be printed later by 'verbose set fdm?', like this: Last set from interactive, 33 commands ago ':diffsplit bar.txt' Or the first 80 chars of the command, in case it was too long (single vim command half million characters long was discussed recently on the list ... although it was not typed interactively on vim command line ... ) Alternatively, 'Last set from' could refer to command number as it appears in the :history (commands are numbered there). But if that command was too long ago that it dropped from history, you can't see it using :history. Just my 5c Yakov
Re: feature request: don't write backup if the file is unmodified
On 10/13/06, David Schweikert <[EMAIL PROTECTED]> wrote: Would it be possible to make Vim overwrite a backup file only if the buffer was actually modified? Look at the following scenario: 1. I edit file foobar.txt, make some change and save it. -> the backup file foobar.txt~ is created 2. I edit again foobar.txt, but this time I don't make any change. I do however write the file with ':w' by mistake... -> the backup file foobar.txt~ is replaced and both files have now the same content. If there is some problem in replacing the current behaviour, could it maybe be an option? You have several options. 1) Try "savevers" plugin http://www.vim.org/scripts/script.php?script_id=89 It saves numbered version at each save, in the directory you specify (I use ~/tmp). This is much more useful than single ~ backup file. 2) You can take up to using :up rather than :w. :up command only writes file if it was mofified. 3) You can use autocommands to avoid saving the buffer if buffer is not modified. I'm not sure at the moment how to achieve it in one-liner; the following works but gives ugly message when buffer is not modified: au BufWritePre * if !&modified | throw "Nothing to save" | endif 4) You can use tip http://www.vim.org/tips/tip.php?tip_id=1285 to remap :w to :up : cabbrev w =(getcmdtype()==':' && getcmdpos()==1 ? 'up' : 'w') Yakov
long echomsg + 'set shortmess+=T' + norm-vs-without-norm
I observe strange behaviour related to 'set shortmess+=T' . Sometimes
this 'T' flag shortens long messages, sometimes it does not.
To see:
1.
vim -u NONE
2.
:set nocp shortmess=aT
:nmap ZB :echomsg repeat('a',&co+10)
3.
Press ZB. You get long message and 'Press Enter' prompt.
4.
Type
:norm ZB
You get shortened message, and no ''Press Enter' prompt.
5.
Type
:echomsg repeat('a',&co+10)
This behaves like (3), not like (4).
I don't understand why (3),(4), and (5) behave differently.
I think (4) is correct and (3) and (5) are bugs ?
Yakov
Re: usability suggestion: 'viminfo'
On 10/7/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Yakov Lerner wrote:
> I suggest new flag for 'viminfo'; flag to turn on the *last-position-jump*
> functionality (say, letter j). Such it will be much easier method to
> turn on the last-position-jump functionality. With new flag, it will be mere:
>
> :set viminfo='20,<50,s10,j
> or
> :set viminfo+=j
> -- as easy as addding flag j to 'viminfo'.
>
> Currently, the magic sequence to turn on the *last-position-jump*
>
> :set viminfo='20,<50,s10
> augroup lastPositionJump
> au!
> autocmd BufReadPost *\ if line("'\"") > 0 && line("'\"") <= line("$") |
> \ exe "normal g`\"" |endif
> augroup END
>
> This proves difficult for novice vim user to figure out even with the
> help of vimhelp.
> It's demanded and requested features, why not to make it easier to turn on ?
>
> I mean that internally, new flag would add/remove that same autocmd.
> It's not difficult to implement, right ? And it's backward-compatible.
> Can I make a patch ?
I think finding the "j" flag in the 'viminfo' option is much harder than
finding the hint to source the $VIMRUNTIME/vimrc_example.vim script.
Also keep in mind that sometimes jumping to some position is undesired,
thus we would also need a mechanism to disable it.
Of course, 'set viminfo-j' would remove the autocommand
(like augroup lastPositionJump|au!|augroup END).
But maybe 'set autojump' then ? (With 'noautojump' removing the
autocommand ?
Every time I look at the {autocmd BufReadPost *\ if line("'\"") >
0 && line("'\"") <= line("$") | exe "normal g`\"" |endif} sequence , I
get
a feeling like the switch which would need to be acessible and
reachable inside the car near the driver seat, was palced under
the hood near the engine, and when one needs to access it,
you need to get out of the car and open the hood.
Yakov
usability suggestion: 'viminfo'
I suggest new flag for 'viminfo'; flag to turn on the *last-position-jump*
functionality (say, letter j). Such it will be much easier method to
turn on the last-position-jump functionality. With new flag, it will be mere:
:set viminfo='20,<50,s10,j
or
:set viminfo+=j
-- as easy as addding flag j to 'viminfo'.
Currently, the magic sequence to turn on the *last-position-jump*
:set viminfo='20,<50,s10
augroup lastPositionJump
au!
autocmd BufReadPost *\ if line("'\"") > 0 && line("'\"") <= line("$") |
\ exe "normal g`\"" |endif
augroup END
This proves difficult for novice vim user to figure out even with the
help of vimhelp.
It's demanded and requested features, why not to make it easier to turn on ?
I mean that internally, new flag would add/remove that same autocmd.
It's not difficult to implement, right ? And it's backward-compatible.
Can I make a patch ?
Yakov
Re: vim -u NONE
On 10/6/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Peter Hodge wrote: [...] > I wouldn't think the -i option is necessary, because 'viminfo' is empty by > default anyway. [...] The 'viminfo' option is not empty by default, except in 'compatible' mode (see -u option forces 'compatible' on. Thus I an pretty sure -i is redundant if added to -u NONE. -n NONE forces 'compatible' and thus empty 'viminfo'. Yakov
Re: vim -u NONE
On 10/6/06, Bill McCarthy <[EMAIL PROTECTED]> wrote: On Thu 5-Oct-06 8:54pm -0600, Gary Johnson wrote: >> > gvim -u NONE -i NONE -N > Setting "-u NONE -i NONE -N" is all that's needed. See ":help -u". I never noticed that 'vim -u NONE' ever read the .viminfo ? For example, if I set 'set nocp' in 'vim -u NONE' then I don't see any command history that I'd see had .viminfo been read in. Do you see any difference between 'vim -u NONE' and 'vi -u NONE -i' ? Yakov
Re: Missing CursorHold after return from insert to normal ?
On 10/5/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > CursorHold is suppsed to be triggered in normal mode > after &updatetime, correct ? But in the scenario below, > when vim gets into normal mode after insert mode, > CursorHold is not triggered: > > 1. vim -u NONE -U NONE > 2. :let x=0 > 3. :let ut=200" just some low value > 3. :au CursorHold * let x=x+1 | echo x > 4. -- watch CursorHold working > 5. ii wait there's not CursorHold > ii wait there's not CursorHold > ii wait there's not CursorHold > > Why ? Bug or feature ? You don't mention the version number. Does it include patch 7.0.104? Yes Then this patch should fix it: *** ../../vim-7.0.118/src/edit.cTue Oct 3 15:49:20 2006 --- edit.c Thu Oct 5 22:26:27 2006 *** *** 923,928 --- 923,929 if (cmdchar != 'r' && cmdchar != 'v') apply_autocmds(EVENT_INSERTLEAVE, NULL, NULL, FALSE, curbuf); + did_cursorhold = FALSE; #endif return (c == Ctrl_O); } That fixes it, thanks. Yakov
Missing CursorHold after return from insert to normal ?
CursorHold is suppsed to be triggered in normal mode after &updatetime, correct ? But in the scenario below, when vim gets into normal mode after insert mode, CursorHold is not triggered: 1. vim -u NONE -U NONE 2. :let x=0 3. :let ut=200" just some low value 3. :au CursorHold * let x=x+1 | echo x 4. -- watch CursorHold working 5. ii wait there's not CursorHold ii wait there's not CursorHold ii wait there's not CursorHold Why ? Bug or feature ? Yakov
Re: Autocommand-Event for Clipboard-Changed
On 10/3/06, Charles E Campbell Jr <[EMAIL PROTECTED]> wrote:
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.
Charles,
What's wrong with doing system("vim --remote-xxx yyy zzz") in
any programming language ?
Yakov
Re: Time to remove naming restrictions?
On 10/3/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote: Nikolai Weibull wrote: > On 10/1/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: >> >> Nikolai Weibull wrote: >> >> > One thing that really annoys me with Vim is the limits it emposes on >> > what names are legal for user-defined functions and commands. I know >> > the reason for these restrictions, but I don't think they make much >> > sense, especially so for user-defined commands. I realize that >> > overriding :quit does have its implications, but done carefully, this >> > does allow for some interesting effects. >> > >> > So, why not lift the restrictions on valid names for user-defined >> > functions and commands? >> > >> > That is, give me good reasons for why they should be maintained and >> > I'll drop this request. >> >> Predictability. > > As in what? That :quit always works as documented? Sure, that's > great, but if that's the problem, the restriction should be limited to > commands already defined. And what happens when more commands are > added? Hell, then they'll break the user-defined commands with the > same name. Big deal; that's life, you'll get over it - everyone does, > eventually. > > I really don't see the big difference between user-defined commands > clashing with built-in commands and user-defined commands clashing > with each other. It'll happen; unless you start adding prefixes or > namespaces or some other way of separating your commands. But then > you lose out on simplicity. You don't want to type :NOWCommand (given > that "NOW" is "my" prefix), and I don't want to type :Command; I want > to type :command. > > Sure, it only saves my fingers from giving up on me for so long, but > every little bit helps. > > I guess my problem is that I want - and I've always wanted - the > flexibility of Emacs coupled with the simplicity and efficiency of > Vim's command set and modes. I guess that's why I nitpick at things > such as this. > > nikolai > :command -bar Command ... :cabbrev command Command and then you'll wonder why you can't define a new user-command but it's your funeral. You can (via source); cabbrev don't affect sourced scritps. Yakov
CursorHold when cursor is in command-line
I observe that CursorHold is not triggered when cursor in spending long time in commandline, correct ? Is it possible to trigger CursorHold also when cursor is in command line ? (Maybe by some :au CursorHold syntax ?) BTW does all this mean that if I enter commandline (:) within less than 'updatetime' from last change, .swp file is not updated all the time I am still in commandline ? Yakov
Re: Do Not Reply To This Message:Re: Time to remove naming restrictions?
Me too. I think it means that (1) "email address at KNBT that is unavailable or no longer valid", and (2) it's time for you to add special filtering rule to your mail reader. I mean, who said mail bot cannot post to mailing list ? Yakov On 10/2/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote: I keep getting this f**king message every time I post to vim-dev. Seriously, wtf? nikolai (awaiting another notification for this mail not getting through) -- Forwarded message -- From: System Administrator <[EMAIL PROTECTED]> Date: 2 Oct 2006 14:19:05 -0400 Subject: Do Not Reply To This Message:Re: Time to remove naming restrictions? To: Nikolai Weibull <[EMAIL PROTECTED]> You have reached an email address at KNBT that is unavailable or no longer valid. If you have any questions please call our customer service number at 1-800-996-2062 (toll-free), Monday – Friday: 7:00 a.m. - 7:00 p.m. and Saturday: 8:00 a.m. - 2:00 p.m. Thank You, We are very sorry for any inconvenience. KNBT Banking, Insurance, Investments, Trust [EMAIL PROTECTED] Office: Fax: http://www.knbt.com "This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error, please notify the system manager. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Keystone Nazareth Bank & Trust. Finally, the recipient should check this e-mail and any attachments for the presence of viruses. Keystone Nazareth Bank & Trust accepts no liability for any damage caused by any virus transmitted by this e-mail."
Re: Searching for selected text
On 9/30/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Sometimes people ask me for a command to search for the text that is currently visually selected. You could add a mapping for the '/' key, but then you lose the possibility to extend the visual area by searching for a pattern. Since we might need more commands in Visual mode later, and we only have a few keys left to be used, we need to use two key combinations for new commands in Visual mode. I think we can start using the '&' key. Currently it doesn't do anything. For now we could add the commands: &/ search for the Visually selected text forward &? same, backward Do Ctrl-K/ Ctrl-K? do something in visual mode ? Yakov
Re: Searching for selected text
On 9/30/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Sometimes people ask me for a command to search for the text that is currently visually selected. You could add a mapping for the '/' key, but then you lose the possibility to extend the visual area by searching for a pattern. Since we might need more commands in Visual mode later, and we only have a few keys left to be used, we need to use two key combinations for new commands in Visual mode. I think we can start using the '&' key. Currently it doesn't do anything. For now we could add the commands: &/ search for the Visually selected text forward &? same, backward Do you plan to treat visual selection as pattern, or a literal text-to search ? Yakov
Re: Searching for selected text
On 9/30/06, Georg Dahn <[EMAIL PROTECTED]> scribbled:
Hi!
Bram Moolenaar wrote:
> &/ search for the Visually selected text forward
> &? same, backward
>
> Is there a good alternative?
I think, this is ok. For the moment I have the following lines
...
vnoremap * VisualSearch('*')
vnoremap # VisualSearch('#')
I also use 'vmap * ...' and 'vmap # ...' to search for
text that is visual selection.In my mapping, all special chars
in visual selection are quoted to make them literal.
I think there can be two variants for search for visual selection:
1) treat visual selection as pattern
2) treat visual selection as literal text
Yakov
patch for , that fixes handling of backslashes
Hello,
Attached patch fixes handling of backslashes in
according to the Bram's table, below. Doc patch is included, too.
Pair of backslashes is translated into single backslash.
Otherwise backslash is special before whitespace, otherwise
backslash is not special (single backslash represents single
backslash except before whitespace or before another backslash).
Yakov
Bram Moolenaar wrote:
commandnew old
XX ab ab ab
XX a\ba\b a\b
XX a\ b a b a b
XX a\\b a\b a\\b
XX a\\ b a\ b a\ b
XX a\\\b a\\ba\\\b
XX a\\\ b a\ ba\\ b
XX ab a\\bab
XX a ba\\ b a b
--- src/ex_docmd.c.000 2006-09-27 20:12:10.0 +0300
+++ src/ex_docmd.c 2006-09-27 20:36:26.0 +0300
@@ -5551,6 +5551,9 @@
mch_memmove(cmd, cmd + 1, (gap->ga_len - i) * sizeof(ucmd_T));
}
+/*
+ * split and quote args for
+ */
static char_u *
uc_split_args(arg, lenp)
char_u *arg;
@@ -5567,7 +5570,12 @@
while (*p)
{
- if (p[0] == '\\' && vim_iswhite(p[1]))
+ if (p[0] == '\\' && p[1] == '\\')
+ {
+ len += 2;
+ p += 2;
+ }
+ else if (p[0] == '\\' && vim_iswhite(p[1]))
{
len += 1;
p += 2;
@@ -5603,7 +5611,13 @@
*q++ = '"';
while (*p)
{
- if (p[0] == '\\' && vim_iswhite(p[1]))
+ if (p[0] == '\\' && p[1] == '\\')
+ {
+ *q++ = '\\';
+ *q++ = '\\';
+ p += 2;
+ }
+ else if (p[0] == '\\' && vim_iswhite(p[1]))
{
*q++ = p[1];
p += 2;
@@ -5735,7 +5749,7 @@
}
break;
- case 2: /* Quote and split */
+ case 2: /* Quote and split () */
/* This is hard, so only do it once, and cache the result */
if (*split_buf == NULL)
*split_buf = uc_split_args(eap->arg, split_len);
--- runtime/doc/map.txt.000 2006-09-27 20:06:17.0 +0300
+++ runtime/doc/map.txt 2006-09-27 20:30:38.0 +0300
@@ -1303,12 +1303,16 @@
) then the value is quoted in such a way as to make it a valid value
for use in an expression. This uses the argument as one single value.
When there is no argument is an empty string.
-
+**
To allow commands to pass their arguments on to a user-defined function, there
is a special form ("function args"). This splits the command
arguments at spaces and Tabs, quotes each argument individually, and the
sequence is replaced by the comma-separated list of quoted arguments.
See the Mycmd example below. If no arguments are given is removed.
+To embed whitespace into argument of , prepend backslash(\) before
+the whitespace. replaces every pair of backslashes (\\) to one
+backslash. Single backslash represent single backslash (except before
+other backslash and before whitespace).
Examples >
--- runtime/doc/todo.txt.000 2006-09-27 20:06:03.0 +0300
+++ runtime/doc/todo.txt 2006-09-27 20:06:39.0 +0300
@@ -650,9 +650,6 @@
7 "[p" doesn't work in Visual mode. (David Brown)
7 The Cygwin and MingW makefiles define "PC", but it's not used anywhere.
Remove? (Dan Sharp)
-9 The argument of a user command doesn't handle backslashes
-properly. "Cmd \ e" is one argument, "Cmd \\ e" still is one argument.
-"Cmd \ e" is two arguments, first one ending in space. (Kontra Gergely)
9 User commands use the context of the script they were defined in. This
causes a "s:var" argument to unexpectedly use a variable in the defining
script, not the calling script. Add an argument to ":command":
Re: no winclose event
On 9/25/06, Charles E Campbell Jr <[EMAIL PROTECTED]> 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. And WinResize event is AWOL, too. Yakov
Re: GTK2 gui_gtk_position_in_parent() - bad indenting or missing operator?
On 9/16/06, Alexey I. Froloff <[EMAIL PROTECTED]> wrote: gui_gtk.c: 3131 if ((pos_x + c_size.width) > (wP + xP)) 3132pos_x = xP + wP - c_size.width - 2; 3133 /* Assume 'guiheadroom' indicates the title bar height... */ 3134 if ((pos_y + c_size.height + p_ghr / 2) > (hP + yP)) 3135 3136 gtk_widget_set_uposition(child, pos_x, pos_y); 3137 } gtk_widget_set_uposition() is called only if condition in line 3134 is true. P.S. Can anyone confirm, that running gvim-gtk2 -u NONE -U NONE --cmd 'set lines=' --cmd 'set guifont=Bolkhov\ VGA\ 10' _SOMETIMES_ does not resize gvim window? On both of my Linux computers, at home, and at work, gvim --cmd 'set lines=' *never* resizes the window. Does this count as "reproduction" :-) ? I think this is by design, as Tony explained. On the other hand, gvim -u NONE -U NONE -c 'set lines=' always resizes. Note the difference: --cmd vs -c. I think Tony is right, this is by design due to difference between '--cmd' and '-c'. Yakov
Re: patch: automatically enter paste mode
On 9/13/06, Ian Kilgore <[EMAIL PROTECTED]> wrote: On Wed, Sep 13, 2006 at 11:27:43AM +0300, Yakov Lerner wrote: > Nice. So simple. I have couple of comments. > Thank you :) > 1. Don't you need to reset 'paste' back to 'nopaste' when > high cps stops ? > There is a hastily coded version of the patch that does this, but I don't like it. It seems hackier (most likely my fault), and stranger to use. That is, as far as I know, inavoidable, since I have to wait until at least one second after the paste ends and the user starts typing before I can know to end the paste. I'm open to suggestions as to how to do that better. I'll attach both patches this time. > 2. It would be better if cps be settable, not hardcoded to 30. > Maybe value of 'autopaste' can be made the cps boundary > 'set autopaste=30', value 0 disables ? > Good idea. Fixed in this version. I think this is useful feature if it can be made reliable. How reliable is this detection ? What are cases when it breaks ? Let's say there is 'nmap ...' or 'imap ...' or iabbr where rhs has more that 30 chars (and autopaste threshold is 30 cps). If user presses F5, will paste be [wrongly] triggered ? Do you check whether chars come from mapping vs not from mapping ? Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > > > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Yakov Lerner wrote: > > > > > > > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > > > > > involving tags break, including the help system. Typing :h, > > > > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > > > > > infinite loop. > > > > > > > > > > [...] > > > > > > > > > > > > Can you find out where in the code this happens? > > > > > > > > > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > > > > > functions. Perhaps fgets(), since that's what is being used to read the > > > > > > > tags file. > > > > > > > > > > > > In situation where fgets() returns NULL, find_tags() enters > > > > > > infinite loop as follows. > > > > > > > > > > Sorry, this doesn't show me where the loop actually is. Please compile > > > > > without the optimizer, otherwise code reordering confuses the debugger. > > > > > > > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). > > > > > > > > The loop is is inside find_tags(), and it procees around following line > > > > numbers: > > > > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 > > > > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 > > > > and infinite loop repeats. Look at this: > > > >gdb> print print search_info.curr_offset > > > > $2 = 5258708303049 > > > > > > I cannot guess where this loop first gets beyond end of file > > > (filesize=2506), but once it gets beyond, we are missing check that > > > search_info.*offset''s are beyond end of file ? > > > Maybe add such check somewhere ? I don't know where to add the check. > > > > > > Yakov > > > > It seems I found the culprint. It is line 1651, > > search_info.match_offset = ftell(fp); > > > > (gdb) p ftell(fp) > > $11 = 2506 > > (gdb) n > > 1652search_info.curr_offset = > > search_info.curr_offset_used; > > (gdb) p search_info.curr_offset > > $12 = 5258708302025 > > (gdb) > > Ok, this must be gcc bug. It bites even without optimization. > Rewriting lines 'search_info.curr_offset = ftell(fp)' fixes the problem > if I rewrite them into this: > long ltmp; > ltmp = ftell(fp); > search_info.curr_offset = ltmp; > > NB that ftell() returns long. Type of search_info.curr_offset is long > long when -D_FILE_OFFSET_BITS=64. Simpe asignment >search_info.curr_offset = ftell(fp) > puts trash into lhs. ftell(fp) by itself returns correct number. > this is gcc 3.4.2 Fedora3 Surprisingly, changing ftell() to ftello() does not change anything. Casting ftell() to (off_t) doesn't change anything. Funnily, casting ftell to (long) makes the problem go away (as it ftell does not already return long, it does): 1628 search_info.curr_offset = (long)ftell(fp); 1644 search_info.curr_offset = (long)ftell(fp); 1651 search_info.match_offset = (long)ftell(fp); New developments: It looks like -D_FILE_OFFSET_BITS=64 alone is wrong because it's not complete. Correct build settings are: gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE This makes problem go away without any changes in the sources. Haakon: can you check that adding these solves the problem on you rmachine ? Yakov 3. Thou shalt not use Google as a verb. http://www.thechurchofgoogle.org/Scripture/10_Commandments.html
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > > > Yakov Lerner wrote: > > > > > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > > > > involving tags break, including the help system. Typing :h, > > > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > > > > infinite loop. > > > > > > > > [...] > > > > > > > > > > Can you find out where in the code this happens? > > > > > > > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > > > > functions. Perhaps fgets(), since that's what is being used to read the > > > > > > tags file. > > > > > > > > > > In situation where fgets() returns NULL, find_tags() enters > > > > > infinite loop as follows. > > > > > > > > Sorry, this doesn't show me where the loop actually is. Please compile > > > > without the optimizer, otherwise code reordering confuses the debugger. > > > > > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). > > > > > > The loop is is inside find_tags(), and it procees around following line > > > numbers: > > > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 > > > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 > > > and infinite loop repeats. Look at this: > > >gdb> print print search_info.curr_offset > > > $2 = 5258708303049 > > > > I cannot guess where this loop first gets beyond end of file > > (filesize=2506), but once it gets beyond, we are missing check that > > search_info.*offset''s are beyond end of file ? > > Maybe add such check somewhere ? I don't know where to add the check. > > > > Yakov > > It seems I found the culprint. It is line 1651, > search_info.match_offset = ftell(fp); > > (gdb) p ftell(fp) > $11 = 2506 > (gdb) n > 1652search_info.curr_offset = > search_info.curr_offset_used; > (gdb) p search_info.curr_offset > $12 = 5258708302025 > (gdb) Ok, this must be gcc bug. It bites even without optimization. Rewriting lines 'search_info.curr_offset = ftell(fp)' fixes the problem if I rewrite them into this: long ltmp; ltmp = ftell(fp); search_info.curr_offset = ltmp; NB that ftell() returns long. Type of search_info.curr_offset is long long when -D_FILE_OFFSET_BITS=64. Simpe asignment search_info.curr_offset = ftell(fp) puts trash into lhs. ftell(fp) by itself returns correct number. this is gcc 3.4.2 Fedora3 Surprisingly, changing ftell() to ftello() does not change anything. Casting ftell() to (off_t) doesn't change anything. Funnily, casting ftell to (long) makes the problem go away (as it ftell does not already return long, it does): 1628 search_info.curr_offset = (long)ftell(fp); 1644 search_info.curr_offset = (long)ftell(fp); 1651 search_info.match_offset = (long)ftell(fp);
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > Yakov Lerner wrote: > > > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > > > involving tags break, including the help system. Typing :h, > > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > > > infinite loop. > > > > > > [...] > > > > > > > > Can you find out where in the code this happens? > > > > > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > > > functions. Perhaps fgets(), since that's what is being used to read the > > > > > tags file. > > > > > > > > In situation where fgets() returns NULL, find_tags() enters > > > > infinite loop as follows. > > > > > > Sorry, this doesn't show me where the loop actually is. Please compile > > > without the optimizer, otherwise code reordering confuses the debugger. > > > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). > > > > The loop is is inside find_tags(), and it procees around following line > > numbers: > > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 > > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 > > and infinite loop repeats. Look at this: > >gdb> print print search_info.curr_offset > > $2 = 5258708303049 > > I cannot guess where this loop first gets beyond end of file > (filesize=2506), but once it gets beyond, we are missing check that > search_info.*offset''s are beyond end of file ? > Maybe add such check somewhere ? I don't know where to add the check. > > Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Thi screenshot did not who intormation rght. It shoudl look (gdb) b tag.c:1651 Breakpoint 1 at 0x81a5032: file tag.c, line 1651. (gdb) cont Continuing. Breakpoint 1, find_tags (pat=0x827b538 "[EMAIL PROTECTED]", num_matches=0xbff0696c, matchesp=0xbff06968, flags=40, mincount=1, buf_ffname=0x0) at tag.c:1651 1651search_info.match_offset = ftell(fp); (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.match_offset $1 = 10763188046282 (gdb) p ftell(fp) $2 = 2506 (gdb)
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > > > Yakov Lerner wrote: > > > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > > > involving tags break, including the help system. Typing :h, > > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > > > infinite loop. > > > > > > [...] > > > > > > > > Can you find out where in the code this happens? > > > > > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > > > functions. Perhaps fgets(), since that's what is being used to read the > > > > > tags file. > > > > > > > > In situation where fgets() returns NULL, find_tags() enters > > > > infinite loop as follows. > > > > > > Sorry, this doesn't show me where the loop actually is. Please compile > > > without the optimizer, otherwise code reordering confuses the debugger. > > > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). > > > > The loop is is inside find_tags(), and it procees around following line > > numbers: > > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 > > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 > > and infinite loop repeats. Look at this: > >gdb> print print search_info.curr_offset > > $2 = 5258708303049 > > I cannot guess where this loop first gets beyond end of file > (filesize=2506), but once it gets beyond, we are missing check that > search_info.*offset''s are beyond end of file ? > Maybe add such check somewhere ? I don't know where to add the check. > > Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Ok, this must be gcc bug. It bites even without optimization. Rewriting lines 'search_info.curr_offset = ftell(fp)' fixes the problem if I rewrite them into this: long ltmp; ltmp = ftell(fp); search_info.curr_offset = ltmp; NB that ftell() returns long. Type of search_info.curr_offset is long long when -D_FILE_OFFSET_BITS=64. Simpe asignment search_info.curr_offset = ftell(fp) puts trash into lhs. ftell(fp) by itself returns correct number. this is gcc 3.4.2 Fedora3 Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > > > Yakov Lerner wrote: > > > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > > involving tags break, including the help system. Typing :h, > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > > infinite loop. > > > > [...] > > > > > > Can you find out where in the code this happens? > > > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > > functions. Perhaps fgets(), since that's what is being used to read the > > > > tags file. > > > > > > In situation where fgets() returns NULL, find_tags() enters > > > infinite loop as follows. > > > > Sorry, this doesn't show me where the loop actually is. Please compile > > without the optimizer, otherwise code reordering confuses the debugger. > > > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). > > The loop is is inside find_tags(), and it procees around following line > numbers: > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 > and infinite loop repeats. Look at this: >gdb> print print search_info.curr_offset > $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov It seems I found the culprint. It is line 1651, search_info.match_offset = ftell(fp); (gdb) p ftell(fp) $11 = 2506 (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) p search_info.curr_offset $12 = 5258708302025 (gdb) Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote: On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: > > Yakov Lerner wrote: > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > > involving tags break, including the help system. Typing :h, > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > > infinite loop. > > [...] > > > > Can you find out where in the code this happens? > > > > > > I suspect the 64 bit library functions work different from the "normal" > > > functions. Perhaps fgets(), since that's what is being used to read the > > > tags file. > > > > In situation where fgets() returns NULL, find_tags() enters > > infinite loop as follows. > > Sorry, this doesn't show me where the loop actually is. Please compile > without the optimizer, otherwise code reordering confuses the debugger. > > At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb> print print search_info.curr_offset $2 = 5258708303049 I cannot guess where this loop first gets beyond end of file (filesize=2506), but once it gets beyond, we are missing check that search_info.*offset''s are beyond end of file ? Maybe add such check somewhere ? I don't know where to add the check. Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> > On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> > >
> > > Yakov Lerner wrote:
> > >
> > > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
> > > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
> > > > > > > involving tags break, including the help system. Typing :h,
> > > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an
> > > > > > > infinite loop.
> > >
> > > [...]
> > >
> > > > > Can you find out where in the code this happens?
> > > > >
> > > > > I suspect the 64 bit library functions work different from the
"normal"
> > > > > functions. Perhaps fgets(), since that's what is being used to read
the
> > > > > tags file.
> > > >
> > > > In situation where fgets() returns NULL, find_tags() enters
> > > > infinite loop as follows.
> > >
> > > Sorry, this doesn't show me where the loop actually is. Please compile
> > > without the optimizer, otherwise code reordering confuses the debugger.
> > >
> > > At least tell us if Vim hangs in tag_fgets() or in find_tags().
> >
> > The loop is is inside find_tags(), and it procees around following line
> > numbers:
> > 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
> > 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
> > and infinite loop repeats. Look at this:
> >gdb> print print search_info.curr_offset
> > $2 = 5258708303049
>
> And additionally:
> (gdb) print search_info
> $3 = {low_offset = 0, high_offset = 10526964844947, curr_offset =
5258708303049,
> curr_offset_used = 5258708303049, match_offset = 10763188046282,
> low_char = 0, high_char = 120}
>
But ftell(fp) prints sane value:
(gdb) print ftell(fp)
$4 = 2506
And filesize is OK, 2506
Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
> On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
> >
> > Yakov Lerner wrote:
> >
> > > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
> > > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
> > > > > > involving tags break, including the help system. Typing :h,
> > > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an
> > > > > > infinite loop.
> >
> > [...]
> >
> > > > Can you find out where in the code this happens?
> > > >
> > > > I suspect the 64 bit library functions work different from the "normal"
> > > > functions. Perhaps fgets(), since that's what is being used to read the
> > > > tags file.
> > >
> > > In situation where fgets() returns NULL, find_tags() enters
> > > infinite loop as follows.
> >
> > Sorry, this doesn't show me where the loop actually is. Please compile
> > without the optimizer, otherwise code reordering confuses the debugger.
> >
> > At least tell us if Vim hangs in tag_fgets() or in find_tags().
>
> The loop is is inside find_tags(), and it procees around following line
> numbers:
> 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
> 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
> and infinite loop repeats. Look at this:
>gdb> print print search_info.curr_offset
> $2 = 5258708303049
And additionally:
(gdb) print search_info
$3 = {low_offset = 0, high_offset = 10526964844947, curr_offset = 5258708303049,
curr_offset_used = 5258708303049, match_offset = 10763188046282,
low_char = 0, high_char = 120}
But ftell(fp) prints sane value:
(gdb) print ftell(fp)
$4 = 2506
Yakov
Re: Tags break when enabling large file support
On 9/14/06, Yakov Lerner <[EMAIL PROTECTED]> wrote:
On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
>
> Yakov Lerner wrote:
>
> > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
> > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
> > > > > involving tags break, including the help system. Typing :h,
> > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an
> > > > > infinite loop.
>
> [...]
>
> > > Can you find out where in the code this happens?
> > >
> > > I suspect the 64 bit library functions work different from the "normal"
> > > functions. Perhaps fgets(), since that's what is being used to read the
> > > tags file.
> >
> > In situation where fgets() returns NULL, find_tags() enters
> > infinite loop as follows.
>
> Sorry, this doesn't show me where the loop actually is. Please compile
> without the optimizer, otherwise code reordering confuses the debugger.
>
> At least tell us if Vim hangs in tag_fgets() or in find_tags().
The loop is is inside find_tags(), and it procees around following line
numbers:
1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566
1576 1582 1588 1601 1603 1604 1616 1619 1621 1625
and infinite loop repeats. Look at this:
gdb> print print search_info.curr_offset
$2 = 5258708303049
And additionally:
(gdb) print search_info
$3 = {low_offset = 0, high_offset = 10526964844947, curr_offset = 5258708303049,
curr_offset_used = 5258708303049, match_offset = 10763188046282,
low_char = 0, high_char = 120}
Re: Tags break when enabling large file support
On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > > > On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote: > > > > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything > > > > involving tags break, including the help system. Typing :h, > > > > or pressing ^] to jump to a tag, causes Vim to get caught in an > > > > infinite loop. [...] > > Can you find out where in the code this happens? > > > > I suspect the 64 bit library functions work different from the "normal" > > functions. Perhaps fgets(), since that's what is being used to read the > > tags file. > > In situation where fgets() returns NULL, find_tags() enters > infinite loop as follows. Sorry, this doesn't show me where the loop actually is. Please compile without the optimizer, otherwise code reordering confuses the debugger. At least tell us if Vim hangs in tag_fgets() or in find_tags(). The loop is is inside find_tags(), and it procees around following line numbers: 1625 1626 1642 1647 1650 1651 1652 1653 1562 1564 1566 1576 1582 1588 1601 1603 1604 1616 1619 1621 1625 and infinite loop repeats. Look at this: gdb> print print search_info.curr_offset $2 = 5258708303049 The difference must be related to fseek(). I don't see where search_info.curr_offset is first initialized, though. Breakpoint 1, find_tags (pat=0x827b570 "[EMAIL PROTECTED]", num_matches=0xbff9238c, matchesp=0xbff92388, flags=40, mincount=1, buf_ffname=0x0) at tag.c:1625 1625eof = tag_fgets(lbuf, LSIZE, fp); (gdb) p eof $1 = 1 (gdb) n 1626if (!eof && search_info.curr_offset != 0) (gdb) n 1642while (!eof && vim_isblankline(lbuf)) (gdb) n 1647if (eof) (gdb) n 1650state = TS_SKIP_BACK; (gdb) n 1651search_info.match_offset = ftell(fp); (gdb) n 1652search_info.curr_offset = search_info.curr_offset_used; (gdb) n 1653continue; (gdb) n 1562line_breakcheck(); /* check for CTRL-C typed */ (gdb) n 1564if ((flags & TAG_INS_COMP)) /* Double brackets for gcc */ (gdb) n 1566if (got_int || compl_interrupted) (gdb) n 1576if (mincount == TAG_MANY && match_count >= TAG_MANY) (gdb) n 1582if (get_it_again) (gdb) n 1588if (state == TS_BINARY) (gdb) n 1601else if (state == TS_SKIP_BACK) (gdb) n 1603search_info.curr_offset -= LSIZE * 2; (gdb) n 1604if (search_info.curr_offset < 0) (gdb) n 1616if (state == TS_BINARY || state == TS_SKIP_BACK) (gdb) n 1619search_info.curr_offset_used = search_info.curr_offset; (gdb) n 1621fseeko(fp, search_info.curr_offset, SEEK_SET); (gdb) n Breakpoint 1, find_tags (pat=0x827b570 "[EMAIL PROTECTED]", num_matches=0xbff9238c, matchesp=0xbff92388, flags=40, mincount=1, buf_ffname=0x0) at tag.c:1625 1625eof = tag_fgets(lbuf, LSIZE, fp); (gdb) n 1626if (!eof && search_info.curr_offset != 0) (gdb) n 1642while (!eof && vim_isblankline(lbuf)) (gdb)
Re: Tags break when enabling large file support
On 9/14/06, Bram Moolenaar <[EMAIL PROTECTED]> wrote:
Yakov Lerner wrote:
> On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
> > After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
> > involving tags break, including the help system. Typing :h,
> > or pressing ^] to jump to a tag, causes Vim to get caught in an
> > infinite loop.
> >
> > Is there another way to get large file support that works?
> > There's no ./configure argument to enable it, so I just added
> > the above macro definition flag in CFLAGS. The problem with
> > not having large file support is not that I need to edit files
> > larger than 2 GiB, but that ^X^F doesn't expand large files,
> > probably because stat() fails with EOVERFLOW.
> >
> > By the way, this problem was encountered on the following system:
> >
> > OS: Slackware Linux 10.2
> > Libc: 2.3.5
> > GCC: several versions: 3.3.6, 3.4.6, 4.1.1
> > Vim: several versions, including 7.0.0 and 7.0.101
>
> I also get infinite loop when I build vim with -D_FILE_OFFSET_BITS=64
> on FedoraCode 3.
>
> Applying 'strace -p' shows that vim is stuck searching for
> tag, see the trace below. Apparently some read() in vim
> does not have check for == 0 return value.
>
> Yakov
>
> [ here vim searches for tags in other file ... then ...]
> open("/home/lerner/.vim/doc/tags", O_RDONLY|O_LARGEFILE) = 3
> fstat64(3, {st_mode=S_IFREG|0644, st_size=2506, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0xb7fbf000
> read(3, ":Brightness\txterm16.txt\t/*:Brigh"..., 4096) = 2506
> _llseek(3, 0, [2506], SEEK_END) = 0
> _llseek(3, 0, [0], SEEK_SET)= 0
> _llseek(3, 0, [0], SEEK_SET)= 0
> read(3, ":Brightness\txterm16.txt\t/*:Brigh"..., 4096) = 2506
> read(3, "", 4096) = 0
> read(3, "", 4096) = 0
> read(3, "", 4096) = 0
> read(3, "", 4096) = 0
> read(3, "", 4096) = 0
> read(3, "", 4096) = 0
> infinite .
Can you find out where in the code this happens?
I suspect the 64 bit library functions work different from the "normal"
functions. Perhaps fgets(), since that's what is being used to read the
tags file.
In situation where fgets() returns NULL, find_tags() enters
infinite loop as follows.
(gdb) where
#0 0xe410 in ?? ()
#1 0xbff7bab0 in ?? ()
#2 0x0015 in ?? ()
#3 0xb7f7b000 in ?? ()
#4 0x00235573 in __write_nocancel () from /lib/tls/libc.so.6
#5 0x001dc57f in _IO_new_file_write () from /lib/tls/libc.so.6
#6 0x001db02b in _IO_new_do_write () from /lib/tls/libc.so.6
#7 0x001dba70 in _IO_new_file_overflow () from /lib/tls/libc.so.6
#8 0x001dd1ca in __overflow () from /lib/tls/libc.so.6
#9 0x001d351f in puts () from /lib/tls/libc.so.6
#10 0x080c2bcc in vim_fgets (
buf=0x8244a78
"xterm16fg_GroupName\txterm16.txt\t/*xterm16fg_GroupName*\n",
size=512,
fp=0x827c1f8) at fileio.c:5853
#11 0x08177494 in find_tags (pat=0x8244568 "[EMAIL PROTECTED]",
num_matches=0x14, matchesp=0x14, flags=40,
mincount=1, buf_ffname=0x0) at tag.c:1625
#12 0x08178b35 in do_tag (tag=0x81f1168 "[EMAIL PROTECTED]", type=1, count=1,
forceit=0, verbose=1)
at tag.c:548
#13 0x080a3b08 in ex_help (eap=0x827d1b0) at ex_cmds.c:5519
#14 0x080b1e72 in do_one_cmd (cmdlinep=0xbff7ce08, sourcing=0,
cstack=0xbff7ce80,
fgetline=0x80c1828 , cookie=0x0) at ex_docmd.c:2616
#15 0x080b3082 in do_cmdline (cmdline=0x0, getline=0x80c1828
, cookie=0x0, flags=0)
at ex_docmd.c:1098
#16 0x08113620 in nv_colon (cap=0xbff7d220) at normal.c:5150
#17 0x08116d2f in normal_cmd (oap=0xbff7d290, toplevel=1) at normal.c:1137
#18 0x080decee in main_loop (cmdwin=0, noexmode=0) at main.c:1154
#19 0x080e2077 in main (argc=20, argv=0x14) at main.c:934
(gdb) b tag.c:1626
Breakpoint 1 at 0x8177494: file tag.c, line 1626.
(gdb) cont
Continuing.
Breakpoint 1, find_tags (pat=0x8244568 "[EMAIL PROTECTED]", num_matches=0x1,
matchesp=0x1, flags=40,
mincount=1, buf_ffname=0x0) at tag.c:1626
1626if (!eof && search_info.curr_offset != 0)
(gdb) n
1625eof = tag_fgets(lbuf, LSIZE, fp);
(gdb) n
1626if (!eof && search_info.curr_offset != 0)
(gdb) n
1651search_info.match_offset = ftell(fp);
(gdb) n
1650state = TS_SKIP_BACK;
(gdb) n
1651search_info.match_offset = ftell(fp);
(gdb) n
1652search_info.curr_offset =
search_info.curr_offset_used;
(gdb) n
1860continue;
(gd
Re: Tags break when enabling large file support
On 9/14/06, Haakon Riiser <[EMAIL PROTECTED]> wrote:
After recompiling Vim with -D_FILE_OFFSET_BITS=64, everything
involving tags break, including the help system. Typing :h,
or pressing ^] to jump to a tag, causes Vim to get caught in an
infinite loop.
Is there another way to get large file support that works?
There's no ./configure argument to enable it, so I just added
the above macro definition flag in CFLAGS. The problem with
not having large file support is not that I need to edit files
larger than 2 GiB, but that ^X^F doesn't expand large files,
probably because stat() fails with EOVERFLOW.
By the way, this problem was encountered on the following system:
OS: Slackware Linux 10.2
Libc: 2.3.5
GCC: several versions: 3.3.6, 3.4.6, 4.1.1
Vim: several versions, including 7.0.0 and 7.0.101
I also get infinite loop when I build vim with -D_FILE_OFFSET_BITS=64
on FedoraCode 3.
Applying 'strace -p' shows that vim is stuck searching for
tag, see the trace below. Apparently some read() in vim
does not have check for == 0 return value.
Yakov
[ here vim searches for tags in other file ... then ...]
open("/home/lerner/.vim/doc/tags", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=2506, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7fbf000
read(3, ":Brightness\txterm16.txt\t/*:Brigh"..., 4096) = 2506
_llseek(3, 0, [2506], SEEK_END) = 0
_llseek(3, 0, [0], SEEK_SET)= 0
_llseek(3, 0, [0], SEEK_SET)= 0
read(3, ":Brightness\txterm16.txt\t/*:Brigh"..., 4096) = 2506
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
read(3, "", 4096) = 0
infinite .
:redraw vs Ctrl-L difference
I noticed that :redraw works differently from Ctrl-L in certain situations: 1) vim -u NONE :set laststatus=2 statusline ruler :help help" get some text 2) Let's cause some screen mispaininting, so we can test :redraw: :silent! !echo aaa " cause mispainted screen (this is ok) 3) :redraw " does not repaint anything :redraw :redraw " nope, does not repaint 4) Ctrl-L "finally, works Is it bug or feature, that :redraw does not repaint screen at step 3 ? Yakov
distributing experimental patches with vim ?
Vim patches submitted by external submitters are either 'incorporated' or 'outsude of vim sources'. That's black-and-white. I thought it's possible to add some intermediate state, where 'experimental-patch' is neither outside of vim nor inside-vim. This is useful because people can try experimental patches easier, with clear understandnig that they are trying experimental patches. It can work as follows. (BTW I think Vince Negri conceal patch deserves this status.) It can work as follows. Experimental patch is added as a _feature_ named 'x-*', say 'x-conceal'. It has it's #ifdef, FEAT_X_CONCEAL, and none of x-* features are built by 'huge' (largest) built. The builder needs to enable them manually with --enable-x-conceal or similar configure flag. To make it very clear that build includes experimental features, the :version will have line seen from large distance: CONTAINS EXPERIMENTAL FEATURES * But then more people can try these experimental patches and feedback on them, improve them, or report their uselessness. Yakov
Re: patch: automatically enter paste mode
On 9/13/06, Ian Kilgore <[EMAIL PROTECTED]> wrote:
Pasting code into vim and forgetting to set paste can have annoying
results. This patch detects the 'really fast typing' that happens when
something is pasted in, and turns on paste mode. It provides an option
'autopaste' (default false) which controls the behavior.
Patch is attached. Hope this is useful.
Nice. So simple. I have couple of comments.
1. Don't you need to reset 'paste' back to 'nopaste' when
high cps stops ?
2. It would be better if cps be settable, not hardcoded to 30.
Maybe value of 'autopaste' can be made the cps boundary
'set autopaste=30', value 0 disables ?
3. Regarding line do_set(&sPaste, 0); I think typical vim style
is to write do_set("paste", 0); then
char_u sPaste[] = "paste";
do_set(&sPaste, 0);
Yakov
Yakov
Re: Binary, Octal, Decimal, Hex!
On 9/12/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> Yakov Lerner wrote: >> >> > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: >> > >> >> It is fairly easy to check for inconsistencies in Binary, Octal, >> and Hex >> > I'm afraid C does not notion of binary numbers. >> On some systems that answer is correct. On others it is not. :-) > > > I'm aware of binary numbers in perl (0b101010101). But in C ? > What exactly is syntax of "binary numbers in C" ? How does it look ? > On which systems ? > I never heard of "binary numbers in C" ... > I am very curious to hear from you all details that you can provide. > What exactly are those systems and how exactly the syntax looks ? > > Yakov > ... Still, I'm not going to rack my brain for exactly which system and where Don't bother. C standard does not have binary numbers. (I'm sorry to disappoint you but B, immediate predecessor of C, did not have binary numbers, too). Yakov
Re: testing patchlevel from script
On 9/11/06, Nikolai Weibull <[EMAIL PROTECTED]> wrote:
On 9/11/06, A.J.Mechelynck <[EMAIL PROTECTED]> wrote:
[a way to create a list of what patches has been applied]
Here's a simpler version of that script that doesn't allow for patches
to be skipped. I don't know if the Vim build scripts actually allow
for patches to be skipped,
Yes it is allowed.
... and considering that later patches will
often depend on earlier ones, I can't see any reason why someone
wouldn't have applied patch i when they have applied patch j, where i
< j.
" Vim plugin file
" Maintainer: Nikolai Weibull <[EMAIL PROTECTED]>
" Latest Revision: 2006-09-11
if exists("g:patches")
finish
endif
let s:i = 1
let g:patches = [0]
while has("patch" . s:i)
call add(g:patches, s:i)
let s:i += 1
endwhile
unlet s:i
let g:version_string = (version / 100) . '.' . (version % 100) . '.' .
g:patches[-1]
I'd prefer
let g:full_version = version . sprintf("%03d", g:patches[-1])
because such version string is comparable for (<,<=,>,>=)
whereas g:full_version is not.
I'd consider patchlevel to be max # of hole-free sequence
of patches starting from 1 (I think patch numbers are 1-starting),
*not* max # of patch applied. The extreme example would be
single patch#100 applied (without patches 1-99) which does
*not* make patchlevel 100.
Yakov
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: Yakov Lerner wrote: > On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: > >> It is fairly easy to check for inconsistencies in Binary, Octal, and Hex > > > I'm afraid C does not notion of binary numbers. > > Yakov > On some systems that answer is correct. On others it is not. :-) I'm aware of binary numbers in perl (0b101010101). But in C ? What exactly is syntax of "binary numbers in C" ? How does it look ? On which systems ? I never heard of "binary numbers in C" ... I am very curious to hear from you all details that you can provide. What exactly are those systems and how exactly the syntax looks ? Yakov
Re: Binary, Octal, Decimal, Hex!
On 9/11/06, Mark Manning <[EMAIL PROTECTED]> wrote: It is fairly easy to check for inconsistencies in Binary, Octal, and Hex I'm afraid C does not notion of binary numbers. Yakov
winrestview() after PageDown
I see a case in which winrestview() work incorrectly after PageDown
near end-of-file. (This is in the context of scrollfix plugin.)
To reproduce:
% vim -u NONE -c 'so x.vim'# x.vim is below
:help help" have some text
:set nu" see line numbers
press seevral ArrowDown to see how x.vim works, works OK, cursor is on 5th line
G OK, cursor is on 5th line
-- now this seems to be a bug, cursor is at top line instead of 5th line
:echo g:last " g:last shows how the last winrestview() was performed
{'lnum': 7336, 'leftcol': 0, 'col': 1, 'topfill': 0, 'topline': 7332,
'coladd': 0, 'skipc
ol': 0, 'curswant': 1}
NB: 'topline' is 7332 but winrestview() incorrectly ignored the 'topline'.
The same wrong behaviour can be observed even with small 3-line file.
Yakov
-- x.vim -
:let g:scroll_fix=5
:let so=0
aug scrollfix
au!
au CursorMoved * :call ScrollFix()
aug END
function! ScrollFix()
if g:scroll_fix==0 | return | endif
if &so!=0 | set so=0|endif
" keep cursor on fixed visual line of the window
let dict = winsaveview()
if dict['lnum'] <= g:scroll_fix | return | endif
if dict['lnum'] - dict['topline'] + 1 == g:scroll_fix | return | endif
let dict['topline'] = dict['lnum'] - g:scroll_fix + 1
let g:last = dict
call winrestview(dict)
endfunction
-
