> * Yoong Hor Meng <yhm@...>:
> > I compiled gvim 57 myself. I detected that there is a huge
> > memory leak (about 68K). The biggest leak happen when vim/gvim
> > call lalloc(size, message). It allocated memory but never free.
> > Other are such as in os_w32exe.c
> >     pszNewCmdLine = (char *)malloc(STRLEN(lpszCmdLine) + STRLEN(prog) +
> 4);
>
Err... let's see
near start of WinMain:

     pszNewCmdLine = (char *)malloc(STRLEN(lpszCmdLine) + STRLEN(prog) + 4);

at end of WinMain

	 free(pszNewCmdLine);

I suspect that this is the hoary old business which has happened before...
someone
runs Vim using (for example) the VC debug libraries and gets "memory leak!"
warnings
on exit, which are in fact for one-off allocations which Vim is letting the
OS clean up
at program exit, rather than waste time calling free() for everything. The
point being
that adding those free()'s wouldn't reduce Vim's memory footprint one iota.

Vince


Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

Yegappan Lakshmanan wrote:

> According to the documentation, the ]m, ]M, [m and [M commands
> can be used in Java or in a similar structured language to jump
> to the start or the end of a method.  I tried this in C for
> jumping to the start and end of a function.  It works without
> any problems.  Why is C not mentioned in the documentation for
> this command?

It doesn't work for me.  [m jumps back to the previous {} inside the function,
not to the start of the function.

> I can use the [[ command to jump to the start of a C function.
> But this will not work if a function declaration is something
> like
>
>  void func(void) {
>
> In the above case, the [m command works without any problems.

All C functions should have a "{" in the first column.  Otherwise it doesn't
look like a C function.  It's not illegal, just bad style.  You could use [{
to find that {.

--
hundred-and-one symptoms of being an internet addict:
100. The most exciting sporting events you noticed during summer 1996
     was Netscape vs. Microsoft.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Johannes Zellner wrote:

> it turns out that it it not really a problem of ins-completion but
> of typing especially when at the bottom of larger files. As an example
> try the attached folding vim.vim with a lengthy vim script, e.g. the
> vim.vim syntax file.
>
> # vim -u NONE $VIMRUNTIME/syntax/vim.vim
> :source vim.vim " <-- this time the attached folding script (not the syntax
file)
>
> Then go to the BOTTOM of the syntax file, open a line (vim will
> complain, because $VIMRUNTIME/syntax/vim.vim is not writable)
> and just type away. It's not usable on my 300 MHz PII.

The problem was identified as the 'foldexpr' returning a fold level relative
to the previous line.  Vim then had to start at the top of the file to
recompute all the foldlevels, since it doesn't know which ones had become
invalid after a change.

It's possible that folds above a change become invalid, I did not see a way to
make a generic solution that guesses the foldlevel above the changed text.
On the other hand, the 'foldexpr' doesn't know which lines have changed.

I found another solution: The 'foldexpr' can call the foldlevel() function to
check the existing fold level.  Since some of these folds are invalid, it will
return -1 for these.  The 'foldexpr' can use this information to try to
compute the absolute foldlevel.  Vim then doesn't need to go back further.

The example from Johannes can be updated like this:

	 [... computes "delta" as the difference in foldlevel compared to the
	 previous line]
>     if delta > 0
>  exe 'return "a'.delta.'"'
>     elseif delta < 0
>  exe 'return "s'.-delta.'"'
>     else
>  return '='
>     endif

The speed can be improved from "not usable" to "fast" by using these lines
first:

     let lvl = foldlevel(v:lnum - 1)
     if lvl >= 0
       return lvl + delta
     endif

Thus when the foldlevel of the line above the one we are computing the
foldlevel for is known, it returns an absolute number.  Then Vim knows it
doesn't have to go further back.

Note that this 'foldexpr' doesn't work correctly for these lines:

	 endif
	 if x

There is no new fold at "if", because the level doesn't change.  ">" should be
returned here.

--
To be rich is not the end, but only a change of worries.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

On Thu, Feb 01, 2001 at 03:31:55PM +0530, vipin aravind wrote:
> How can I select between tags before jumping to anyone of them rather than
going to
> the first one?

:ts
:help :ts

I've:

map <C-\> :exec "tjump " . expand("<cword>")<CR>


--
    Johannes

Actually, what I'm thinking of is being able to 'print' xterm query
codes and have some way of extracting the answer in a vim function.

   Is that in any shape or form even feasable?

--
=====================- http://www.thalesgroup.com/ -=====================
Neil Bird                          |  If this .signature   |
   work mailto:neil.bird@... |  looks pants, then    | $> cd /pub
   personal mailto:neil@...  |  stop using Outlook!  | $> more beer

Benji Fisher wrote:
> 1. strpart("abc", 1) strips off the first character, returning "bc".
> IWBNI strpart("abc", -1) stripped off the last character, returning "ab".

   Sounds easy enough. The only problem would be that it'd not be backwards
compatible, as that first number being negative already has a meaning, so
in context, it already does the right thing, IYSWIM.

   I'll think on that.


> 3. IWBNI there were a read-only register, say @|, that was filled with
> the number of the branch that matches after any search or call to
> match() and company:  after match("foo", 'f\|b'), @| holds 1, after
> match("bar", 'f\|b') it holds 2, and after match("IWBNI", 'f\|b') it
> holds 0.

   Unless I'm missing something, there's more to this: IWBNI we had access
to the \1, \2 etc. "()" sub-matches. If a sensible way to access these
were thought of, then it'd be a matter of considering how '|' matches
fitted into the equation.

   I'm thinking a 'lastsubmatch()' function that can be called to
interrogate the results of the, erm, last sub-match.

--
=====================- http://www.thalesgroup.com/ -=====================
Neil Bird                          |  If this .signature   |
   work mailto:neil.bird@... |  looks pants, then    | $> cd /pub
   personal mailto:neil@...  |  stop using Outlook!  | $> more beer

Neil Bird wrote:

>   Actually, what I'm thinking of is being able to 'print' xterm query
> codes and have some way of extracting the answer in a vim function.
>
>   Is that in any shape or form even feasable?

Is getchar() not sufficient?

--
hundred-and-one symptoms of being an internet addict:
113. You are asked about a bus schedule, you wonder if it is 16 or 32 bits.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Maybe it's NT specific, then.  I see it on two different NT4 systems.

>-----Original Message-----
>From: Benji Fisher [mailto:benji@...]
>Sent: Wednesday, January 31, 2001 6:15 PM
>To: Ron Aaron
>Cc: 'vim-dev@...'
>Subject: Re: Delay when using the mouse to activate menus on Win32
>
>
>Ron Aaron wrote:
>>
>> Hi all -
>>
>> I have noticed for a long time a curious buglet:
>>
>> In gvim on Win32, when selecting a menu item, the action is
>not immediate.
>>
>> For example, load a bunch of files so you have entries in
>the 'buffers'
>> menu.  Now, using the mouse, select a buffer from the menu
>BUT DON'T MOVE
>> THE MOUSE after selecting.  If you are careful, nothing will
>happen until
>> you move the mouse!
>>
>> It looks like something bogus in our event handling.  Has anyone else
>> noticed this?
>>
>> Ron
>
>     I do not see this.  I am running gvim 5.7 and 6.0t on
>W95.  I use a
>track pad, so I can test this pretty reliably:  when I tap the button,
>there is no danger of accidentally moving the pointer at the same time.
>
> 			 --Benji Fisher
>

Hi.  My name is Mike and I am a trackball user.  I don't see this problem on
Win2K either.

Mike

> -----Original Message-----
> From: Ron Aaron [mailto:raaron@...]
> Sent: Thursday, February 01, 2001 9:25 am
> To: 'Benji Fisher'
> Cc: 'vim-dev@...'
> Subject: RE: Delay when using the mouse to activate menus on Win32
>
>
> Maybe it's NT specific, then.  I see it on two different NT4 systems.
>
> >-----Original Message-----
> >From: Benji Fisher [mailto:benji@...]
> >Sent: Wednesday, January 31, 2001 6:15 PM
> >To: Ron Aaron
> >Cc: 'vim-dev@...'
> >Subject: Re: Delay when using the mouse to activate menus on Win32
> >
> >
> >Ron Aaron wrote:
> >>
> >> Hi all -
> >>
> >> I have noticed for a long time a curious buglet:
> >>
> >> In gvim on Win32, when selecting a menu item, the action is
> >not immediate.
[snip]
> >>
> >> Ron
> >
> >     I do not see this.  I am running gvim 5.7 and 6.0t on
> >W95.  I use a
> >track pad, so I can test this pretty reliably:  when I tap
> the button,
> >there is no danger of accidentally moving the pointer at the
> same time.
> >
> > 			 --Benji Fisher
> >
>

> Ron Aaron [SMTP:raaron@...] pondered:
>
> Maybe it's NT specific, then.  I see it on two different NT4 systems.

Don't see it on my NT4 system, so it must be more
specific than that! :-)

Vince


Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such
privilege. Please advise the sender if you receive this e-mail by mistake.

In article <001b01c08bc5$32e10600$3800a8c0@...> of Wed, 31
Jan 2001 15:34:23 in !vim-dev, J. David Boyd <dave@...> writes
>
>----- Original Message ----- >
>> But it should work on MS-DOS too.  That's why a batch script is used.
>>
>
>MS-DOS only supports 9 batch variables directly.  Then you have to start
>using the SHIFT command, like in the script.
>
>Dave
>

I have tested the file from which the enclosed diff was made
*** dosinst.!c  Sat Jan 06 17:41:52 2001
--- dosinst.c   Thu Feb 01 16:39:58 2001
***************
*** 559,564 ****
--- 559,624 ----
   }

   /*
+  * On input **destination is the path of an executable.
+  * If that executable is in the current directory, look for another one.
+  * *destination is set to NULL or the location of that file.
+  */
+
+ static void
+ findoldfile(char **destination)
+ {
+     char *exename;
+     char *bp = *destination;
+     size_t indir_l = strlen(installdir);
+     char *cp = bp + indir_l;
+     char *tmpname;
+     char *farname;
+
+     /*
+      * No action needed if exe not found or not in this directory.
+      */
+     if (bp == NULL
+     || strnicmp(bp, installdir, indir_l) != 0
+     || strchr("/\\", *cp++) == NULL
+     || strchr(cp, '\\') != NULL
+     || strchr(cp, '/') != NULL)
+       return;
+
+     exename = alloc(strlen(cp)+1);
+     strcpy(exename, cp);
+     tmpname = alloc(strlen(cp)+sizeof(".tmp"));
+     strcpy(tmpname, cp), strcat(tmpname, ".tmp");
+
+     if (access(tmpname, 0) == 0)
+     {
+       printf("\nERROR: %s and %s clash. remove/move so only %s exists\n",
+           tmpname, exename, exename);
+       exit(1);
+     }
+
+     if (rename(exename, tmpname) != 0)
+     {
+       printf("\nERROR: failed to rename %s to %s: %s\n",
+           exename, tmpname, strerror(errno));
+       exit(1);
+     }
+
+     farname = searchpath_save(exename);
+
+     if (rename(tmpname, exename) != 0)
+     {
+       printf("\nERROR: failed to rename %s back to %s: %s\n",
+           tmpname, exename, strerror(errno));
+       exit(1);
+     }
+
+     free(*destination);
+     free(exename);
+     free(tmpname);
+     *destination = farname;
+ }
+
+ /*
    * Find out information about the system.
    */
       static void
***************
*** 605,610 ****
--- 665,679 ----
       oldvimexe = searchpath_save("vim.exe");
       oldgvimexe = searchpath_save("gvim.exe");
       mch_chdir(installdir);
+
+     /*
+      * The technique used above to set oldvimexe and oldgvimexe
+      * gives a spurious result for Windows 2000 Professional.
+      * w.briscoe@... 2001-01-20
+      */
+     findoldfile(&oldvimexe);
+     findoldfile(&oldgvimexe);
+
       if (oldvimexe != NULL || oldgvimexe != NULL)
       {
         printf("Warning: Found a Vim executable in your $PATH:\n");
***************
*** 796,808 ****
              * contains a space.  The quotes would be included in the value
              * for MSDOS. */
             fprintf(fd, "set VIM=%s\n", buf);
!
!           strcpy(buf, installdir);
!           add_pathsep(buf);
!           strcat(buf, exename);
!           /* Can only handle 9 arguments now.  Use "shift" to use more? */
!           fprintf(fd, "%s %%1 %%2 %%3 %%4 %%5 %%6 %%7 %%8 %%9\n", buf);
!
             fclose(fd);
             printf("%s has been %s\n", batname,
                                  oldname == NULL ? "created" : "overwritten");
--- 865,879 ----
              * contains a space.  The quotes would be included in the value
              * for MSDOS. */
             fprintf(fd, "set VIM=%s\n", buf);
!           fprintf(fd, "set VIMARGS=\n");
!           fprintf(fd, ":arg\n");
!           fprintf(fd, "if .%%1==. goto start\n");
!           fprintf(fd, "set VIMARGS=%%VIMARGS%% %%1\n");
!           fprintf(fd, "shift\n");
!           fprintf(fd, "goto arg\n");
!           fprintf(fd, ":start\n");
!           fprintf(fd, "%%VIM%%VIM60T\\%s %%VIMARGS%%\n", exename);
!           fprintf(fd, "set VIMARGS=\n");
             fclose(fd);
             printf("%s has been %s\n", batname,
                                  oldname == NULL ? "created" : "overwritten");


--
Walter Briscoe

This patch modifies the man.vim syntax file so that the period (".") is
acceptable in the man page name.  Lots of configuration-related man pages, e.g.
"inetd.conf", use the period.

16,17c16,17
< syn match  manReference       "[a-z][a-z0-9_]*([1-9][a-z]\{0,1})"
< syn match  manTitle           "^\i\+([0-9]\+[a-z]\=).*"
---
> syn match  manReference       "[a-z][a-z0-9_\.]*([1-9][a-z]\=)"
> syn match  manTitle           "^[a-z][a-z0-9_\.]*([0-9]\+[a-z]\=).*"


I'm not sure why the original manReference pattern used only alphanumeric
characters plus the underscore, while the manTitle pattern used \i, which is the
set of "identifier" characters.  I guess the title can be more descriptive than
the simple man page name you type on the command line?  Anyway, I tried adding
the period after the \i as shown below, but for some reason it didn't work. 
Maybe someone can tell me why.  Can't you use \i within square brackets?

    syn match  manTitle           "^[\i\.]\+([0-9]\+[a-z]\=).*"

If my removal of \i from manTitle break some man pages, then the syntax file
might need further tweaking.

Craig Barkhouse wrote:
>
> This patch modifies the man.vim syntax file so that the period (".") is
acceptable in the man page name.  Lots of configuration-related man pages, e.g.
"inetd.conf", use the period.
>
> 16,17c16,17
> < syn match  manReference       "[a-z][a-z0-9_]*([1-9][a-z]\{0,1})"
> < syn match  manTitle           "^\i\+([0-9]\+[a-z]\=).*"
> ---
> > syn match  manReference       "[a-z][a-z0-9_\.]*([1-9][a-z]\=)"
> > syn match  manTitle           "^[a-z][a-z0-9_\.]*([0-9]\+[a-z]\=).*"
>
> I'm not sure why the original manReference pattern used only alphanumeric
characters plus the underscore, while the manTitle pattern used \i, which is the
set of "identifier" characters.  I guess the title can be more descriptive than
the simple man page name you type on the command line?  Anyway, I tried adding
the period after the \i as shown below, but for some reason it didn't work. 
Maybe someone can tell me why.  Can't you use \i within square brackets?
>
>    syn match  manTitle           "^[\i\.]\+([0-9]\+[a-z]\=).*"
>
> If my removal of \i from manTitle break some man pages, then the syntax file
might need further tweaking.

      I am not sure whether there are special rules on this for syntax
files, bit in general, character classes like '\i' are not allowed inside
[brackets] in regexp's.  See :help /[ for details, and :help alnum and
following for the kind of character classes that are allowed in brackets.

HTH 			 --Benji Fisher

Neil Bird wrote:
>
> Benji Fisher wrote:
> > 1. strpart("abc", 1) strips off the first character, returning "bc".
> > IWBNI strpart("abc", -1) stripped off the last character, returning "ab".
>
>   Sounds easy enough. The only problem would be that it'd not be backwards
> compatible, as that first number being negative already has a meaning, so
> in context, it already does the right thing, IYSWIM.
>
>   I'll think on that.
>
> > 3. IWBNI there were a read-only register, say @|, that was filled with
> > the number of the branch that matches after any search or call to
> > match() and company:  after match("foo", 'f\|b'), @| holds 1, after
> > match("bar", 'f\|b') it holds 2, and after match("IWBNI", 'f\|b') it
> > holds 0.
>
>   Unless I'm missing something, there's more to this: IWBNI we had access
> to the \1, \2 etc. "()" sub-matches. If a sensible way to access these
> were thought of, then it'd be a matter of considering how '|' matches
> fitted into the equation.
>
>   I'm thinking a 'lastsubmatch()' function that can be called to
> interrogate the results of the, erm, last sub-match.

      Until vim 6.0, strpart("abc", -1) was illegal, as was
strpart("abc",1).  Thus the compatibility issue is not too great:  how
many scripts have been written since 6.0 alphas started coming out that
rely on strpart("abc",-1) returning "abc"?  Also, is there another good
way to strip off the last character?  I bet that strpart(str, 0,
strlen(str)-1) takes twice as long as strlen(str,1).

					 --Benji Fisher

I think a new function is in order.

strpartright("abc",1)
would return 'ab'
strpartright("abc",0,1)
would return 'c'

in other words if we had a function reverse() that reverses a string, then
strpartright would be
reverse(strpart(reverse( {string}) , {arg1}[, {arg2}]


I also think that a better 'modification' to strpart using -ve values would
be:

strpart( {strexpr}, {start}, -{len} )
equivalent to
strpart( {strexpr}, {start}, strlen({strexpr}) - {len}  )

so

let a = "'my string'"
echo strpart( a, 1,-1)

would echo:
my string


//.

	 -----Original Message-----
	 From: Neil Bird [SMTP:neil.bird@...]
	 Sent: Friday, 2 February 2001 2:19
	 To: benji@...
	 Cc: Vim-Dev Mailing List
	 Subject: Re: "It would be nice" (Was: patch: ':let a="+10"'
etc)

	 Benji Fisher wrote:
	 > 1. strpart("abc", 1) strips off the first character, returning
"bc".
	 > IWBNI strpart("abc", -1) stripped off the last character,
returning "ab".

	   Sounds easy enough. The only problem would be that it'd not be
backwards
	 compatible, as that first number being negative already has a
meaning, so
	 in context, it already does the right thing, IYSWIM.

On Tue, 30 Jan 2001, Bram Moolenaar wrote:

> > Some tools apparently can't deal with the new way of handling file I/O...
> >
> > When using vim 6.0t with "crontab -e", crontab holds the fd of the tmp
> > file, and compares the result of fstat before and after; vi unlinks the
> > old file and writes a new one.
>
> Hmm, I thought I fixed that.  And for me it works fine.

Not working on Red Hat Linux 7.

> Did you change any of the options?  Specifically 'backupskip'.  Or is your
> $TMPDIR not set to /tmp?

No special options, no tampering with backupskip, no odd $TMPDIR.

This happens only with the minimal version
   --with-features=tiny --with-x=no \
   --disable-pythoninterp --disable-perlinterp --disable-tclinterp \
   --with-tlib=termcap --enable-gui=no --disable-gpm --exec-prefix=/

the full-featured version
   --with-features=huge --enable-pythoninterp \
   --enable-perlinterp --disable-tclinterp --with-x=no --enable-gui=no \
   --exec-prefix=/usr --enable-multibyte --enable-fontset

works great.

LLaP
bero

On Fri, Feb 02, 2001 at 11:31:59AM +0100,
Bernhard Rosenkraenzer <bero@...> wrote:
>
> On Tue, 30 Jan 2001, Bram Moolenaar wrote:
>
> > > Some tools apparently can't deal with the new way of handling file I/O...
> > >
> > > When using vim 6.0t with "crontab -e", crontab holds the fd of the tmp
> > > file, and compares the result of fstat before and after; vi unlinks the
> > > old file and writes a new one.
> >
> > Hmm, I thought I fixed that.  And for me it works fine.
>
> Not working on Red Hat Linux 7.
>
> > Did you change any of the options?  Specifically 'backupskip'.  Or is your
> > $TMPDIR not set to /tmp?
>
> No special options, no tampering with backupskip, no odd $TMPDIR.
>
> This happens only with the minimal version
>   --with-features=tiny --with-x=no \
>   --disable-pythoninterp --disable-perlinterp --disable-tclinterp \
>   --with-tlib=termcap --enable-gui=no --disable-gpm --exec-prefix=/
>
> the full-featured version
>   --with-features=huge --enable-pythoninterp \
>   --enable-perlinterp --disable-tclinterp --with-x=no --enable-gui=no \
>   --exec-prefix=/usr --enable-multibyte --enable-fontset
>
> works great.

What I always wanted to ask in this respect: Doing a default install of
RedHat 6.2, vim-minimal gets installed. Now, I hit "vim" and get
"command not found", so I enter "vi", and :ver says... "hey, it's vim".
That's just annoying!

> LLaP
> bero

Ciao,
Thomas

--
  Thomas Köhler Email:   jean-luc@...     | LCARS - Linux
      <><        WWW:     http://jeanluc-picard.de      | for Computers
                 IRC:             jeanluc               | on All Real
                PGP public key available from Homepage! | Starships

On Fri, 2 Feb 2001, Thomas Köhler wrote:

> What I always wanted to ask in this respect: Doing a default install of
> RedHat 6.2, vim-minimal gets installed. Now, I hit "vim" and get
> "command not found", so I enter "vi", and :ver says... "hey, it's vim".
> That's just annoying!

I think this is the only sane thing to do - having a /bin/vi that is vim
stripped down to be little more than old vi (features=tiny) and a
/usr/bin/vim as a fully featured editor (from vim-enhanced) seems sane to
me.

I've always been in favor of moving vim-enhanced to the default
installations, but some <puke>emacs</puke> freaks are blocking that idea.
:/

LLaP
bero

Thomas K?hler wrote:

> > > Did you change any of the options?  Specifically 'backupskip'.  Or
> is your
> > > $TMPDIR not set to /tmp?
> >
> > No special options, no tampering with backupskip, no odd $TMPDIR.
> >
> > This happens only with the minimal version
> >   --with-features=tiny --with-x=no \
> >   --disable-pythoninterp --disable-perlinterp --disable-tclinterp \
> >   --with-tlib=termcap --enable-gui=no --disable-gpm --exec-prefix=/
> >
> > the full-featured version
> >   --with-features=huge --enable-pythoninterp \
> >   --enable-perlinterp --disable-tclinterp --with-x=no --enable-gui=no
> \
> >   --exec-prefix=/usr --enable-multibyte --enable-fontset
> >
> > works great.
>
> What I always wanted to ask in this respect: Doing a default install of
> RedHat 6.2, vim-minimal gets installed. Now, I hit "vim" and get
> "command not found", so I enter "vi", and :ver says... "hey, it's vim".
> That's just annoying!

The bugzilla.redhat.com is the place to said this if you want to be heard.

--
An experienced user learns to be pessimistic.

Benji Fisher wrote:
>      Until vim 6.0, strpart("abc", -1) was illegal, as was
> strpart("abc",1).  Thus the compatibility issue is not too great:  how
> many scripts have been written since 6.0 alphas started coming out that
> rely on strpart("abc",-1) returning "abc"?

   In that case, it can come down to: which interpretation do people (read:
Bram) prefer? I think I'd vote for the 'new' way, but I can see how
'correctly' interpreting negative start indices would be useful in scripts
(to catch boundary cases).

   Unless, of course, another combination can be thought of. Negative
lengths?

--
=====================- http://www.thalesgroup.com/ -=====================
Neil Bird                          |  If this .signature   |
   work mailto:neil.bird@... |  looks pants, then    | $> cd /pub
   personal mailto:neil@...  |  stop using Outlook!  | $> more beer

On Fri, Feb 02, 2001 at 11:58:01AM +0100,
Bernhard Rosenkraenzer <bero@...> wrote:
>
> On Fri, 2 Feb 2001, Thomas Köhler wrote:
>
> > What I always wanted to ask in this respect: Doing a default install of
> > RedHat 6.2, vim-minimal gets installed. Now, I hit "vim" and get
> > "command not found", so I enter "vi", and :ver says... "hey, it's vim".
> > That's just annoying!
>
> I think this is the only sane thing to do - having a /bin/vi that is vim
> stripped down to be little more than old vi (features=tiny) and a
> /usr/bin/vim as a fully featured editor (from vim-enhanced) seems sane to
> me.

It's sane if there really are both of them. It's not if there's only vi.
Why not symlink vim to vi then?

And of course, you could as well just let vim-minimal conflict with
vim-enhanced (that's what package management is for), so if you install
vim-enhanced, vim-minimal gets removed first. vim-minimal contains both
vi and vim (the later being a symlink to the first), and vim-enhanced
contains both (vi being the "minimal" version, vim being the enhanced
one).

> I've always been in favor of moving vim-enhanced to the default
> installations, but some <puke>emacs</puke> freaks are blocking that idea.
> :/

~> emacs
zsh: command not found: emacs

Of course, this is not a default installation (and, to be honest, it's
debian-based ;-)

> LLaP
> bero

Ciao,
Thomas

--
  Thomas Köhler Email:   jean-luc@...     | LCARS - Linux
      <><        WWW:     http://jeanluc-picard.de      | for Computers
                 IRC:             jeanluc               | on All Real
                PGP public key available from Homepage! | Starships

Craig Barkhouse wrote:

> This patch modifies the man.vim syntax file so that the period (".") is
> acceptable in the man page name.  Lots of configuration-related man pages,
> e.g. "inetd.conf", use the period.
>
> 16,17c16,17
> < syn match  manReference       "[a-z][a-z0-9_]*([1-9][a-z]\{0,1})"
> < syn match  manTitle           "^\i\+([0-9]\+[a-z]\=).*"
> ---
> > syn match  manReference       "[a-z][a-z0-9_\.]*([1-9][a-z]\=)"
> > syn match  manTitle           "^[a-z][a-z0-9_\.]*([0-9]\+[a-z]\=).*"

This also came up in another message shortly ago.  The solution was to use
"\f" for the manpage name.  I suppose that's right, since the name of the
manual page is a file name as well.  The required "(1)" after it makes sure it
doesn't match too often:

	 syn match  manReference       "\f\+([1-9][a-z]\=)"
	 syn match  manTitle           "^\f\+([0-9]\+[a-z]\=).*"

> Anyway, I tried adding the period after the \i as shown below, but for some
> reason it didn't work.  Maybe someone can tell me why.  Can't you use \i
> within square brackets?
>
>    syn match  manTitle           "^[\i\.]\+([0-9]\+[a-z]\=).*"

Indeed, you can't use \i here.  Inside [] the backslash is not a special
character, except in a few specific cases.  This is for Vi compatibility.

--
hundred-and-one symptoms of being an internet addict:
118. You are on a first-name basis with your ISP's staff.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Bram Moolenaar wrote:
> >   Actually, what I'm thinking of is being able to 'print' xterm query
> > codes and have some way of extracting the answer in a vim function.
>
> Is getchar() not sufficient?

   Erm ... <fx: whistles and looks around innocently>

   Yes, sorry, I managed to miss that :-/


   OK, well I'm pretty well there: two snags (ref. attached test script)

(1) is there a way to force echo to actually /print/ an <esc> as opposed
to "^["? Yes, I know it'd normally be dangerous, but doing !echo switches
screens.

(2) getchar(), as far as I can tell, is actually waiting for me to
physically type something before it sees the xterm's response (which it
does do). I.e., I run the attached GetSize() and have to hit <Space> to
get anything.

--
=====================- http://www.thalesgroup.com/ -=====================
Neil Bird                          |  If this .signature   |
   work mailto:neil.bird@... |  looks pants, then    | $> cd /pub
   personal mailto:neil@...  |  stop using Outlook!  | $> more beer

function! Getchar()
    let g = 0
    while g == 0
       let g = getchar()
       echom 'got ' . g
    endwhile
    return g
endfunction

function! ReadInputUntil(t)
    let r = ''
    let g = '?'
    while g != a:t && g != ''
       let g = Getchar()
       echom 'got ' . g
       let g = nr2char(g)
       if g != a:t
          let r = r . g
       endif
    endwhile
    return r
endfunction

function! GetSize()
    silent exe "!echo \"\<Esc>[18t\""
    " echom 'char waiting = ' . getchar(1)
    let res = Getchar() . Getchar() . Getchar() . Getchar()  " <Esc>[8;
    let x = ReadInputUntil(';')
    let y = ReadInputUntil('t')
    echom 'Got X=' . x . '; Y=' . y
endfunction

Bernhard Rosenkraenzer wrote:

> > > When using vim 6.0t with "crontab -e", crontab holds the fd of the tmp
> > > file, and compares the result of fstat before and after; vi unlinks the
> > > old file and writes a new one.
> >
> > Hmm, I thought I fixed that.  And for me it works fine.
>
> Not working on Red Hat Linux 7.
>
> > Did you change any of the options?  Specifically 'backupskip'.  Or is your
> > $TMPDIR not set to /tmp?
>
> No special options, no tampering with backupskip, no odd $TMPDIR.

Hmm, only in the tiny version...  Ah, 'backupskip' isn't included then.

Include this patch, then it should work:

*** feature.h~ Tue Jan 30 14:47:58 2001
--- feature.h Fri Feb  2 12:54:58 2001
***************
*** 387,395 ****
   #endif

   /*
!  * +wildignore  'wildignore' option
    */
! #ifdef FEAT_NORMAL
   # define FEAT_WILDIGN
   #endif

--- 387,396 ----
   #endif

   /*
!  * +wildignore  'wildignore' and 'backupskip' options
!  * 	 Needed for Unix to make "crontab -e" work.
    */
! #if defined(FEAT_NORMAL) || defined(UNIX)
   # define FEAT_WILDIGN
   #endif


--
hundred-and-one symptoms of being an internet addict:
125. You begin to wonder how often it REALLY is necessary to get up
      and shower or bathe.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Michael Geddes wrote:

> I think a new function is in order.
>
> strpartright("abc",1)
> would return 'ab'
> strpartright("abc",0,1)
> would return 'c'

I like that better than a negative argument.  If the "offset" argument is a
variable, and it accidentally becomes negative (e.g., -1), you don't suddenly
want to get characters from the other side of the string.

> I also think that a better 'modification' to strpart using -ve values would
> be:
>
> strpart( {strexpr}, {start}, -{len} )
> equivalent to
> strpart( {strexpr}, {start}, strlen({strexpr}) - {len}  )
>
> so
>
> let a = "'my string'"
> echo strpart( a, 1,-1)
>
> would echo:
> my string

That makes sense.  Although I think the example should be:

	 echo strpart(a, 1, -2)

You're taking off two characters, one on both sides.

However, the when the length is computed, and you accidentally end up
computing a negative length, you don't get what you want.

I don't like the idea of a negative value making the function do something
different.  The meaning of the function call becomes less obvious, you have to
look carefully to see what it does.  So, let's just use that strlen()
explicit, that's much clearer.

For all these theoretical items, it's very useful to see some actual code that
uses it.  Only then can we find out what is easy to use and what isn't.

--
hundred-and-one symptoms of being an internet addict:
120. You ask a friend, "What's that big shiny thing?" He says, "It's the sun."

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Neil Bird wrote:

> (1) is there a way to force echo to actually /print/ an <esc> as opposed
> to "^["? Yes, I know it'd normally be dangerous, but doing !echo switches
> screens.

Did you try adding <Esc> to 'isprint'?

> (2) getchar(), as far as I can tell, is actually waiting for me to
> physically type something before it sees the xterm's response (which it
> does do). I.e., I run the attached GetSize() and have to hit <Space> to
> get anything.

It works fine for me, without typing a space.  Perhaps it's because your xterm
swaps screens?

Anyway, getchar() wasn't really setup to handle communication with escape
sequences.  I'm surprised this actually works.

--
hundred-and-one symptoms of being an internet addict:
126. You brag to all of your friends about your date Saturday night...but
      you don't tell them it was only in a chat room.

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Bram wrote:
> syn match  manReference       "\f\+([1-9][a-z]\=)"
> syn match  manTitle           "^\f\+([0-9]\+[a-z]\=).*"

Thanks, this does the job and is much neater to look at.

> >    syn match  manTitle           "^[\i\.]\+([0-9]\+[a-z]\=).*"
> Indeed, you can't use \i here.  Inside [] the backslash is not a special
> character, except in a few specific cases.  This is for Vi compatibility.

Thanks for the tip.

Vim Dev Guys and Gals:

      Is there a way to bail out of a hopelessly confused function in debug
mode?  I tried CTRL-C and it did not work.  Once one variable comes up
undefined, I get a lot of error messages before the function quits.  Maybe
this is a more general problem, that the "Hit ENTER" prompt does not
accept CTRL-C.

					 --Benji Fisher

Benji Fisher wrote:
>
> Vim Dev Guys and Gals:
>
>      Is there a way to bail out of a hopelessly confused function in debug
> mode?  I tried CTRL-C and it did not work.  Once one variable comes up
> undefined, I get a lot of error messages before the function quits.  Maybe
> this is a more general problem, that the "Hit ENTER" prompt does not
> accept CTRL-C.

I hit that one, too, and didn't find a way out. I'd be interested to
know, too.
I just killed the window but that's what you want to do...
Problem is I can't reproduce it now, I fixed some of the problems and
now
I can't get into that state.

---Zdenek