On May 3, 12:01 pm, Tony Mechelynck <antoine.mechely...@...>
wrote:
> On 02/05/11 12:03, Tim Cuthbertson wrote:
>
> > Hi all,
>
> > I love vim, but must admit to not being so fond of the fairly old
> > looking icon. I recently created a new logo for my own use, and would
> > be more than happy if you'd like to use it for an actual app icon or
> > logo.
>
> > I'm happy to release it under pretty much whatever licence is
> > required, if people want to modify / improve it.
>
> > The icon can be found here:
> >http://gfxmonk.net/2011/04/25/new-gvim-icon.html
>
> > svg:http://gfxmonk.net/images/vim-logo/vim-logo.svg
> > png:http://gfxmonk.net/images/vim-logo/vim-logo-128.png
>
> > Cheers,
> >   - Tim.
>
> What's wrong with that old icon?

Mostly subjective reasons, but the lack of antialiasing and the
limited colour use I think are concrete aspects that make the logo
look particularly outdated. And the subjective opinions are at least
shared by most who have participated in this thread (so far).

> Doesn't anyone use low resolutions
> and/or 256-colour terminals anymore (even in the deepest of the jungles
> where Vim might be in use on 4th-hand computers even if Vista isn't
> supported by them)?

Perhaps there is need for a fallback icon with safe colours for the
minority of users who run their graphical environment in 256-colour,
but I doubt it should be the default.

> I have a 48x48 Vim icon on my desktop and it doesn't look out of place
> next to SeaMonkey, Thunderbird, Adobe Reader and YaST.

I'm running fedora 15 w/ gnome-shell, which features pretty large
icons (~96px, I think). Vim looks extremely out of place. In my
applications list, there is not a single other application that lacks
antialiasing, nor one that sticks to any palette of "safe" colours. So
yes, I'm certainly viewing most of my icons larger than most folk
right now, but the trend is nonetheless for bigger icons.

