Re: breakindent, take 2

[Yakov Lerner]

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: breakindent, take 2

[Yakov Lerner]

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

[Yakov Lerner]

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-devm=109921292009721w=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: breakindent, take 2

[Yakov Lerner]

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-devm=109921292009721w=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: Proposal: adding an extra hook into vim's search

[Yakov Lerner]

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 expr' 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: A performance question (patch included)

[Yakov Lerner]

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 {fname}.
+   If unitsize is given, then the file {fname}'s 

Re: Proposal: adding an extra hook into vim's search

[Yakov Lerner]

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 expr' 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 silentf2 :call ToggleSpecialSpaceSearch()cr
cnoremap exprf2 (ToggleSpecialSpaceSearch())
func! ToggleSpecialSpaceSearch()
   if exists('g:my_search')  g:my_search
   cunmap space
   let g:my_search=0
   echo 'space in search normal'
   else
   cnoremap exprspace
(getcmdtype()=='/'\|\|getcmdtype()=='?'?'\_s\+':' ')
   let g:my_search=1
   echo 'space in search special'
   endif
   return ''
endfun


Yakov

Re: [Announcement] Subversion repository location changed

[Yakov Lerner]

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

Vim version 7.1a BETA -- runtime files ?

[Yakov Lerner]

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 -- runtime files ?

[Yakov Lerner]

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

Re: Vim version 7.1a BETA -- runtime files ?

[Yakov Lerner]

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

[Yakov Lerner]

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

[patch] search() flag to not use smartcase

[Yakov Lerner]

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: [patch] search() flag to not use smartcase

[Yakov Lerner]

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

Re: wish: show search progress on slow searches

[Yakov Lerner]

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 (M10), then we adjust N by increasing it.
  If M is too low(M10), 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: wish: show search progress on slow searches

[Yakov Lerner]

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 (M10), then we adjust N by increasing it.
 If M is too low(M10), 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

[Yakov Lerner]

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 (M10), then we adjust N by increasing it.
If M is too low(M10), 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

[Yakov Lerner]

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?

[Yakov Lerner]

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: replace VimScript (was: wish: allow a: in the function def)

[Yakov Lerner]

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

Re: replace VimScript (was: wish: allow a: in the function def)

[Yakov Lerner]

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: coredump with match by lines-range (7.0.222); highlighting is not painted fully.

[Yakov Lerner]

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 \%123l   \%123l, in addition to ==N, the \%123l).
Or is there other way to highlight block of lines ?

Thanks

wish: collaboration of N vim instances editing same file

[Yakov Lerner]

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

todo? (setting eol/noeol after :r !cmd ? )

[Yakov Lerner]

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: crash due to -fstack-protector false positive

[Yakov Lerner]

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

[Yakov Lerner]

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(regstack, 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(regstack, 1, 1);
 +ga_init2(regstack, 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

wrong direction of 'n' -- when #,n are remapped and inside function

[Yakov Lerner]

In the script below, where # and n are remapped,
n goes the wrong direction after #. To see:
   vim -u NONE bad.bim
   :so %
   gg/bacrnnn#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('#')cr
nnoremap n :call Foo('n')cr

func! Foo(cmd)
  silent! exe norm!  . a:cmd
endfun

 test sequence: gg/bacrnnn#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! #cr
nnoremap n :silent! exe norm! ncr

 test sequence: gg/bacrnnn#n
 expected: last 'n' to go backwards
 actual  : ok

Re: avoiding unneeded buffer scrolling

[Yakov Lerner]

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

Re: gVim 7 Win32 Maximize bug report

[Yakov Lerner]

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: gVim 7 Win32 Maximize bug report

[Yakov Lerner]

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: syntax region match with braces

[Yakov Lerner]

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=\script\\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=\script\\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=\script\...
This seems less probale because you say that beginning of edcScript
region matches correctly.

Yakov

Re: escape() and '

[Yakov Lerner]

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

the plugin startup check

[Yakov Lerner]

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

Re: the plugin startup check

[Yakov Lerner]

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

svn vs rsync vs ftp

[Yakov Lerner]

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: feature request: don't write backup if the file is unmodified

[Yakov Lerner]

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 c-R=(getcmdtype()==':'  getcmdpos()==1 ? 'up' : 'w')cr

Yakov

Re: :diffsplit | verbose set fdm?

[Yakov Lerner]

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 manually 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: :diffsplit | verbose set fdm?

[Yakov Lerner]

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 manually 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: [PATCH] cygwin: Trouble recognizing absolute path

[Yakov Lerner]

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

long echomsg + 'set shortmess+=T' + norm-vs-without-norm

[Yakov Lerner]

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)cr
3.
Press ZB. You get long message and 'Press Enter' prompt.
4.
Type
:norm ZBcr
You get shortened message, and no ''Press Enter' prompt.
5.
Type
:echomsg repeat('a',co+10)cr
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

usability suggestion: 'viminfo'

[Yakov Lerner]

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: usability suggestion: 'viminfo'

[Yakov Lerner]

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

Re: vim -u NONE

[Yakov Lerner]

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: vim -u NONE

[Yakov Lerner]

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: Missing CursorHold after return from insert to normal ?

[Yakov Lerner]

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. C-EC-EC-E  -- watch CursorHold working
 5. iiesc  wait  there's not CursorHold
 iiesc  wait  there's not CursorHold
 iiesc  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 ?

[Yakov Lerner]

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. C-EC-EC-E  -- watch CursorHold working
5. iiesc  wait  there's not CursorHold
   iiesc  wait  there's not CursorHold
   iiesc  wait  there's not CursorHold

Why ? Bug or feature ?

Yakov

Re: Time to remove naming restrictions?

[Yakov Lerner]

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

Re: Autocommand-Event for Clipboard-Changed

[Yakov Lerner]

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

CursorHold when cursor is in command-line

[Yakov Lerner]

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
commandline 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: Searching for selected text

[Yakov Lerner]

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

[Yakov Lerner]

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 expr * SIDVisualSearch('*')
vnoremap expr # SIDVisualSearch('#')


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

Re: Searching for selected text

[Yakov Lerner]

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: no winclose event

[Yakov Lerner]

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: patch: automatically enter paste mode

[Yakov Lerner]

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 F5 ...' or 'imap F5 ...' 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

:redraw vs Ctrl-L difference

[Yakov Lerner]

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

Re: Tags break when enabling large file support

[Yakov Lerner]

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 .

Re: Tags break when enabling large file support

[Yakov Lerner]

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 getexline, cookie=0x0) at ex_docmd.c:2616
#15 0x080b3082 in do_cmdline (cmdline=0x0, getline=0x80c1828
getexline, 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;
(gdb) n
1652search_info.curr_offset =
search_info.curr_offset_used;
(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
1588

Re: Tags break when enabling large file support

[Yakov Lerner]

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

[Yakov Lerner]

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

[Yakov Lerner]

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

[Yakov Lerner]

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

[Yakov Lerner]

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)