> BTW, the HTML textbooks I have here still mention "safe" GUI colours,
> which are colours where the red, green and blue components are each a
> multiple of 0x33 (in #rrggbb notation) or of 3 (in "abbreviated"
> 3-nybble #rgb notation). This means there are 6^3 = 216 "safe" colours.

Is your point that there are plenty of safe colours to use, or simply
that conservative icons should stick to safe colours only? I haven't
read a HTML book for a long time, but I also don't know any web
developer who still actually sticks to safe colours.

Regards,
  - Tim.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On May 3, 8:18 am, "Christian J. Robinson" <hept...@...> wrote:
> On Mon, 2 May 2011, Tim Cuthbertson wrote:
> > I love vim, but must admit to not being so fond of the fairly old
> > looking icon. I recently created a new logo for my own use, and
> > would be more than happy if you'd like to use it for an actual app
> > icon or logo.
>
> I like this icon, but my problem is that it looks increasingly poor as
> it is scaled down in size.  The small size on my taskbar looks
> significantly worse than the default icon.
>
> - Christian

Yes, that is a problem. I am not too concerned about it for my own
personal use (I never see it smaller than ~86px), but I expect smaller
variants would need to be created which increased contrast / line
width for better representation at smaller sizes. If required I can
have a go at doing this (or others can, the .svg is the original
inkscape source), but I'd rather not bother if nobody is going to
actually use it.

Regards,
  - Tim.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 03/05/11 09:59, Sung Pae wrote:
> Upon closer inspection, I have the following observations about vim's
> handling of foreign selections.
>
>
> When pasting from the "* or "+ register, vim requests a selection
> from the system clipboard. If the selection is not in a vim
> selection format:
>
>      - The mac, macosx, msdos, mswin, and qnx ports detect the presence
>        of a NL or CR (whatever is appropriate) _anywhere_ in the text and
>        switch the motion_type to MLINE
>
>      - The riscos, gtk-x11, and x11 ports always set motion_type to MCHAR
>
>      - In X, if the selection request fails, CUT_BUFFER0 is used, and is
>        also always set to MCHAR
>
> As you can see, vim's behavior wrt pasting foreign text is inconsistent.
> Most of the non-X ports linewise paste multi-line selections, while the
> X-based vims do not.
>
> While the X behavior is not a bug (it is actually explicitly
> documented), I believe it is surprising in this instance.
>
> When I copy a large multi-line selection in an application in order to
> transfer it into a vim buffer, I don't usually intend on engaging in a
> delicate mid-line paste operation. The major non-X GUI ports evidently
> share this view.
>
>
> There a couple of other instances to consider in which vim yanks from
> foreign sources:
>
>      - When dragging text into gvim (gtk-x11), the selection is always
>        yanked as MCHAR
>
>      - Modeless selections are always yanked as MCHAR
>
> With drag and drop, pasting character-wise is justifiable because there
> is typically not much context switching involved: there are no separate
> yank and paste operations, the two applications are likely to be side
> by side, and flashy GUIs often show a live preview of the text as it is
> dragged about. It would be more surprising to open a new line for the
> paste than to paste it exactly at the cursor.
>
> With modeless selections, it is logical to simply yank as MCHAR since
> one of their primary purposes is to transfer text to the command line.
>
>
> Summary of the following patch:
>
>   * Risc OS, Gtk-X11, and X11:
>
>      Call vim_strchr(buf, '\n') on the selection buffer to switch
>      multi-line strings to MLINE mode before yanking into "* or "+
>
>   * Documentation:
>
>      Update relevant sections regarding pasting multi-line strings from
>      foreign applications
>
>
> Gary, would you mind running your tests again with this patch? Yanking
> multi-line selections from Firefox should be just fine, since it no
> longer just looks at the last character to determine the motion type.
>
> Cheers,
> Sung Pae
>
> ---
>   runtime/doc/gui.txt     |    7 ++++---
>   runtime/doc/gui_x11.txt |    5 +++--
>   src/gui_gtk_x11.c       |    4 ++++
>   src/gui_riscos.c        |    6 +++++-
>   src/ui.c                |   12 ++++++++++--
>   5 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/runtime/doc/gui.txt b/runtime/doc/gui.txt
> index 213f455..74c3cfc 100644
> --- a/runtime/doc/gui.txt
> +++ b/runtime/doc/gui.txt
> @@ -439,9 +439,10 @@ When using this register under X11, also see
> |x11-selection|.  This also
>   explains the related "+ register.
>
>   Note that when pasting text from one Vim into another separate Vim, the type
> -of selection (character, line, or block) will also be copied.  For other
> -applications the type is always character.  However, if the text gets
> -transferred via the |x11-cut-buffer|, the selection type is ALWAYS lost.
> +of selection (character, line, or block) will also be copied.  When pasting
> +from other applications the type is character, unless the the selection
> +consists of multiple lines, in which case the type is line.  This also
applies
> +to text transferred via the |x11-cut-buffer|.
>
>   When the "unnamed" string is included in the 'clipboard' option, the unnamed
>   register is the same as the "* register.  Thus you can yank to and paste the
> diff --git a/runtime/doc/gui_x11.txt b/runtime/doc/gui_x11.txt
> index 6d16500..ad434b6 100644
> --- a/runtime/doc/gui_x11.txt
> +++ b/runtime/doc/gui_x11.txt
> @@ -566,8 +566,9 @@ requested X selection is empty or unavailable, Vim
> reverts to reading the
>   current value of the CUT_BUFFER0.
>
>   Note that when text is copied to CUT_BUFFER0 in this way, the type of
> -selection (character, line or block) is always lost, even if it is a Vim
which
> -later pastes it.
> +selection (character, line or block) is always lost. However, when pasting
> +from CUT_BUFFER0, the selection will be pasted as line if the text consists
> +of multiple lines, and as character otherwise.
>
>   Xterm, by default, always writes visible selections to both PRIMARY and
>   CUT_BUFFER0.  When it pastes, it uses PRIMARY if this is available, or else
> diff --git a/src/gui_gtk_x11.c b/src/gui_gtk_x11.c
> index 0454afb..a527945 100644
> --- a/src/gui_gtk_x11.c
> +++ b/src/gui_gtk_x11.c
> @@ -1258,6 +1258,10 @@ selection_received_cb(GtkWidget  *widget UNUSED,
>   	    if (tmpbuf != NULL)
>   	 text = tmpbuf;
>    }
> +
> + /* Switch multiline strings to MLINE */
> + if (vim_strchr(text, '\n') != NULL)
> +     motion_type = MLINE;
>       }
>
>       /* Chop off any traiing NUL bytes.  OpenOffice sends these. */
> diff --git a/src/gui_riscos.c b/src/gui_riscos.c
> index 90634fa..cbce7da 100644
> --- a/src/gui_riscos.c
> +++ b/src/gui_riscos.c
> @@ -2649,6 +2649,7 @@ clip_mch_request_selection(VimClipboard *cbd)
>       int  reason;
>       char_u *buffer;
>       long_u length;
> +    int  motion_type;
>
>       block[0] = 48; 	 /* Size of block. */
>       block[3] = 0; 	 /* Orinial message. */
> @@ -2715,7 +2716,10 @@ clip_mch_request_selection(VimClipboard *cbd)
>       if (xswi(OS_File, 16, "<Wimp$Scrap>", buffer, 0)&  v_flag)
>    return;
>
> -    clip_yank_selection(MCHAR, buffer, length, cbd);
> +    /* Determine appropriate motion type */
> +    motion_type = (vim_strchr(buffer, '\n') == NULL) ? MCHAR : MLINE;
> +
> +    clip_yank_selection(motion_type, buffer, length, cbd);
>
>       vim_free(buffer);
>
> diff --git a/src/ui.c b/src/ui.c
> index 9d940b1..67b27ee 100644
> --- a/src/ui.c
> +++ b/src/ui.c
> @@ -2098,6 +2098,10 @@ clip_x11_request_selection_cb(w, success,
> sel_atom, type, value, length,
>    }
>    p = (char_u *)text_list[0];
>    len = STRLEN(p);
> +
> + /* Switch multiline strings to MLINE */
> + if (vim_strchr(p, '\n') != NULL)
> +     motion_type = MLINE;
>       }
>       clip_yank_selection(motion_type, p, (long)len, cbd);
>
> @@ -2401,6 +2405,10 @@ yank_cut_buffer0(dpy, cbd)
>   {
>       int  nbytes = 0;
>       char_u *buffer = (char_u *)XFetchBuffer(dpy,&nbytes, 0);
> +    int  motion_type;
> +
> +    /* Determine appropriate motion type */
> +    motion_type = (vim_strchr(buffer, '\n') == NULL) ? MCHAR : MLINE;
>
>       if (nbytes>  0)
>       {
> @@ -2422,7 +2430,7 @@ yank_cut_buffer0(dpy, cbd)
>   	 conv_buf = string_convert(&vc, buffer,&nbytes);
>   	 if (conv_buf != NULL)
>   	 {
> - 	    clip_yank_selection(MCHAR, conv_buf, (long)nbytes, cbd);
> + 	    clip_yank_selection(motion_type, conv_buf, (long)nbytes, cbd);
>   		    vim_free(conv_buf);
>   		    done = TRUE;
>   	 }
> @@ -2431,7 +2439,7 @@ yank_cut_buffer0(dpy, cbd)
>    }
>    if (!done)  /* use the text without conversion */
>   #endif
> -     clip_yank_selection(MCHAR, buffer, (long)nbytes, cbd);
> +     clip_yank_selection(motion_type, buffer, (long)nbytes, cbd);
>    XFree((void *)buffer);
>    if (p_verbose>  0)
>    {
>
>
> 0001-Linewise-pasting-of-multi-line-selections-in-X-and-R.patch
>
>
>  From 76797820cfb212c3f185efcee2189eed4240ac5a Mon Sep 17 00:00:00 2001
> From: guns<self@...>
> Date: Tue, 3 May 2011 01:51:08 -0500
> Subject: [PATCH] Linewise pasting of multi-line selections in X and Risc OS
>
> Upon closer inspection, I have the following observations about vim's
> handling of foreign selections.
>
> When pasting from the "* or "+ register, vim requests a selection
> from the system clipboard. If the selection is not in a vim
> selection format:
>
>      - The mac, macosx, msdos, mswin, and qnx ports detect the presence
>        of a NL or CR (whatever is appropriate) _anywhere_ in the text and
>        switch the motion_type to MLINE
>
>      - The riscos, gtk-x11, and x11 ports always set motion_type to MCHAR
>
>      - In X, if the selection request fails, CUT_BUFFER0 is used, and is
>        also always set to MCHAR
>
> As you can see, vim's behavior wrt pasting foreign text is a little
> inconsistent. Most of the non-X ports linewise paste multi-line
> selections, while the X-based vims do not.
>
> While the X behavior is not a bug (it is actually explicitly
> documented), I believe it is surprising in this instance.
>
> When I copy a large multi-line selection in an application in order to
> transfer it into a vim buffer, I don't usually intend on engaging in a
> delicate mid-line paste operation. The major non-X GUI ports share this
> view, and scan the text for the presence of an EOL character.
>
> I should mention that scanning the selection buffer for an EOL could
> be costly if the user tries to paste a single, very long line from the
> X clipboard (minified javascript comes to mind). It would be nice in
> this instance to be able to use a reverse strchr (strrchr) on the likely
> chance that the line ends in a newline.

Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline
sentence from the middle of a paragraph? As in the example below, I
mean? With this newfangled system, I won't be able to insert it in the
middle of a different paragraph in Vim, except by calling setreg('+',
'', 'ac') to force it to characterwise.

Example (using [ and ] to show the ends of the visual selection)

Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut
fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem
sequi nesciunt, neque porro quisquam est, qui do[lorem ipsum, quia
dolor sit amet, consectetur, adipisci velit, sed quia non numquam ejus
modi tempora incidunt, ut labore et dolore magnam aliquam quaerat
voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem
ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi
consequa]tur? Quis autem vel eum jure reprehenderit, qui in ea voluptate
velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem
eum fugiat, quo voluptas nulla pariatur?


Best regards,
Tony.
--
Deliberation, n.:
	 The act of examining one's bread to determine which side it is
buttered on.
		 -- Ambrose Bierce, "The Devil's Dictionary"

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

> Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline sentence
> from the middle of a paragraph? As in the example below, I mean? With this
> newfangled system, I won't be able to insert it in the middle of a different
> paragraph in Vim, except by calling setreg('+', '', 'ac') to force it to
> characterwise.

That is the thing I find frustrating, too. I find it easier to whack my cursor
at
the beginning of a line or open a new line than split a line, paste linewise,
then
join lines again.

Someone did note a workaround for this, though: going into insert mode and using
Ctrl-R + to paste. This perhaps allows the best of both worlds (once the people
who, like me, prefer characterwise clipboard pasting, put together some mappings
to do it that way).

Cheers,

Ben.

P.S. Tony, I think you just won the award for the worst quote trimming ever. ;-)



--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

>>> I love vim, but must admit to not being so fond of the fairly old
>>> looking icon. I recently created a new logo for my own use, and
>>> would be more than happy if you'd like to use it for an actual app
>>> icon or logo.

I quite like the icon, too. I agree the old one (which in recent times, I've
only
seen in Windows), looks a bit dated if nothing else.

Another icon to look at/consider/etc. is the MacVim icon which, likewise, tried
to
modernise the old Vim icon somewhat, and I think did quite well. Can't remember
when it was done, who did it, or anything. But it has been rendered at multiple
sizes, and there are scripts that also create document icons with the MacVim
badge
and file extension printed on them for different file types. AFAIK, pretty much
everything needed for this is in the MacVim git repository. The icon format is
Mac-specific, I think, but it could probably be converted if other platforms
would
like to use it. I'm sure people are free to.

Ben.


--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On May 3, 3:42 am, Tony Mechelynck <antoine.mechely...@...>
wrote:
>
> Well, what if I yank (in Firefox, say, or in Thunderbird) a multiline
> sentence from the middle of a paragraph? As in the example below, I
> mean? With this newfangled system, I won't be able to insert it in the
> middle of a different paragraph in Vim, except by calling setreg('+',
> '', 'ac') to force it to characterwise.


One consolation is that browsers typically display <p> sections as
a single unbroken line. If your example was from the Wikipedia page on
Lorem Ipsum, for example, your selection would paste characterwise as
before.

With regards to email in your mail client, I suspect that most people
receive email that is not politely hard-wrapped at 72 characters, and
possibly the response therein is even top-posted for convenience. If
this does not describe your mail, then I am quite jealous.

Also, the fact that i_Ctrl-r always pastes characterwise is a very
nice
workaround (thank you Ben Schmidt - I think I will set up those
mappings
right now); you would have to explicitly type "*p or "+p to paste from
the X clipboard anyhow (unless clipboard=unnamed or unnamedplus).

Cheers,
Sung Pae

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Tue, May 3, 2011 at 3:58 AM, Ben Schmidt:

> This perhaps allows the best of both worlds (once the people who, like
> me, prefer characterwise clipboard pasting, put together some mappings
> to do it that way).

I'd like to mention that there is another way to resolve this issue:

Instead of scanning the whole selection buffer for an EOL character, you
could simply allow clip_yank_selection() to take MAUTO as a valid motion
type and then have it switch between MCHAR/MLINE depending on the value
of the LAST character only.

Currently this strategy is only being employed for setting registers
via `let @r = "foo\nbar\n"'. It would be simple to add the MAUTO
functionality to clip_yank_selection(), and then change all the
strchr(buf, '\n') calls in the OS ports to simply marking strings from
the clipboard as MAUTO.

I prefer this solution myself, since it allows very granular control of
the selection's motion type, but I surmised that it would be rejected
because it would change the behavior of all the OS versions, instead of
just one.

Also, this control is annoyingly incompatible with Firefox since it does
not seem to allow you to select a terminating newline.

Cheers,
Sung Pae

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 03-May-2011 Jean-Rene David <jrdavid.ml@...> wrote:
> Can someone reproduce this item from the todo list:
>
> When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero or two lines
> instead of one. (Constantin Pan, 2010 Sep 10)
>
> I can't. And I didn't find a message on either mailing lists on that
> subject around that date.

I can reproduce it. However, I need to set 'ls' to 0 for the problem to
show.

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Hi,

Jean-Rene David wrote:
> * Lech Lorens [2011.05.03 10:00]:
>> On 03-May-2011 Jean-Rene David <jrdavid.ml@...> wrote:
>>> Can someone reproduce this item from the todo list:
>>>
>>> When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero or two lines
>>> instead of one. (Constantin Pan, 2010 Sep 10)
>>>
>>> I can't. And I didn't find a message on either mailing lists on that
>>> subject around that date.
>>
>> I can reproduce it. However, I need to set 'ls' to 0 for the problem to
>> show.
>
> Still no luck for me, even with 'ls' set to 0. What version of vim are
> you using?

you might also have to adjust 'cmdheight' by 1. For me this happens with

   set lines=25 scrolloff=12 laststatus=0 cmdheight=1

on Windows with GVim 7.3.170. It also happens with

   set lines=26 scrolloff=12 laststatus=2 cmdheight=1

Seems it always happens if there is only one window and if

   2 * &scrolloff + &cmdheight + (&laststatus == 2 ? 1 : 0) == &lines

because

   set lines=25 scrolloff=10 laststatus=2 cmdheight=4

and

   set lines=23 scrolloff=10 laststatus=0 cmdheight=3

show the same bug.

Regards,
Jürgen

--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.     (Calvin)

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

* Lech Lorens [2011.05.03 10:00]:
> On 03-May-2011 Jean-Rene David <jrdavid.ml@...> wrote:
> > Can someone reproduce this item from the todo list:
> >
> > When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero or two lines
> > instead of one. (Constantin Pan, 2010 Sep 10)
> >
> > I can't. And I didn't find a message on either mailing lists on that
> > subject around that date.
>
> I can reproduce it. However, I need to set 'ls' to 0 for the problem to
> show.

Still no luck for me, even with 'ls' set to 0. What version of vim are
you using?

--
JR

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 4/05/11 12:11 AM, Jean-Rene David wrote:
> * Lech Lorens [2011.05.03 10:00]:
>> On 03-May-2011 Jean-Rene David<jrdavid.ml@...>  wrote:
>>> Can someone reproduce this item from the todo list:
>>>
>>> When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero or two lines
>>> instead of one. (Constantin Pan, 2010 Sep 10)
>>>
>>> I can't. And I didn't find a message on either mailing lists on that
>>> subject around that date.
>>
>> I can reproduce it. However, I need to set 'ls' to 0 for the problem to
>> show.
>
> Still no luck for me, even with 'ls' set to 0. What version of vim are
> you using?

I see the behaviour now, with 7.3.161.

Ben.



--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Jean-Rene David wrote:

> The following item from the todo list has been fixed in 7.3.029.
>
> ":sort n" treats empty line as higher than zero. (Beeyawned, 2010 Oct 13)
>
> Patch for todo.txt attached.

Thanks!

--
hundred-and-one symptoms of being an internet addict:
43. You tell the kids they can't use the computer because "Daddy's got work to
     do" and you don't even have a job.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 2011-05-03, Tim Cuthbertson wrote:
> On May 3, 8:18 am, "Christian J. Robinson" wrote:
> > On Mon, 2 May 2011, Tim Cuthbertson wrote:
> > > I love vim, but must admit to not being so fond of the fairly old
> > > looking icon. I recently created a new logo for my own use, and
> > > would be more than happy if you'd like to use it for an actual app
> > > icon or logo.
> >
> > I like this icon, but my problem is that it looks increasingly poor as
> > it is scaled down in size.  The small size on my taskbar looks
> > significantly worse than the default icon.
> >
> > - Christian
>
> Yes, that is a problem. I am not too concerned about it for my own
> personal use (I never see it smaller than ~86px), but I expect smaller
> variants would need to be created which increased contrast / line
> width for better representation at smaller sizes. If required I can
> have a go at doing this (or others can, the .svg is the original
> inkscape source), but I'd rather not bother if nobody is going to
> actually use it.

I do like the looks of your design, but I have no need for large
icons.  I cover my desktop with windows.  The icons I use are in the
panel/taskbar and measure about 24x24.  They need to be uniquely
identifiable and should look nice at that size.

The tiny icon used in the Windows Quick Launch, for example, is
crisp and easy to identify.  In contrast, the icon that appears in
the Fedora 11 panel is an unreadable blue-green blob that I've
learned to associate with gvim only through frequent use.

Regards,
Gary

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Tuesday, May 03, 2011 09:31:48 Jürgen Krämer wrote:

> Hi,

> Jean-Rene David wrote:
> > * Lech Lorens [2011.05.03 10:00]:
> >> On 03-May-2011 Jean-Rene David <jrdavid.ml@...> wrote:
> >>> Can someone reproduce this item from the todo list:
> >>>
> >>> When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero
> >>> or two lines instead of one. (Constantin Pan, 2010 Sep
> >>> 10)
> >>>
> >>> I can't. And I didn't find a message on either mailing
> >>> lists on that subject around that date.
> >>
> >> I can reproduce it. However, I need to set 'ls' to 0 for
> >> the problem to show.
> >
> > Still no luck for me, even with 'ls' set to 0. What version
> > of vim are you using?

> you might also have to adjust 'cmdheight' by 1. For me this
> happens with

>  set lines=25 scrolloff=12 laststatus=0 cmdheight=1

> on Windows with GVim 7.3.170. It also happens with

>  set lines=26 scrolloff=12 laststatus=2 cmdheight=1

> Seems it always happens if there is only one window and if

>  2 * &scrolloff + &cmdheight + (&laststatus == 2 ? 1 : 0) ==
> &lines

> because

>  set lines=25 scrolloff=10 laststatus=2 cmdheight=4

> and

>  set lines=23 scrolloff=10 laststatus=0 cmdheight=3

> show the same bug.

ok i can make it jump with these settings, but it isn't that
'j' is failing to advance through the file, it's that the
scroll offset moves

by reading seq into an empty module with

     :0r!seq 100

and scrolling with 'j', if you have 'cursorline' on you can
see current line moving up and down -- slow it down and you'll
see it is in fact moving through the file one line at a time
as it should, but the scrolloffset is not keeping current line
in the same place as one might expect

sc

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Hi Bram,
attached patch fixes this issue from todo.txt:

8   Add an event like CursorHold that is triggered repeatedly, not just
once after typing something.
Need for CursorHold that retriggers.  Use a key that doesn't do anything,
or a function that resets did_cursorhold.


regards,
Christian

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Am 04.05.2011 08:59, schrieb Christian Brabandt:
> Hi Bram,
> attached patch fixes this issue from todo.txt:
>
> 8   Add an event like CursorHold that is triggered repeatedly, not just
> once after typing something.
> Need for CursorHold that retriggers.  Use a key that doesn't do anything,
> or a function that resets did_cursorhold.

Could you please explain a bit more without requiring everybody to
inspect and understand the attachment?

ok .. did open ...

You use "CursorHoldR" for the event, that's a confusing name -- if
CursorHoldI is for Insert mode, then CursorHoldR must be for Overwrite
mode ... huh?
What about "CursorRepeat" instead ...

If the new event is active, does this mean that the CursorHold event
never fires?

Ah, no, what you actually do is: modify CursorHold to make it trigger
repeatedly (?).  "CursorHoldRepeat"

Then again, what about normal CursorHold events that I only want to get
triggered after X milliseconds or Y key presses ... how will both events
work together?  Does one event influence the other?

--
Andy

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Wed, May 4, 2011 11:19 am, Andy Wokula wrote:
> Am 04.05.2011 08:59, schrieb Christian Brabandt:
>> Hi Bram,
>> attached patch fixes this issue from todo.txt:
>>
>> 8   Add an event like CursorHold that is triggered repeatedly, not just
>> once after typing something.
>> Need for CursorHold that retriggers.  Use a key that doesn't do
>> anything,
>> or a function that resets did_cursorhold.
>
> Could you please explain a bit more without requiring everybody to
> inspect and understand the attachment?
>
> ok .. did open ...

Sorry, I'll try to be more verbose next time.

> You use "CursorHoldR" for the event, that's a confusing name -- if
> CursorHoldI is for Insert mode, then CursorHoldR must be for Overwrite
> mode ... huh?

Yeah I am not happy about the name. R stands for Repeat or Retrigger.
I am open for suggestions.

> What about "CursorRepeat" instead ...
>
> If the new event is active, does this mean that the CursorHold event
> never fires?
>
> Ah, no, what you actually do is: modify CursorHold to make it trigger
> repeatedly (?).  "CursorHoldRepeat"

No. after 'updatetime' passes, the CursorHold event triggers and
executes the CursorHold autocommands as well as
CursorHoldR autocommands. Afterwards, only CursorHoldR event retriggers
after every 'updatetime' passes.

> Then again, what about normal CursorHold events that I only want to get
> triggered after X milliseconds or Y key presses ... how will both events
> work together?  Does one event influence the other?

I haven't touched the logic, after when the event will be triggered.
That means, you would have to manually check, if X milliseconds have
been passed between each invocation. Not sure what you mean with
Y key presses (there is no such event I think).

Both autocommands are independent of each other, except that the
CursorHold event will also trigger CursorHoldR autocommands.

This is because I find it confusing if the CursorHoldR event
triggers first after 2 times 'updatetime' have been passed (after typing
something), but then retriggers after every 'updatetime'

regards,
Christian

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Am 04.05.2011 11:49, schrieb Christian Brabandt:
> On Wed, May 4, 2011 11:19 am, Andy Wokula wrote:
>> Am 04.05.2011 08:59, schrieb Christian Brabandt:
>>> Hi Bram,
>>> attached patch fixes this issue from todo.txt:
>>>
>>> 8   Add an event like CursorHold that is triggered repeatedly, not
>>> just once after typing something.
>>> Need for CursorHold that retriggers.  Use a key that doesn't do
>>> anything, or a function that resets did_cursorhold.

>> You use "CursorHoldR" for the event, that's a confusing name -- if
>> CursorHoldI is for Insert mode, then CursorHoldR must be for
>> Overwrite mode ... huh?
>
> Yeah I am not happy about the name. R stands for Repeat or Retrigger.
> I am open for suggestions.
>
>> What about "CursorRepeat" instead ...
>>
>> If the new event is active, does this mean that the CursorHold event
>> never fires?
>>
>> Ah, no, what you actually do is: modify CursorHold to make it trigger
>> repeatedly (?).  "CursorHoldRepeat"
>
> No. after 'updatetime' passes, the CursorHold event triggers and
> executes the CursorHold autocommands as well as CursorHoldR
> autocommands. Afterwards, only CursorHoldR event retriggers after
> every 'updatetime' passes.

OK!

>> Then again, what about normal CursorHold events that I only want to
>> get triggered after X milliseconds or Y key presses ... how will both
>> events work together?  Does one event influence the other?
>
> I haven't touched the logic, after when the event will be triggered.
> That means, you would have to manually check, if X milliseconds have
> been passed between each invocation. Not sure what you mean with Y key
> presses (there is no such event I think).

"Y keypresses" ... I confused that with swapfile syncing, please ignore.

> Both autocommands are independent of each other, except that the
> CursorHold event will also trigger CursorHoldR autocommands.
>
> This is because I find it confusing if the CursorHoldR event triggers
> first after 2 times 'updatetime' have been passed (after typing
> something), but then retriggers after every 'updatetime'

OK, makes sense, CursorHoldR should behave like CursorHold plus
retriggering.  I guess that's why an additional version for Insert
mode isn't needed.

Thanks for your explanations :-)

--
Andy

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On 2011-05-03, Sung Pae wrote:

> Gary, would you mind running your tests again with this patch? Yanking
> multi-line selections from Firefox should be just fine, since it no
> longer just looks at the last character to determine the motion type.

Sung Pae,

Thanks for the new patch.  I reverted your previous patch and
applied this one.

Test 1a

     *   Start vim as "vim -N -u NONE".  (I replaced the previous
         version of vim in my PATH with this patched version.)
     *   Read some text into vim with ":r !ls -l".
     *   Triple-click on the Vim 7.3 release notice from vim.sf.net
         ("[2010-08-15] Finally, ... Moolenaar)")
     *   Paste into the middle of a line in the middle of the vim
         screen with

             "*p

     *   The text is pasted character-wise, that is, is inserted in
         the middle of the line with no newlines.

     This is the same behavior as before, but may be because Firefox
     may not put a newline in the copied text.

Test 1b

     *   Set up vim as before.
     *   On the vim.sf.net page, select the text from "Vim charity
         update" through the end of the Vim 7.3 release notice by
         left-clicking and dragging the mouse over it.
     *   Paste into the middle of a line in the middle of the vim
         screen with

             "*p

     *   This time the text is pasted line-wise below the cursor.

     I didn't test this case with the previous patch.  An unpatched
     vim pastes this character-wise.

Test 2

     *   Set up vim as before.
     *   Move the cursor to the middle of some line below the top of
         the screen and copy three lines with

             Vjj"+y

     *   Exit vim, then restart and set up as before.
     *   Move the cursor to the middle of a line in the middle of the
         screen and paste with

             "+p

     *   The text is pasted line-wise below the cursor.  (It was
         pasted character-wise with the previous patch.)

     This one is weird.  From this experiment, the patch appears to
     work correctly.  The first time I tried it, though, it pasted
     character-wise.  I've been repeating this one a number of times
     and sometimes it pastes line-wise and sometimes it pastes
     character-wise.  I've been copying lines randomly and pasting
     them in random positions, but I _think_ I've done all the other
     steps the same way.  I haven't found a pattern yet.

I replied to your message of May 2, but I never received a copy from
the list.  I haven't checked the web interface to see if it wasn't
received by the list or whether I just didn't receive my copy.

Regards,
Gary

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On May 4, 5:05 am, Andy Wokula <anw...@...> wrote:
>
> > Both autocommands are independent of each other, except that the
> > CursorHold event will also trigger CursorHoldR autocommands.
>
> > This is because I find it confusing if the CursorHoldR event triggers
> > first after 2 times 'updatetime' have been passed (after typing
> > something), but then retriggers after every 'updatetime'
>
> OK, makes sense, CursorHoldR should behave like CursorHold plus
> retriggering.  I guess that's why an additional version for Insert
> mode isn't needed.
>

I don't follow why an additional Insert mode event would not be
needed. What if we want an action to occur repeatedly in insert mode?
If it acts like CursorHold plus retriggering, then CursorHoldR is only
usable in Normal mode.

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Am 04.05.2011 21:12, schrieb Ben Fritz:
> On May 4, 5:05 am, Andy Wokula<anw...@...>  wrote:
>>
>>> Both autocommands are independent of each other, except that the
>>> CursorHold event will also trigger CursorHoldR autocommands.
>>
>>> This is because I find it confusing if the CursorHoldR event triggers
>>> first after 2 times 'updatetime' have been passed (after typing
>>> something), but then retriggers after every 'updatetime'
>>
>> OK, makes sense, CursorHoldR should behave like CursorHold plus
>> retriggering.  I guess that's why an additional version for Insert
>> mode isn't needed.
>
> I don't follow why an additional Insert mode event would not be
> needed. What if we want an action to occur repeatedly in Insert mode?
> If it acts like CursorHold plus retriggering, then CursorHoldR is only
> usable in Normal mode.

He, you're right ... my guess was both CursorHold and CursorHoldI would
(at least in the final patch) trigger CursorHoldR -- but indeed, that
will not be sufficient.

--
Andy

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Hi Ben!

On Mi, 04 Mai 2011, Ben Fritz wrote:

>
>
> On May 4, 5:05 am, Andy Wokula <anw...@...> wrote:
> >
> > > Both autocommands are independent of each other, except that the
> > > CursorHold event will also trigger CursorHoldR autocommands.
> >
> > > This is because I find it confusing if the CursorHoldR event triggers
> > > first after 2 times 'updatetime' have been passed (after typing
> > > something), but then retriggers after every 'updatetime'
> >
> > OK, makes sense, CursorHoldR should behave like CursorHold plus
> > retriggering.  I guess that's why an additional version for Insert
> > mode isn't needed.
> >
>
> I don't follow why an additional Insert mode event would not be
> needed. What if we want an action to occur repeatedly in insert mode?
> If it acts like CursorHold plus retriggering, then CursorHoldR is only
> usable in Normal mode.

That is easy enough to add. I have a working version ready. Should that
be called CursorRepeat/CursorRepeatI or CursorHoldRepeat/
CursorHoldRepeatI? Other suggestions?

Mit freundlichen Grüßen
Christian

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

On Wed, 4 May 2011, Christian Brabandt wrote:

> On Mi, 04 Mai 2011, Ben Fritz wrote:
>> On May 4, 5:05 am, Andy Wokula wrote:
>>>
>>>> Both autocommands are independent of each other, except that the
>>>> CursorHold event will also trigger CursorHoldR autocommands.
>>>
>>>> This is because I find it confusing if the CursorHoldR event
>>>> triggers first after 2 times 'updatetime' have been passed (after
>>>> typing something), but then retriggers after every 'updatetime'
>>>
>>> OK, makes sense, CursorHoldR should behave like CursorHold plus
>>> retriggering.  I guess that's why an additional version for Insert
>>> mode isn't needed.
>>>
>>
>> I don't follow why an additional Insert mode event would not be
>> needed. What if we want an action to occur repeatedly in insert mode?
>> If it acts like CursorHold plus retriggering, then CursorHoldR is
>> only usable in Normal mode.
>
> That is easy enough to add. I have a working version ready. Should
> that be called CursorRepeat/CursorRepeatI or CursorHoldRepeat/
> CursorHoldRepeatI? Other suggestions?

I'm not quite following all of this.  What's the use case for firing an
event every X milliseconds *if the user isn't moving the cursor*?

Wouldn't it be far more useful to have something like JavaScript-style
setInterval()?  (which runs a function every X milliseconds, and the
returned 'interval ID' can be used to stop the repeating via
'clearInterval()')

I'd much rather see something like that make it into Vim, rather than
just extending CursorHold{,I} to CursorHoldRepeat{,I} simply because
it's fairly straightforward in terms of the implementation details.
(Not that I'm terribly opposed to this change; I just don't see the
rationale.)

--
Best,
Ben H

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

äÍÉÔÒÉÊ æÒÁÎË wrote:
> Hi.
>
> I very like Vim, thank you, but there's one thing in Vim that i really
> hate.
>
> I often use rather old notebook with processor Pentium M 1.6 GHz, and
> when i use Vim on it, i can't normally edit files *.vim and *.php :
> syntax highlighting for these filetypes is VERY SLOW.
>
> And i'm sure that 1.6 GHz is pretty enough for syntax highlighting.
> Some IDEs and just editors i tested works fine: SlickEdit, UltraEdit,
> PHP Expert Editor.
>
> I tested Vim both on Windows and Linux: lags the same. And other
> editors works fine.
> And this is Vim! Vim was always positioned as extremely fast editor,
> when compared with IDEs. But there's fact: IDE works fast, Vim is
> slow, on the same hardware.
>
> I believe that Vim handles syntax highlighting not in the best
> possible manner. I have to turn syntax off while editing *.vim and
> *.php files on this machine, and i very don't like this.
>
> I have two questions:
> 1) Do you have plans to improve syntax highlight handling, to make it
> faster?
> 2) Is there maybe simplified syntax files for *.vim and/or *.php
> files? Or any other way to solve this trouble without turning syntax off?
>
You could try "simplifying" the syntax files yourself. The slowest
portion of syntax highlighting involves "syn match ..." and "syn region
..."; ie. regular expression handling. To speed things up:

a) copy a system version of the syntax file you're interested in to your
home directory; ie. to $HOME/.vim/syntax or something like that.
b) Remove all lines from your personal copy that have "syn match ..."
and "syn region" in them, leaving only "syn keyword .." lines to do the
syntax highlighting.

Although this operation will not produce the same highlighting as the
unaltered files, and won't support syntax-based folding, I would expect
it to produce faster syntax highlighting.

As an easier item: look into :help syn-sync . Perhaps you can reduce
maxlines.

Syntax highlighting is known to be slow for loooooong lines. Try
breaking any long lines up a bit (ie. those >100 characters in the line,
as a rough criterion).

BTW, your 1.6GHz machine should be fine with syntax highlighting as-is.
Is it still "too slow" if you...

vim -u NONE somefile.vim
:set nocp
:syn on

I'm wondering if your slowdown is due to something other than just
syntax highlighting. This method of startup is barebones; no plugins, no
.vimrc, pretty much just syntax highlighting.

Regards,
Chip Campbell


--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Christian Brabandt wrote:

> Hi Bram,
> attached patch fixes this issue from todo.txt:
>
> 8   Add an event like CursorHold that is triggered repeatedly, not just
> once after typing something.
> Need for CursorHold that retriggers.  Use a key that doesn't do anything,
> or a function that resets did_cursorhold.

Thanks.  Did you verify it actually keeps triggering in various
environments?  Esp. terminal, GUI and Windows console.

>  /*
> - * Return TRUE if the CursorHold event can be triggered.
> + * Return 1 if the CursorHold event can be triggered.
> + * Return 2 if the CursorHoldR event can be triggered.
>   */
>      int
>  trigger_cursorhold()

It's simpler if you have it either return zero, KE_CURSORHOLD or
KE_CURSORHOLDR.

Would we need a separate CursorHoldRepeat and CursorHoldRepeatI?  So
that we can separate Normal and Insert mode?  Would at least be more
consistent.

--
hundred-and-one symptoms of being an internet addict:
51. You put a pillow case over your laptop so your lover doesn't see it while
     you are pretending to catch your breath.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Jean-Rene David wrote:

> * Bram Moolenaar [2011.05.02 14:00]:
> > One thing you do need to do: Add the tag to the help files
> > somewhere.  When a user sees an error message, he should be able to type
> > :help E123 to get more information about what's wrong.
>
> Done. The completed patch is attached once more. Note that the patch
> also removes the item from the todo list. That way it's all nice and
> self-contained. :-)

Nice, thanks.  I'll include it.

--
hundred-and-one symptoms of being an internet addict:
50. The last girl you picked up was only a jpeg.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Sung Pae wrote:

> Upon closer inspection, I have the following observations about vim's
> handling of foreign selections.
>
>
> When pasting from the "* or "+ register, vim requests a selection
> from the system clipboard. If the selection is not in a vim
> selection format:
>
>     - The mac, macosx, msdos, mswin, and qnx ports detect the presence
>       of a NL or CR (whatever is appropriate) _anywhere_ in the text and
>       switch the motion_type to MLINE
>
>     - The riscos, gtk-x11, and x11 ports always set motion_type to MCHAR
>
>     - In X, if the selection request fails, CUT_BUFFER0 is used, and is
>       also always set to MCHAR
>
> As you can see, vim's behavior wrt pasting foreign text is inconsistent.
> Most of the non-X ports linewise paste multi-line selections, while the
> X-based vims do not.
>
> While the X behavior is not a bug (it is actually explicitly
> documented), I believe it is surprising in this instance.
>
> When I copy a large multi-line selection in an application in order to
> transfer it into a vim buffer, I don't usually intend on engaging in a
> delicate mid-line paste operation. The major non-X GUI ports evidently
> share this view.

We need to think of various things the user wants to do and how he can
make it work.  I think it's not unusual to copy a few lines, starting
halfway a line and ending halfway a line.  E.g., a sentence that is
split over multiple lines.  And then the user would like to paste it
somewhere inside an existing line.  If we would make the selection
linewise, the user would first have to break the line, paste the text
linewise, then join the lines back together.  This is possible, but a
bit clumsy.

I would rather use the linewise selection only when the text ends in a
line break.  I think in most situations the user can select the text
either with or without a terminating NL.  At least in xterm you can.

If I understand the other remarks correctly, there are situations where
it's not possible to get a terminating NL.  That means the selection
won't become linewise, thus we get the current behavior.  That's not too
bad.  Depending on where the text is pasted, the user would have to
insert a line break before and/or after the pasted text.  The cursor
should be at the end, thus if the user pastes in front of a line it's a
matter of inserting a line break there.

To make it consistent, we would also have to change the operating
systems that currently find a NL or CR anywhere in the selection.
I wonder if anybody would have a problem with that.


--
Never go to the toilet in a paperless office.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Jean-Rene David wrote:

> Can someone reproduce this item from the todo list:
>
> When 'lines' is 25 and 'scrolloff' is 12, "j" scrolls zero or two lines
> instead of one. (Constantin Pan, 2010 Sep 10)
>
> I can't. And I didn't find a message on either mailing lists on that
> subject around that date.

This is the description I received:

> Hello. I've found a weird behavior of vim when scrolling down. If you
> set the 'scrolloff=X' and window height to (2*X+1), then on 'j' Vim
> scrolls down in a broken manner (two lines at once, then zero lines,
> then two again). The cursor acts correctly though, moving down one
> line per 'j'. See the screenshots joined in the attached gif.
>
> How to reproduce the bug (X is here 12, but the bug evinces itself on
> any value of X):
>
> 1. Set terminal height to (2*X+1) lines, i.e. 25. So, that:
>
> $ echo $LINES
> 25
>
> 2. Run Vim with scrolloff=X.
>
> $ hexdump /dev/urandom | head -100 | vim "+set scrolloff=12" "+set number" -
>
> 3. Press 'j' to move the cursor down until the scrolling starts. Watch
> line numbers on the left increasing by 2 on every second 'j'.
>
> Scrolling up works fine. GVim acts likewise. I've also tried on
> another machine (with Debian), and the bug shows up there.

-
CVS sux, men don't like commitment

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php