distributing experimental patches with vim ?

[Yakov Lerner]

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

winrestview() after PageDown

[Yakov Lerner]

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

Re: Binary, Octal, Decimal, Hex!

[Yakov Lerner]

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

Re: Binary, Octal, Decimal, Hex!

[Yakov Lerner]

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: testing patchlevel from script

[Yakov Lerner]

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!

[Yakov Lerner]

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

extraHuge build size (= huge + intepreters)

[Yakov Lerner]

This patch adds 'extrahuge' build size, which is
huge+interpreters (spelled as --with-features=extrahuge
or --with-features=allinterp).

Yakov

P.S. Maybe --with-features=max is better name.


patch-extrahuge
Description: Binary data

Re: The c.vim file

[Yakov Lerner]

On 9/10/06, Mark Manning [EMAIL PROTECTED] wrote:

In the syntax stuff, the c.vim file should be changed to have the following:

Old:

syn regioncStringstart=++ skip=+\|\\+ end=++
contains=cSpecial


New

syn regioncStringstart=++ skip=+\||'+ end=++
contains=cSpecial
syn regioncStringstart=+'+ skip=+\|\\\'\|+ end=+'+
contains=cSpecial

This would take care of the ..'. problem and the '' problem


Hmmm both  ..'. and  '' are handled
correctly for me with existing C syntax. Which
$VIMRUNTIME/syntax/c.vim version
is yours ?

Yakov

Re: Update on the update

[Yakov Lerner]

On 9/11/06, Mark Manning [EMAIL PROTECTED] wrote:

 (If I
put in echo version it comes back as 700.  Even the 7.0.17 version
comes back as 700


Output of ':echo version' does not reflect patchlevel. (the .17 in
7.0.17 is patchlevel).
You can see the patchlevel on the initial splashscreen, or
in the output of :version (look at 'Included patches' line, 2nd line). (The
latter is same as 'vim --version).

Yakov

Re: New question

[Yakov Lerner]

On 9/11/06, Mark Manning [EMAIL PROTECTED] wrote:

Hey, I hate to keep barging in here asking questions and such but here
is a new one.  :-)

In the new basic.vim file I am having a problem.  In FreeBasic you can
use both single as well as double quotes to enclose a string.
Unfortunately, you can also have comments which start with a single
quote.  So far I can capture and highlight correctly these three conditions:

1. REM Comment
2. Spaces'Comment
3. :SpacesComment

What I can not get is the:

1. 'Comment

Like so:

test.bas
rem This is a comment
'   This is a comment
:   '   This is a comment
'   This is a comment too but it doesn't properly highlight.  Instead,
it thinks it is a string.
end

Here are my commands:

Comments
syn matchbSpecialcontained \\.
syn region  bCommentstart=^rem end=$ contains=bSpecial,bTodo
syn regionbCommentstart=:\s*' end=$ contains=bSpecial,bTodo
syn regionbCommentstart=^\s*' end=$ contains=bSpecial,bTodo

 String and Character contstants
syn regionbStringstart='' end='' contains=bSpecial,bTodo
syn regionbStringstart=' end=' contains=bSpecial,bTodo

Suggestions?


Try to reverse order of statements, putting Comment after String. The
last one takes precedence, and you want Comment to take precedence
over string. Like this:

 String must go before Comments
 String and Character contstants
syn regionbStringstart='' end='' contains=bSpecial,bTodo
syn regionbStringstart=' end=' contains=bSpecial,bTodo

Comments
syn matchbSpecialcontained \\.
syn region  bCommentstart=^rem end=$ contains=bSpecial,bTodo
syn regionbCommentstart=:\s*' end=$ contains=bSpecial,bTodo
syn regionbCommentstart=^\s*' end=$ contains=bSpecial,bTodo

Yakov

Re: New question

[Yakov Lerner]

-- Forwarded message --
From: Mark Manning [EMAIL PROTECTED]
Date: Sep 11, 2006 1:43 AM
Subject: Re: New question
To: Yakov Lerner [EMAIL PROTECTED]


Ok, tried it and it works!  :-)

Thanks!  :-)

Mark

Re: Possible addition to the c.vim and perl.vim syntax files

[Yakov Lerner]

On 9/11/06, Mark Manning [EMAIL PROTECTED] wrote:

I saw in the c.vim that there was an error statement for octal numbers.
There isn't one for hex numbers so I made one really quickly.  If you
want, just put it into the c.vim file.  :-)

The test:

syn regioncHexErrorstart=0x\x*[g-zG-Z] end=\W

The highlight command:

hi link   cHexError   cError

Of course, this needs to be approved by Bram first though.  :-)


Good idea. But then, why not to add error syntax for decimal numbers ?
I think it is also not present.

Yakov

RFC: bigger '--with-features' than huge (incl interpreters)

[Yakov Lerner]

Hello,

The biggest build size that exists now (the --with-features) is 'huge'.
This 'huge' still does not include interpreters.

What does public and Bram think about adding another build size
('extra-huge') that includes [all] interpreters ?
What is your feeback ?

Yakov

Possible namings: 'all', 'jumbo', 'giant', 'everything', 'huge+interp',
 'xxl', 'colossal', 'tremendous', 'gigantic',
'enormous',
 'ohmygod', 'extra-huge'

My reasoning behind 'xxl' is this: current build sizes are {tiny,
small, normal, big, huge}.
'Big' is like  'large'. Thus 'huge' (next grade after big/large)
corresponds to 'xl'
(extra large). Then next grade after huge/xl is xxl. Then it is easy to
add xxxl, l, etc.

Re: Hello! Well Met! And a possible bug. :-)

[Yakov Lerner]

On 9/8/06, Mark Manning [EMAIL PROTECTED] wrote:

I believe I may have found an obscure bug.  It is not a harmful bug.  It
does not make VIM crash or do weird things.  (Well, sort-of.)  :-)

Here is how to reproduce it:

First you have to have a lot of open and close braces (}).  They
do not have to be on the same line and in fact, this bug shows up better
if they are on separate lines.  For example:  This happened while I was
writing some Perl code and I had a lot of IF statements with their
trailing braces.  These were inside of a subroutine so the last line of
the subroutine is, of course a brace.  There were lots of subroutines
and I was cleaning up code by separating out the subroutines into
separate files.  So my code originally looked like this:

main
.
.
.
sub a
{
if(){
   if(){
   }
}
}

sub b
{
more stuff
if(){
   if(){
   }
}
}

and so on...

Ok.  So the problem happens when you delete sub b and then hit the
dd key to delete the blank line between sub a's ending close brace
and where sub b's starting line was.  When you do this VIM pops up
onto the end of the brace for sub a.  The thing is, is that the cursor
isn't _on_ the close brace - it is next to the close brace.  So if you
then do a % VIM pops to the middle of the file rather than to the open
brace like it should do.  (ie: Match braces.)

Like I said - it's not a terrible problem, it doesn't crash VIM, it's
just a what the heck!? kind of thing and it took me a while to realize
that I was not doing something myself wrong and that it had more to do
with how VIM treated the deletion of the other line and where it put the
cursor afterwards.

However, this also brings up the next thing.  If, after deleting the
blank line you type the $ key, the curse will pop to the correct
location (ie:on the close brace).  Does this mean that the cursor is
actually beyond the end of the line at that point?  Could this cause
other problems with VIM?

Anyway, just a short note.  Other than this, VIM works fine.  Here is my
system information:

Two separate versions of VIM are doing this.

Version #1 of VIM:
VIM v6.1
Windows XP Pro
512MB of memory
250GB hard drive (lots of space)
Editing standard text files.

Version #2 of VIM:
Vim v7.0.1
Cygwin via Windows XP Pro
Same system so same everything else.



I tried what you describe in vim7.0.91, and the cursor is
right on the closing brace after dd, not after.
Maybe you should upgdare to the latest vim7.

Yakov

Re: screen update problem during periodic file refresh

[Yakov Lerner]

On 9/7/06, Bram Moolenaar [EMAIL PROTECTED] wrote:


Yakov Lerner wrote:

 I see several problems (that I can't explain) in the vim refresh-loop
 watching the growing file (a-la 'tail -f'). Vim commands are below.

 Problem #1: There is unexpected output on the bottom line
   (lines of the file is echoed on the bottom line). Why ?
 Problem #2: When you vertically resize the xterm window,
   vim screen is corrupted and never repainted properly.
 Problem #3: Sometimes, when I press Ctrl-C to quit the loop,
   vim is in ex mode and responds 'Type  :quitEnter
 to exit Vim'
   Why ?
 Problem #4: Since vim repaints properly when waiting for chars, I'd like
   to put getchartimeout(1000) in place of sleep 1. Do we
   have getchar() with timeout ?

 To see the demonstration:

 1. In one window, create growing file using these shell command:

   % while :; do date 1; sleep 1; done

 2. In another window:

   vim -u NONE ~/xxx
   :set nolz | while 1 | e | redraw | $ | sleep 1 | endw

notice unexpected output on the bottom line
try to resize screen. It is not restored properly.
Press Ctrl-C to quit. Sometimes, vim quits the loop properly.
Sometime, vim does not quit the loop, stays in ex mode.
(Type  :quitEnter  to exit Vim)

 (This command sequence must be not perfect but it demonstrates the problem).

I can see the extra output on the bottom line.  I'll look into this
later.

How do you see the problem with the screen resize?


Originally, lines is around 50. Screenshot before resize is

http://www.wikiupload.com/download_page.php?id=16428
   (before-resize.gif). This is normal screen.

Here is how I resize: I resize screen height down to 10.
Then I resize height back to approximately original height.
Here is screenshot after resize
(I also give it several seconds of time, but it never really recovers):

http://www.wikiupload.com/download_page.php?id=16429
(after-resize.gif). It's different every time, but always screwed.

Yakov

Re: screen update problem during periodic file refresh

[Yakov Lerner]

On 9/7/06, Yakov Lerner [EMAIL PROTECTED] wrote:

On 9/7/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Yakov Lerner wrote:

  I see several problems (that I can't explain) in the vim refresh-loop
  watching the growing file (a-la 'tail -f'). Vim commands are below.
 
  Problem #1: There is unexpected output on the bottom line
(lines of the file is echoed on the bottom line). Why ?
  Problem #2: When you vertically resize the xterm window,
vim screen is corrupted and never repainted properly.
  Problem #3: Sometimes, when I press Ctrl-C to quit the loop,
vim is in ex mode and responds 'Type  :quitEnter
  to exit Vim'
Why ?
  Problem #4: Since vim repaints properly when waiting for chars, I'd like
to put getchartimeout(1000) in place of sleep 1. Do we
have getchar() with timeout ?
 
  To see the demonstration:
 
  1. In one window, create growing file using these shell command:
 
% while :; do date 1; sleep 1; done
 
  2. In another window:
 
vim -u NONE ~/xxx
:set nolz | while 1 | e | redraw | $ | sleep 1 | endw
 
 notice unexpected output on the bottom line
 try to resize screen. It is not restored properly.
 Press Ctrl-C to quit. Sometimes, vim quits the loop properly.
 Sometime, vim does not quit the loop, stays in ex mode.
 (Type  :quitEnter  to exit Vim)
 
  (This command sequence must be not perfect but it demonstrates the problem).

 I can see the extra output on the bottom line.  I'll look into this
 later.

 How do you see the problem with the screen resize?

I am  trying now to ':call getchar(0)' near 'sleep 1',
and with this addition, screen resizes properly.
Like this:

:set nolz | while 1 | e | redraw | $ | call getchar(0) | sleep 1 | endw


Correction, this should have been getchar(1) not getchar(0).
Addition of getchar(1) also handles resizes properly.

Yakov

'acd' + :file, 'acd' : +saveas

[Yakov Lerner]

Giving buffer new name in different directory does not change
to new directory, when 'acd' is set. This does not sound right,
taking into account that switching buffers to and back makes
current directory right.

To reproduce:
% vim -u NONE ~/xxx
:set acd
:he acdto have 2nd buffer
Ctrl-Wdown  back to ~/xxx
:file /tmp/1
:pwd wrong current dir, we expect /tmp
Ctrl-WupCtrl-Wdown  now pwd becomes right
 same happens with :saveas instead of :file
:saveas /var/tmp/2
:pwd wrong current dir, we expect /tmp
Ctrl-WupCtrl-Wdown  now pwd becomes right

Bug or feature ?

Yakov

winrestview() + 'showcmd'

[Yakov Lerner]

I see erratic screen redraw (namely, curshor shown
past last line of file, or on wrong line (which is not line('.'))).
This vim 7.0.86 taken from svn today, including recent
fix to winrestcmd().

It happens after certain winrestview() when 'showcmd' is set.
This code works ok with 'noshowcmd'. (It took me a while to
track this down to 'showcmd' option specifically. The
context of this code is, I want to make scrollfix plugin which
locks cursor at Nth visual line, Nth line from top of screen).

To reproduce:

1. First, let's see how it works ok
 vim -u NONE -c 'so x.vim' x.vim
 press Down to end of file to see how it works ok.
 G gg G gg   works ok

2. With 'showcmd', same code works very differently:

 vim -u NONE -c 'so x.vim' x.vim
 :set showcmd  this turns on the problem
 :set nu ruler statusline= laststatus=2 this to watch the
  line number mismatch
  press Down repeatedly till eof
  BUG1: notice cursor draw past eof
  Up
  BUG2:  now notice the cursor is in line 25 but
  ':echo line(.)' shows line 26
  ggG
  BUG3: Now cursor is totally off-limits

Note that ':echo g:last' allows to see the dict
used in last winrestview() thanks to 'let g:last = dict'
line in x.vim.

Yakov
- x.vim --
:let g:scroll_fix=5  fix cursor fixed at fixed Nth visual line
:let so=0

aug scrollfix
   au!
   au CursorMoved * :call ScrollFix()
aug END

function! ScrollFix()
   if g:scroll_fix==0 | return | 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  for debugging
   call winrestview(dict)
endfunction

Re: Syntax matching. extend inside normal inside keepend

[Yakov Lerner]

On 9/3/06, Ilya [EMAIL PROTECTED] wrote:

Yakov Lerner wrote:
 When I removed both 'keepend' and 'extend', it
 started to work as expected.
No, it would not work as I want it to.  Block would not end unclosed
String.  Like this:
{ Some string with a quote (  ) inside }


Ah, I have a guess what can be the problem. Maybe
region does not like it when ending pattern ([]) is same as
beginning pattern. It does not know then whether to treat 2nd
double-quote as a  beginning of new nested
region (string), or end of previous block (string).

Maybe you should try
'syn match' for both strings and identifiers.
(nested 'syn match'). Maybe you should look into perl.vim
how it does it.

Yakov

Re: Syntax matching. extend inside normal inside keepend

[Yakov Lerner]

On 9/2/06, Ilya [EMAIL PROTECTED] wrote:

Hello.

I have a question regarding syntax matching.  I have some kind of syntax
and I have some solution to highlight it, but it does not work the way I
expect it to.

What I want:  match syntax that consists of blocks (enclosed in {}),
strings (enclosed in ) and identifiers (starts with ${ and ends with
}).  Block end should also end any string that starts inside this block.

My solution:

:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend


 Your 'keepend' option clearly causes '}' which is end of
identifier to terminate the enclosing block, in full accordance
with :help syn-keepend.
 If I read ':help syn-keepend' right, then 'keepend' does not
allow a region on which it is used to have proper subregions.

Yakov

Re: Syntax matching. extend inside normal inside keepend

[Yakov Lerner]

On 9/3/06, Ilya [EMAIL PROTECTED] wrote:

Yakov Lerner wrote:
 When I removed both 'keepend' and 'extend', it
 started to work as expected.
No, it would not work as I want it to.  Block would not end unclosed
String.  Like this:
{ Some string with a quote (  ) inside }


What about the following example:
  {
  1 }
  { 
  }
Do you want to distinguish mismatched double-quotes
within one line only, or across multiple lines ? As you
syntax is currently written, your intention is ambiguoius.
On one hand, your 'syntax region String' can span multiple lines.
On other hand, you want that '}' inside quoted string terminate a block.

  Do you want to consider line ' 1 }' a line with
mismatched quote, or it's supposed to match quote on
after ' {' ? NB that your 'syntax region String' does allow
strings spanning multilpe lines.

Yakov

Re: Syntax matching. extend inside normal inside keepend

[Yakov Lerner]

On 9/3/06, Ilya [EMAIL PROTECTED] wrote:

Yakov Lerner wrote:
 On 9/2/06, Ilya [EMAIL PROTECTED] wrote:
 Hello.

 I have a question regarding syntax matching.  I have some kind of syntax
 and I have some solution to highlight it, but it does not work the way I
 expect it to.

 What I want:  match syntax that consists of blocks (enclosed in {}),
 strings (enclosed in ) and identifiers (starts with ${ and ends with
 }).  Block end should also end any string that starts inside this block.

 My solution:

 :syn cluster Top contains=Block,String,Identifier
 :syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
 :syn region String start=++ end=++ contains=Identifier
 :syn region Identifier start=+\${+ end=+}+ extend

  Your 'keepend' option clearly causes '}' which is end of
 identifier to terminate the enclosing block, in full accordance
 with :help syn-keepend.
No, it does not because of an extend option. Here is a picture (I've
already included it in my previous mail):
{ string ${var} string }
BB
  SS   SS
  II
B - Block region
S - String region
I - Identifier region

I got this information using synID function.
  If I read ':help syn-keepend' right, then 'keepend' does not
 allow a region on which it is used to have proper subregions.
Except for 'extend' regions.  That is why Block is 'keepend' and 'extend'.


What if  'extend'  can override only the 'keepend' of only
immediately enclosing region ? The example in :help syn-extend
only has examlpe of overriding 'keepend' of immediately containing
region. Does not say whether 'extend' acts all the way up
the stack of enclosing regions.

Yakov

Re: Syntax matching. extend inside normal inside keepend

[Yakov Lerner]

On 9/2/06, Ilya [EMAIL PROTECTED] wrote:

Hello.

I have a question regarding syntax matching.  I have some kind of syntax
and I have some solution to highlight it, but it does not work the way I
expect it to.

What I want:  match syntax that consists of blocks (enclosed in {}),
strings (enclosed in ) and identifiers (starts with ${ and ends with
}).  Block end should also end any string that starts inside this block.

My solution:

:syn cluster Top contains=Block,String,Identifier
:syn region Block start=+{+ end=+}+ keepend extend [EMAIL PROTECTED]
:syn region String start=++ end=++ contains=Identifier
:syn region Identifier start=+\${+ end=+}+ extend

Here is a sample that shows that this solution does not work:

{
  string ${var} string
}

For some reason an Identifier region ends a String region and a second
word 'string' is not highlighted as a string (and Vim says that it has
Block match there).

Question: why the String region is not restored after the Identifier
region ends?


When I removed both 'keepend' and 'extend', it
started to work as expected.

With ''kepend extend', it
apparently takes identifier-closing brace for a
block-closing brace. I don't know why.

You might also try another solution: the 'syn match'
for identifier  instead of region.

Yakov

Re: session-file problem in presence of 'set acd'

[Yakov Lerner]

On 9/1/06, Bram Moolenaar [EMAIL PROTECTED] wrote:


Yakov Lerner wrote:

 When 'acd' is set, 'vim -S' open files in wrong directory.
 To reproduce:

 1. make your ~/.vimrc 1-liner 'set acd'
(Alternatively, use use vim -u NONE -c 'set acd' instead of vim
 in commands below).
 2. vim ~/xxx# or
 :he options.txt
  now you have two files open: (1) ~/xxx (2)
 $VIMRUNTIME/doc/options.txt
 :mksession! /tmp/3
 :q!
 3. vim -S /tmp/3
 4. You'll see that buffer 'options.txt' is empty.
 ':pwd' in window of options.txt shows that current directory is incorrect.

 The problem is that ':edit' commands in session-file do not
 contain full paths. Incomplete paths do not work when 'acd' is set.
 Here are relevant lines from sessionfile, the /tmp/3:

cd /usr/local/share/vim/vim70/doc
edit ~/xxx
edit options.txt

 This (3rd line)does not work with 'set acd'. I think all filenames
 must be with full path like

edit ~/xxx
edit /usr/local/share/vim/vim70/doc/options.txt

Don't keep 'autochdir' set all the time, some things won't work.


Hmmm why, I always been having 'set acd' in my .vimrc for years;
and everyhing works just fine. It's convenient. I never had problems.

I also have equivalent lcd autocmd (in .vimrc) in case autocd
is not compiled in. It's convenient.


I'll see if the option can be switched off in the session file until the
very end, that should help.


Yakov

session-file problem in presence of 'set acd'

[Yakov Lerner]

When 'acd' is set, 'vim -S' open files in wrong directory.
To reproduce:

1. make your ~/.vimrc 1-liner 'set acd'
  (Alternatively, use use vim -u NONE -c 'set acd' instead of vim
in commands below).
2. vim ~/xxx# or
:he options.txt
now you have two files open: (1) ~/xxx (2)
$VIMRUNTIME/doc/options.txt
:mksession! /tmp/3
:q!
3. vim -S /tmp/3
4. You'll see that buffer 'options.txt' is empty.
':pwd' in window of options.txt shows that current directory is incorrect.

The problem is that ':edit' commands in session-file do not
contain full paths. Incomplete paths do not work when 'acd' is set.
Here are relevant lines from sessionfile, the /tmp/3:

  cd /usr/local/share/vim/vim70/doc
  edit ~/xxx
  edit options.txt

This (3rd line)does not work with 'set acd'. I think all filenames
must be with full path like

  edit ~/xxx
  edit /usr/local/share/vim/vim70/doc/options.txt

Yakov

Re: vim mailing lists

[Yakov Lerner]

On 8/30/06, Bram Moolenaar [EMAIL PROTECTED] wrote:


Benji Fisher wrote:

 On Sun, Aug 27, 2006 at 02:40:24PM +0200, Bram Moolenaar wrote:
 
  Apparently the sorbs blacklist mechanism is still being used, causing
  trouble for some people.  I have asked the mail server maintainer to
  remove sorbs a few times now...

  Twice recently, sorbs has bounced my mails to the list because some
 server between my ISP and the vim-dev list is on its blacklist.

  Do you have any plans to move the vim mailing lists to a new
 server, where you (or someone more responsive) has administrative
 control?

The plan was to move the maillists to the server that is now already the
Vim mail server.  And the one causing this blacklist trouble...

There is no progress in moving the maillists.  I suppose it's time to
find a better place for the Vim mail server.  Instead of a server that
just happens to be available and run by someone who doesn't always
respond, or some big and anonymous server park like Yahoo, I think we
should look for a small site that does have 24 hour support.


Maybe vger.kernel.org can host vim mailing list ?
I assume fair number of kernel developers use vim.
vger.kernel.org already handles dozens of MLs, some of
multi-hundred-messages-per-day traffic. Thus couple of
vim MLs trafic shall not be problem for it ?

Yakov

\Left inside C-R=

[Yakov Lerner]

The following does not work as expected. I wonder
whether it is a bug or a feature:

cabbr XXX c-R=xyz.Left()cr

function! Left()
   return \Left
endfun

Instead of repositioning cursor left, I get
   :[EMAIL PROTECTED]
I know It is possible to make it work via feedkeys(), but this
[EMAIL PROTECTED] does not make much sense, does it ?

I wonder why \Left is nor recognized here as
special key ? Is it some sort of bug ?

Yakov

syntax and filetype.vim patch for 'initng' config files

[Yakov Lerner]

This is filetype.vim patch and syntax for initng config files.

Initng is bold new replacement for sysv-init, http://initng.thinktux.net

Those config files sit under /etc/initng/** and have extension *.i
Distinguishing them from other *.i files is easy, they have
#!/bin/itype in the 1st line.

The syntax file was written by Elan Ruusamäe [EMAIL PROTECTED]
and comes from http://glen.alkohol.ee/pld/initng/vim/

Yakov
--- filetype.vim2006-08-21 14:46:46.0 +
+++ filetype.vim.0012006-08-21 14:19:49.0 +
@@ -1250,19 +1250,14 @@
  endif
endfun

- Progress or assembly or initng
-au BufNewFile,BufRead *.i  call s:FTprogress_asm_initng()
+ Progress or assembly
+au BufNewFile,BufRead *.i  call s:FTprogress_asm()

-function! s:FTprogress_asm_initng()
+function! s:FTprogress_asm()
  if exists(g:filetype_i)
exe setf  . g:filetype_i
return
  endif
-   initng *.i files begin with #!/sbin/itype
-  if getline(1) ==# '#!/sbin/itype'
- setf initng
- return
-  endif
   This function checks for an assembly comment the first ten lines.
   If not found, assume Progress.
  let lnum = 1


initng.vim
Description: Binary data

Re: conceal-patch status

[Yakov Lerner]

On 8/17/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:

Vince Negri wrote:
 I'm still alive, just very busy :-)

 New home for conceal patches is:

 http://vince.negri.googlepages.com/
[...]


OK. I've updated my W32 and Unix HowTo (compile Vim) pages to mention
this, and while I was at it, I've mentioned Steve Hall's W32 download
page on my main vim page http://users.skynet.be/antoine.mechelynck/vim/


I put the link to the 'conceal' patch into vimtip:
   http://www.vim.org/tips/tip.php?tip_id=1308
so that people who look for conceal patch on the vim.org can find the
updated link.

Yakov

different format of features in :version

[Yakov Lerner]

I want to suggest different format of features listing in output of :version.
Namely, I suggest that all included features go first in one list, and
after them, all excluded go in another list. I think this is more readable
than existing format, in which both (+) and (-) features are mixed in a single
alphabetical lilst. Your opinion ?
Example is below:

:version
VIM - Vi IMproved 7.0 (2006 May 7, compiled Aug  3 2006 14:59:55 by
[EMAIL PROTECTED])
Included patches: 1-42. Huge version with GTK2 GUI.
   Features included: +arabic +autocmd +balloon_eval +browse
+builtin_terms +byte_offset +cindent +clientserver +clipboard
+cmdline_compl +cmdline_hist +cmdline_info
.
   Features excluded: -ebcdic -footer -hangul_input  -osfiletype
-mouse_jsbterm -mzscheme -perl -python -sun_workshop -tag_any_white
-ruby -sniff -tcl -xfontset -xterm_save

Yakov

Re: Vim's mch_FullName() function and ClearCase versioned file names

[Yakov Lerner]

On 8/12/06, Gary Johnson [EMAIL PROTECTED] wrote:

I just finished troubleshooting a problem that had several
contributing factors, one of which was the way Vim's mch_FullName()
function behaves with ClearCase versioned file names.

If you open a file under ClearCase using the full path name and a
version extension, e.g.,

/project/xyz/system/src/bar.c@@/main/42

Vim will ask mch_FullName() for the full name of that file.
mch_FullName() will then extract everything to the left of the last
'/' as the directory containing the file and chdir() to that
directory, e.g.,

chdir(/project/xyz/system/src/bar.c@@/main)

mch_FullName() then calls getcwd() to determine the operating
system's name for that directory, which from ClearCase is

/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main

mch_FullName() then puts back the trailing file name of 42 in
this case and returns the full file name as

/view/garyjohn_main@@/project/xyz/system/main/5/src/main/2/bar.c/main/42

This is the name that is then given to the buffer used for that file
and which appears in the status line.

This is a valid file name which points to the correct file and works
with most external commands.  However, it does not work with those
external commands or Vim autocommands whose behavior depend on the
file name suffix.  It's also really ugly in the status line.


How about using a symlink ?

Regarding statusline, you can use custom statusline
and replace %f to %{MyFilename()} which knows to handle @@.

Yakov

Re: Patch (Unofficial): Malformed characters in menu and toolbar when using zh_CN.GBK encoding under Linux

[Yakov Lerner]

On 8/12/06, mwoehlke [EMAIL PROTECTED] wrote:

Bram Moolenaar wrote:
 hundred-and-one symptoms of being an internet addict:
 256. You are able to write down over 250 symptoms of being an internet
  addict, even though they only asked for 101.

So where is the complete list? ;-)


I believe the list can't be complete because people
invent new ways of internet addiction every day.

258. You are subscribed to mailing list for every
piece of software you use.

259. You collect hilarious signatures from all
250 mailing lists you are subscribed to.

Yakov

vim cannot quit after certain tabs manipulation

[Yakov Lerner]

After certain 3-step manipulation with tabs,
can't quit vim with :q!. (vim 7.0.42). Tabline is
not updated properly.

% vim -u NONE -U NONE
ixescmake 1st buffer modified
:tabnewcr create 2nd tab
ixescmake 2nd buffer modified
:tabclose! 1 delete non-last tab

 ^^^ watch the tabline after tabclose command.
 PROBLEM #1 here: tabline shows 2 tabs but this is
   wrong; only 1 tab exist at this point
:tabs   confirm that ony 1 tab exists

:q!
E37: No write since last change (add ! to override)
E162: No write since last change for buffer [No Name]
^ PROBLEM #2: can't quit vim here, must resort to kill

Yakov

Re: Vim-Runtime

[Yakov Lerner]

On 8/4/06, Martin Krischik [EMAIL PROTECTED] wrote:


How are updates to the runtime files submitted?


You email them to Bram.

Yakov

Re: No way to color-region(s) of text -- highlighter mode.

[Yakov Lerner]

On 8/6/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:

Nikolai Weibull wrote:
 On 8/5/06, A.J.Mechelynck [EMAIL PROTECTED] wrote:

 Nikolai Weibull wrote:

  However, it can sort of be simulated by having marks that stick to the
  text position that they mark, instead of line + fixed column.  (We
  don't have this kind of mark at the moment.)

 IIUC, Vim's marks _are_ normally anchored to the text they mark, not to
 line numbers.

 That's what I so ineloquently stated.  The thing is that the column is
 fixed.

  nikolai



Hm., I checked it, and to my surprise, indeed when jumping with ` to a
mark after a characterwise-delete but in the same line, the mark is not
on the same text. Bug?


Line marks are anchored to the text (noy to line numbers).
Column marks are fixed at columns numbers, they are not
anchored to the text.

Yakov

Re: vim server ? security hole?

[Yakov Lerner]

On 7/28/06, Nikolai Weibull [EMAIL PROTECTED] wrote:

On 7/27/06, Bram Moolenaar [EMAIL PROTECTED] wrote:

 Vim uses the X server for communication.  Only users with write access
 to the X server can send a message to Vim.  And if you have write
 access, you are also able to send keystrokes to another process, thus
 you can do anything anyway.  E.g., by sending keystrokes to an xterm in
 which a shell is running.

 That is, I think it works this way.  Perhaps someone with more detailed
 knowledge of X server access restrictions can give a better answer.

Actually, you have to explicitly allow the sending of synthetic
keystrokes to an xterm (the allowSendEvents resource).


Via 'editres protocol', you can remotely manipulate
resources of running xterm (because xterm is Xt application).
I believe that it is possible to turn remotely this
allowSendEvents of xterm (if one has X server access).
Unless this allowSendEvents is treated differently than
other resources; I did not try to write working example.
I don't care, I always run with 'xhost +'.


I don't know,
but perhaps Vim needs to have something similar.

Vim has something similar:
  gvim --servername 
disables clientserver in gvim.

Yakov

Re: vim server ? security hole?

[Yakov Lerner]

On 7/26/06, Marc Weber [EMAIL PROTECTED] wrote:

I did notice that you can do
su
gvim
:echo SERVERNAME

and then using another user
gvim --servername=GVIMxx --remote-send='!/dowhatyouwant ;-)'


Marc,
In case you are talking X11:
D you have x11 authorization enabled or disabled ?

Command 'xhost' without arguments will show current status of x11 authorization.

The 'access controlled' state (default, or after 'xhost-'):
% xhost
access control enabled ...

The 'promiscuous' status (as after 'xhost +') shows as:
% xhost
access control disabled ...

If your access control is disabled, then can you try 'xhost -' (turn
access control on) and repeat your check ? What you describe
can not happen, AFAIK, when x11 access control is enabled.

Yakov

Re: vim server ? security hole?

[Yakov Lerner]

On 7/26/06, Marc Weber [EMAIL PROTECTED] wrote:

 Marc,
 In case you are talking X11:
 D you have x11 authorization enabled or disabled ?
I've been taking x11.
I did modify xhost because I wanted a php script be able to launch vim.
But I've restarted X now and xhost - shows the same as xhost. It still
works.

So c-rsystem('xhost') inserts:
access control enabled, only authorized clients can connect

But I'm not sure.. wether I've enabled localhost..
Anyway, should this be possible?
I mean root and somesuer should be able to connect to X without
somesuer beeing able to run root tasks using --remote-send.. by default.

 If your access control is disabled, then can you try 'xhost -' (turn
 access control on) and repeat your check ? What you describe
 can not happen, AFAIK, when x11 access control is enabled.

I've looked at vim code once.. On x it's using some weired gtk hack.. To
do this stuff.

I think you've tried it yourself and weren't able to reproduce it.. So I
think it's my setup only.


I am sure this thing, being potential security issue, awaits for
Bram's reaction and verdict. I just wanted to make sure that the
status of 'xhost' is mentioned wrt your setup, and to bring the
issue of 'xhost' into the picture.

With 'xhost +' (security disabled), yes, you can cross the borders and
invoke [potentially superuser] commands via vim clientserver. With 'xhost -'
(the default state), you can't. With 'xhost -' (security enabled),
I get this for your testcase:

 $ vim --servername GVIM --remote-send ':!ls'
 Xlib: connection to :0.0 refused by server
 Xlib: Invalid MIT-MAGIC-COOKIE-1 key
 No display: Send failed.
 $ vim --serverlist
 Xlib: connection to :0.0 refused by server
 Xlib: Invalid MIT-MAGIC-COOKIE-1 key

(vim is refused connection to x server. It can't send clientserver
commands w/o x connection.)

Can you confirm that with 'xhost -' you get same negative result as I ?

Yakov