Raul Segura wrote:

> word-wise selection is not working properly.
>
> doble click selects the word under the cursor, but then draging the mouse
> makes the selection character-wise, with vim 5.7 the selection is always
> word-wise while draging the mouse.

I don't see it working wordwise in Vim 5.7 either.  You need to double-click
the right button extend by a word.  There is no word-wise mode (I have been
annoyed by applications that do select by words and not allow you to select by
character when you want to).

--
hundred-and-one symptoms of being an internet addict:
1. You actually wore a blue ribbon to protest the Communications Decency Act.

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

Raul Segura wrote:

> after change some text in "select" mode, everytime you type "."
> to repeat the change a "c" character is added at the beginning of
> the "." register before it's inserted.
>
> for example if I "select" some text and replace it with the word
> "Vim" the next "." command would insert "cVim", a second "."
> would insert "ccVim", and so on.

I see the problem.  The flag that indicates select mode isn't reset.  This
patch should fix it:

*** getchar.c~ Mon Feb 26 19:46:35 2001
--- getchar.c Wed Feb 28 10:17:28 2001
***************
*** 798,803 ****
--- 798,804 ----
       {
  	 VIsual = curwin->w_cursor;
  	 VIsual_active = TRUE;
+  VIsual_select = FALSE;
  	 VIsual_reselect = TRUE;
  	 redo_VIsual_busy = TRUE;
  	 c = read_redo(FALSE, old_redo);

--
login: yes
password: I don't know, please tell me
password is incorrect
login: yes
password: incorrect

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

Benji Fisher wrote:

>      The problem is that :setlocal com& sets 'comments' to the default
> value, which includes n:>.  Try adding "com-=n:>" (without the quotes)
> to the :setlocal line.  When you are done, try :set com to see what
> value the option ends up with, compare with :help comments, and let us
> (and the maintainer of the ftplugin file) know whether there are any
> other pieces that should be removed.  BTW, is there a cpp.vim ftplugin?

I think I know the maintainer of the plugin. :-)

There are more parts in the default value of 'comments' that might cause
trouble in a C file.  Setting the option to a string, instead of removing
parts that are not wanted would be possible, but then bits that were added by
the user will also be lost.

What I have now is this:

setlocal com& com^=sO:*\ -,mO:*\ \ ,exO:*/ com-=b:# com-=n:> com-=fb:- com-=:%

--
hundred-and-one symptoms of being an internet addict:
5. You find yourself brainstorming for new subjects to search.

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

Robert Webb wrote:

>     - With 'mousefocus' set, ^Wh or ^W<Left> don't work.  Neither does
>       ^W^W to move to a window on the left.  Seems no commands will
>       move you to a window that's on the left.

I can see why this happens.  Patch below.

>     - syntax.txt, line 2790, lists builtin :highlight types.  They are
>       alphabetical order except for the last three.

I'll fix that.

>     - The old "WinEnd" group appears to have changed to "NonText".  I
>       always had this set to a very dark blue, in fact so dark that
>       you can't really read it.  I didn't really want to be able to
>       see the "~"s at the end or the occasional line of "@"s too
>       clearly since they are not of interest other than vague
>       place-holders.  Anyway, now all ctrl characters are coloured
>       this way, both in the text and in :-commands.  I guess it just
>       means I'll have to change to a more readable colour.  Pity since
>       I don't really care to see all those "~"s at the end too
>       clearly.
>       Maybe it's just that it seems to me like there's a difference
>       between real characters, which aren't printable, and characters
>       which aren't even there.  Maybe there should be separate
>       highlight groups for these?

Was there a WinEnd group in Vim 5.7?  I can't find it.

Perhaps we should use NonText for the "~" lines and 'showbreak', and use
SpecialKey for unprintable characters?

>     - I would have expected the vertical split bar to be in the same
>       colour as the horizontal split bar, using the StatusLine group.
>       Would this be possible?  Or maybe to have its own highlight
>       group?  I couldn't find one in the docs.

There is the FillColumn group for this.

>     - I'd suggest the default for 'winwidth' should be 1, since it is
>       unexpected behaviour for a window to suddely get bigger when the
>       user hasn't requested it.  Especially noticable I guess with
>       'mousefocus' set.

I don't expect many people to have 'mousefocus' set.  You would have to reduce
'winwidth' yourself if you set 'mousefocus'.   A window smaller than about 20
characters has the problem that the status line can't show much.  And with a
normal 80 columns window it means you have split it four times, which is quite
a lot.

>     - If you split vertically (^Wv), then split the window on the left
>       horizontally (^Ws) and put the mouse over the character where
>       the two split bars meet, you'd expect it to control the vertical
>       bar, to slide it left or right.  Instead it controls the
>       horizontal bar up or down, even though the character under the
>       mouse is from the vertical bar.

If you do it the other way (horizontal split first, then vertical split) then
the character right of the status line is part of the status line, and should
be used to resize up-down (and it does).  Making this difference is a bit
complicated.  Still, the code exists in win_redr_status(), thus it could be
made to work correctly.

>     - In 6.0w Ctrl-_ now comes out as Ctrl-^ instead.  In 5.7 the two
>       were different.  This means I can't use one of my favourite
>       commands anymore, ^W^_, to make the current window take up as
>       much space as possible.  Instead I can use ^W_, but that's quite
>       a bit harder to type.  Ah, but I can type ^_ by holding down
>       Ctrl+Shift+minus.  Normally you should only need Ctrl+minus.  I
>       remember this bug being fixed in 5.x at some point.  Did it get
>       lost on the way to 6.0?

It looks like the patch for EBCDIC made a mistake here.  It replaces CTRL('-')
with Ctrl_HAT instead of Ctrl__.  Patch below.

>     - Didn't ":tn" in a help window used to take you to the next
>       matching help tag?  Now it always says there's only one matching
>       tag.  Try ":h min".  Doing ^D shows lots of matches, but how do
>       you get to them?

I don't think this ever worked with ":tn".  You can do it if you are inside a
help window:  ":ta /min".  But you don't get the clever translations then.

>     - ":h ^W_" takes you to help for "^W^" instead, I suppose since
>       there's an underscore separating the ^W and the ^ in the tag
>       label.  However, doing the same command again does take you to
>       the right place.  Repeating the command again leaves you at the
>       right place.

For me it always jumps to the "wrong" place, which is CTRL-W_=.  I suppose the
translation of ^W to CTRL-W could check for a single-letter argument and
insert the _.

>     - "h ^W^_" doesn't work unless ^_ is a real control character, as
>       opposed to a "^" followed by a "_".

That ^_ should be translated to CTRL-_.  I'll try to add it.

>     - This is nothing new, but I still wish there was a way to use
>       wildmenu, without tying up the left and right arrow keys.  I'm
>       constantly stuffing up, and trying to use them to move the
>       cursor left after completing something, which instead finds a
>       different match.  Could we add an option to 'wildmenu' to
>       disable arrow keys?  I imagine other people still want to be
>       able to use them.  Personally I never use them for that purpose
>       since you have to use Tab to start the completion, so you might
>       as well just keep hitting it to search through the different
>       completions, or Shift-Tab to search backwards.

I don't want to add yet another option for this.  There are so many choices
for the user already.  I also use Tab and shift-Tab to select the matches, but
shift-Tab doesn't work in all terminals.  I mostly type a space to get out of
wildmenu mode and then move the cursor.  That's not really good either.

I suppose we need a character that gets you out of wildmenu mode, without side
effects.  Then you can map cursor-left.  Hmm, doesn't this work:
	 :cnoremap <Left> <Space><BS><Left>

>     - The Edit menu has the usual Cut, Copy and Paste, but then it has
>       Put Before and Put After, which use vim's yank buffer rather
>       than the clipboard like the previous commands.  Maybe we should
>       also have Paste Before and Paste After to avoid confusion?

What does Paste normally do?  I guess it puts the text before the cursor (at
least in Insert mode).  Perhaps we should make it "Paste", "Paste after",
"put" and "put after"?

> Other than that, it looks very good.  The best thing is, well, that it
> doesn't look any different!  It happily processed my almost 2000 line
> _vimrc without a comment.  I like the cursor shape change when over
> the status bar.  Oh, and somehow I seem to fit four more lines of text
> on the screen now!  Are the lines squished together more than before?
> Other than that I haven't looked far into the new features yet.  I
> haven't even tried folding!

I'm glad the switch from 5.7 to 6.0 doesn't cause too much trouble.  Keep
checking for problems!


*** gui.c~ Sat Feb 24 14:54:23 2001
--- gui.c Wed Feb 28 12:24:58 2001
***************
*** 3532,3538 ****
  	 if (wp != curwin && wp != NULL) /* If in other than current window */
  	 {
  	     validate_cline_row();
! 	    gui_mch_setmouse((int)Columns * gui.char_width - 3,
  			  (W_WINROW(curwin) + curwin->w_wrow) * gui.char_height
  						      + (gui.char_height) / 2);
  	 }
--- 3532,3538 ----
  	 if (wp != curwin && wp != NULL) /* If in other than current window */
  	 {
  	     validate_cline_row();
! 	    gui_mch_setmouse((int)W_ENDCOL(curwin) * gui.char_width - 3,
  			  (W_WINROW(curwin) + curwin->w_wrow) * gui.char_height
  						      + (gui.char_height) / 2);
  	 }

*** gui_w48.c~ Sat Feb 24 19:27:25 2001
--- gui_w48.c Wed Feb 28 12:51:06 2001
***************
*** 1855,1861 ****
  		 /* vk == 0xDB AZERTY for CTRL-'-', but CTRL-[ for * QWERTY! */
  		 else if (vk == 0xBD) /* QWERTY for CTRL-'-' */
  		 {
! 		    string[0] = Ctrl_HAT;
  		     add_to_input_buf(string, 1);
  		 }
  		 /* Japanese keyboard map '^' to vk == 0xDE */
--- 1855,1861 ----
  		 /* vk == 0xDB AZERTY for CTRL-'-', but CTRL-[ for * QWERTY! */
  		 else if (vk == 0xBD) /* QWERTY for CTRL-'-' */
  		 {
! 		    string[0] = Ctrl__;
  		     add_to_input_buf(string, 1);
  		 }
  		 /* Japanese keyboard map '^' to vk == 0xDE */

--
hundred-and-one symptoms of being an internet addict:
10. And even your night dreams are in HTML.

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

Mary Ellen Foster wrote:

> Is it possible to have the "quickfix" window (created by :cw) scroll
> appropriately when you use the :cn and :cp commands? I find myself using
> a mixture of the two, and I keep having to figure out where in the
> errorlist I am if I want to go back to the quickfix window.

Hmm, that sounds like a reasonable thing to do.  It will also help when the
error message is too long to fit in the command line.  You can see the whole
error in the quickfix window then.  I'll make a remark in the todo list.

--
hundred-and-one symptoms of being an internet addict:
13. You refer to going to the bathroom as downloading.

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

Mark Brophy wrote:

>  I do a lot of java programming with vim, and have recently
> gotten around to using the includeexpr option to search through
> imported files. This is great, but I expected it to work with
> commands like gf, and ^wf as well.
> Since I use those commands a lot when programming in C, it's
> annoying when it doesn't work in java. Is it possible to add
> another option fnameexpr, which does the same thing as
> includeexpr?

I wonder if you want to change the name of the file in all situations.  And
'suffixesadd' is also used.  This is getting a bit complicated.

Perhaps "gf" could be changed to first try finding the file unmodified, and
then processed through 'includeexpr'?  Somehow that sounds logical.
Especially when you use "gf" on a file name in an "include" line.

> While using 5.x, I made a change to the file explorer script
> to jump to the current directory when hitting 'g', so I
> could jump all over the place easily with macros.
> I was also thinking it would be great to have the ability to
> cycle through the directories in the current path, as well
> as being able to add the current directory to the path.
>
> Is someone maintaining the distributed file explorer?
> or should I do it myself and post patches?

The explorer script is maintained.  But the idea is to keep it simple.  The
danger with any file explorer is that everybody has some nice feature he would
like to have added.  "it would be nice" isn't a  good enough reason to add
something.

--
hundred-and-one symptoms of being an internet addict:
12. You turn off your modem and get this awful empty feeling, like you just
     pulled the plug on a loved one.

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

From: Bram Moolenaar [mailto:Bram@...]
> There are more parts in the default value of 'comments' that
> might cause trouble in a C file.  Setting the option to a string,
> instead of removing parts that are not wanted would be possible,
> but then bits that were added by the user will also be lost.

But surely the setlocal com& gets rid of anything the user has added anyway?
(I don't see this as a problem, the user can add things in after/c.vim)

Using com& leaves you having to change things when Vim's default changes.
Using a fixed value gives you full control. The only difference is if the
maintainer doesn't notice when the Vim maintainer changes the default value
:-)

Paul.

Paul Moore wrote:

> From: Bram Moolenaar [mailto:Bram@...]
> > There are more parts in the default value of 'comments' that
> > might cause trouble in a C file.  Setting the option to a string,
> > instead of removing parts that are not wanted would be possible,
> > but then bits that were added by the user will also be lost.
>
> But surely the setlocal com& gets rid of anything the user has added anyway?
> (I don't see this as a problem, the user can add things in after/c.vim)

Right, resetting 'comments' to its default gets rid of anything the user has
set.  And omitting that probably isn't a good idea, since it makes the value
unpredictable.  I'll change it to set the value directly.

> Using com& leaves you having to change things when Vim's default changes.
> Using a fixed value gives you full control. The only difference is if the
> maintainer doesn't notice when the Vim maintainer changes the default value
> :-)

That happens all the time (I have used fdisk to partition my brain :-).

--
hundred-and-one symptoms of being an internet addict:
14. You start introducing yourself as "Jim at I-I-Net dot net dot au"

  ///  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:
>
> Raul Segura wrote:
>
> > word-wise selection is not working properly.
> >
> > doble click selects the word under the cursor, but then draging the mouse
> > makes the selection character-wise, with vim 5.7 the selection is always
> > word-wise while draging the mouse.
>
> I don't see it working wordwise in Vim 5.7 either.  You need to double-click
> the right button extend by a word.  There is no word-wise mode (I have been
> annoyed by applications that do select by words and not allow you to select by
> character when you want to).

      I also see a change from 5.7 to 6.0v, on W95.  In gvim 5.7,
double-clicking the left mouse selects a word.  Double-clicking and then
dragging selects additional words.  In gvim 6.0v, I get additional
characters.  In both versions, I have 'mouse' set to a and 'mousemodel'
set to extend.  Are there any other options I should check?

					 --Benji Fisher

Bram Moolenaar wrote:
>
> Mark Brophy wrote:
> > Since I use those commands a lot when programming in C, it's
> > annoying when it doesn't work in java. Is it possible to add
> > another option fnameexpr, which does the same thing as
> > includeexpr?
>
> I wonder if you want to change the name of the file in all situations.  And
> 'suffixesadd' is also used.  This is getting a bit complicated.
>
> Perhaps "gf" could be changed to first try finding the file unmodified, and
> then processed through 'includeexpr'?  Somehow that sounds logical.
> Especially when you use "gf" on a file name in an "include" line.

Ah ok, I guess the only time you really want to process a filename
somehow is when it's coming from a keyword within the text.  Are 'gf'
and ^wf the only times this will happen?

> The explorer script is maintained.  But the idea is to keep it simple.  The
> danger with any file explorer is that everybody has some nice feature he would
> like to have added.  "it would be nice" isn't a  good enough reason to add
> something.

Perhaps just the ability to go to the current directory then? That
way anything interesting like jumping through the path can be kept
outside the file explorer in macros etc?

	 Mark Brophy

> vipin aravind wrote:
>
> Build  for win32 breaks in ex_cmds.c due to undefined VIMINFO.How do I
> avert it?
> vipin

      We need a lot more details.  What files did you get?  What compiler
are you using?  What command did you give to the compiler?

					 --Benji Fisher

Mark Brophy wrote:

> Perhaps just the ability to go to the current directory then? That
> way anything interesting like jumping through the path can be kept
> outside the file explorer in macros etc?

Do you mean like what ":e ." does?  Well, there you have it.

--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
     site address in print or on TV, even though you've never had heart
     problems before.

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

Benji Fisher wrote:

> Bram Moolenaar wrote:
> >
> > Raul Segura wrote:
> >
> > > word-wise selection is not working properly.
> > >
> > > doble click selects the word under the cursor, but then draging the mouse
> > > makes the selection character-wise, with vim 5.7 the selection is always
> > > word-wise while draging the mouse.
> >
> > I don't see it working wordwise in Vim 5.7 either.  You need to double-click
> > the right button extend by a word.  There is no word-wise mode (I have been
> > annoyed by applications that do select by words and not allow you to select
by
> > character when you want to).
>
>      I also see a change from 5.7 to 6.0v, on W95.  In gvim 5.7,
> double-clicking the left mouse selects a word.  Double-clicking and then
> dragging selects additional words.  In gvim 6.0v, I get additional
> characters.  In both versions, I have 'mouse' set to a and 'mousemodel'
> set to extend.  Are there any other options I should check?

Oh, wait.  I was trying a double click and then dragging or clicking with the
right mouse button.  If you click and then click-drag I can see the
difference.  I suppose the wordwise selection should work like in 5.7 then.
I'll find out if that can be fixed.

--
hundred-and-one symptoms of being an internet addict:
16. You step out of your room and realize that your parents have moved and
     you don't have a clue when it happened.

  ///  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:
>
> Mark Brophy wrote:
>
> > Perhaps just the ability to go to the current directory then? That
> > way anything interesting like jumping through the path can be kept
> > outside the file explorer in macros etc?
>
> Do you mean like what ":e ." does?  Well, there you have it.

hehe. Didn't think of that. Thanks. 8)

	 Mark Brophy.

I'm currently using vim6.0v under win2k.
When sections within the text are folded, scrolling past text
with the keyboard works as expected, but when using a wheel mouse,
or the scrollbar the folds are treated as their internal
height, and scrolling past them takes a lot longer.

eg. If I'm scanning through the code of a function, and there's
a large function above it that's been folded (but is still
on the display), scrolling the mouse wheel down doesn't move
the text until it's scrolled through the folded text.

Is this a bug, or is it intended?

	 Mark Brophy.

i noticed that css.vim is missing quite a few keywords and such and was
wondering how one goes about getting it updated. should one e-mail the
maintainer and complain (hehe) or send him a patch or problem
description or what?

--
/***************************************************************************
  * Name:        Nikolai Weibull
  * Nick:        pcp
  * A.K.A:       pcppopper
  * Likes:       a certain girl, open-minded people, his nickname
  * Dislikes:    intolerance
  * System:      Midi ATX, ASUS CUV4X, Celeron 667@950, GeForce2 MX 32,
  *              256mb PC133, Fujitsu 20.49gb UDMA-66
  * E-Mail:      da.box@...
  * E-Location:  www.pcppopper.org
  ***************************************************************************/

Mark Brophy wrote:
>
> I'm currently using vim6.0v under win2k.
> When sections within the text are folded, scrolling past text
> with the keyboard works as expected, but when using a wheel mouse,
> or the scrollbar the folds are treated as their internal
> height, and scrolling past them takes a lot longer.
>
> eg. If I'm scanning through the code of a function, and there's
> a large function above it that's been folded (but is still
> on the display), scrolling the mouse wheel down doesn't move
> the text until it's scrolled through the folded text.
>
> Is this a bug, or is it intended?
>
>         Mark Brophy.

      I think this bug was already reported.  Try vim 6.0w.

					 --Benji Fisher

at the usual spot:
	 http://www.mossbayeng.com/~ron/vim/alpha.html

I found a small ;-) problem in workshop.c


*** ../vim60w/src/workshop.c Thu Feb 22 06:21:12 2001
--- src/workshop.c Wed Feb 28 09:23:22 2001
***************
*** 630,641 ****
  	 XmStringExtent(fontList, str, &w, &h);
  	 XmStringFree(str);
  	 XmFontListFree(fontList);
- #if 0
  	 /* documentation says XmFontListEntryFree() doesn't free the
  	  * XFontStruct, but gvim crashes if the following call is made.
  	  */
!  XmFontListEntryFree(fle);
! #endif
       }
       if (h)
       {
--- 630,644 ----
  	 XmStringExtent(fontList, str, &w, &h);
  	 XmStringFree(str);
  	 XmFontListFree(fontList);
  	 /* documentation says XmFontListEntryFree() doesn't free the
  	  * XFontStruct, but gvim crashes if the following call is made.
  	  */
!  XmFontListEntryFree(&fle);
!  /* OOPS! You are supposed to pass in the ADDRESS of fle!
! 	 *
! 	 * Note: These are Motif 1.2 and later functions/contructs.
! 	 * (David Harrison)
! 	 */
       }
       if (h)
       {

Mark Brophy wrote:

> I'm currently using vim6.0v under win2k.
> When sections within the text are folded, scrolling past text
> with the keyboard works as expected, but when using a wheel mouse,
> or the scrollbar the folds are treated as their internal
> height, and scrolling past them takes a lot longer.
>
> eg. If I'm scanning through the code of a function, and there's
> a large function above it that's been folded (but is still
> on the display), scrolling the mouse wheel down doesn't move
> the text until it's scrolled through the folded text.
>
> Is this a bug, or is it intended?

The scroll wheel should scroll closed folds as if they were one line.  I'll
look into that.

Dragging the scrollbar is working as it is.  Recomputing the number of
screenlines each time a fold is opened or closed would take too much time.

--
hundred-and-one symptoms of being an internet addict:
21. Your dog has its own home page.

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

Greetings, Bram

On Tue, Feb 27, 2001 at 14:49:25, Bram Moolenaar wrote:
BM> Andrew Rodionoff wrote:
[...]
>>  I've also included new option 'metaesc', aimed to make GUI Vim send
>> <esc>  before Meta-modified key, like xterm does. This one supposed to
>> solve a  problem of entering Meta-modified 8bit chars.

BM> There are a few problems with this:
BM> - An extra option.  Would be better if meta keys work the same way always.
BM> - Using <M-x> in mappings won't work when 'metaesc' is set.
     I see your point. I guess the whole meta-key recognition can be rewritten
to use <Esc> as a prefix. I know at least one editor that use similar
approach, it's John Harper's Jade.

BM> - Using an ESC causes trouble in Insert mode, it's not normally used for
BM> special keys in the GUI.
     It's a matter of setting 'esckeys' option. It can be force-set when
'metaesc' is being set.

BM>  It's not clear what problem this option is trying to solve.
     I guess I speak English like Two Conkers from Discworld Noir do :) It's
apparently a problem of i18n. When one is typing 8-bit (I mean 8th bit on)
text, he can't use Meta-combos to trigger macros. Meta-modified key and actual
keysym just appear to be the same.

--
Best regards, Andrew

He is the MELBA-BEING ... the ANGEL CAKE ... XEROX him ... XEROX him --

Greetings, Devin

On Tue, Feb 27, 2001 at 10:00:05, Devin Weaver wrote:
DW> On Tue, Feb 27, 2001 at 12:58:43AM +0300, Andrew Rodionoff wrote:
>>  I use this one with both 5.x and 6.x branches to edit my SGML docs. This
>>  syntax file is as generic as possible, with a slight bias towards TEI
>> Lite  standard. Its main feature is short tags and marked sections
>> support.

DW> Because XML and SGML are so closely brother and sister and that there
DW> can be many different DTD's for both. sgml.vim and xml.vim use a plugin
DW> like feature. Were the filetype.vim exmines the extention to the file
DW> and the <!DOCTYPE> declaritive and determines two things. the syntax to
DW> load and what mode it's in. a *.sgml file with a  <!DOCTYPE book PUBLIC
DW> "-//OASIS//DTD DocBook V4.1//EN"> would produce in the reading of
DW> docbk.vim which would take the *.sgml extention and read in sgml.vim.
     I see. I should have provided some filetype detection facilities.

DW>  In conclution is your interested in a syntax for a DTD you can easily
DW> use dokbk.vim as an example and make it compatable with both SGML and
DW> XML. However if your syntax changes are to the actuall formating of a
DW> SGML document say the </> tags and all then it goes in the current
DW> sgml.vim file. Lorance Stinson <madlinux@...> is the maintainer
DW> for that. (Is that correct Lorance?)
     Yeah, but docbk.vim is just a buch of keywords which is loaded on demand.
I think that Dr. C's approach on TeX syntax, who's 'not trying to be All
Knowing' is better. You're right though, 'cause my main goal was to support
<tag// constructions and marked sections like <![CDATA [ ]]>. Currently I have
no spare time to make patch to sgml.vim or something, but I would not mind if
someone will use the ideas from my file.

--
Best regards, Andrew

-- I love KATRINKA because she drives a PONTIAC.  We're going away
now.  I fed the cat.

Bram wrote:

> Was there a WinEnd group in Vim 5.7?  I can't find it.

Maybe it was from an even older version, but still worked for
back-compatibility only.

> Perhaps we should use NonText for the "~" lines and 'showbreak', and
> use SpecialKey for unprintable characters?

Yeah, sounds good to me.

> >     - I would have expected the vertical split bar to be in the
> >     same colour as the horizontal split bar, using the StatusLine
> >     group.  Would this be possible?  Or maybe to have its own
> >     highlight group?  I couldn't find one in the docs.
>
> There is the FillColumn group for this.

Ah, right you are!  The name didn't leap out at me when browsing the
help.  How about calling it "VertSplit" instead?

And I don't suppose it can inherit from StatusLineNC when not set?

> >     - I'd suggest the default for 'winwidth' should be 1, since it
> >     is unexpected behaviour for a window to suddely get bigger
> >     when the user hasn't requested it.  Especially noticable I
> >     guess with 'mousefocus' set.
>
> I don't expect many people to have 'mousefocus' set.  You would have
> to reduce 'winwidth' yourself if you set 'mousefocus'.   A window
> smaller than about 20 characters has the problem that the status
> line can't show much.  And with a normal 80 columns window it means
> you have split it four times, which is quite a lot.

Hmm, I guess it doesn't worry me too much, but I imagine it seeming
strange to a new user.  You might have a window one column wide just
to get it out of the way temporarily, and use ^W^W to travel between
windows, passing through the thin window on the way to the one you
want to get to.  In this case the thin window would get wider when you
don't expect it to, or want it to.

> >     - If you split vertically (^Wv), then split the window on the
> >     left horizontally (^Ws) and put the mouse over the character
> >     where the two split bars meet, you'd expect it to control the
> >     vertical bar, to slide it left or right.  Instead it controls
> >     the horizontal bar up or down, even though the character under
> >     the mouse is from the vertical bar.
>
> If you do it the other way (horizontal split first, then vertical
> split) then the character right of the status line is part of the
> status line, and should be used to resize up-down (and it does).
> Making this difference is a bit complicated.  Still, the code exists
> in win_redr_status(), thus it could be made to work correctly.

Doesn't seem like it should be too hard, since the windows must
already be in a tree structure, and I assume this is used when finding
which window the mouse was in.  Of course, this is a stupid thing to
say not having looked at the code :-)

> >     - Didn't ":tn" in a help window used to take you to the next
> >     matching help tag?  Now it always says there's only one
> >     matching tag.  Try ":h min".  Doing ^D shows lots of matches,
> >     but how do you get to them?
>
> I don't think this ever worked with ":tn".  You can do it if you are
> inside a help window:  ":ta /min".  But you don't get the clever
> translations then.

Hmm, pity (although I didn't know about ":ta /" which is great!).
Another place where this is a shame is when using K.  I was editing
my _vimrc and put the cursor on "winwidth" as in "set winwidth=1" and
hit K.  It went to help for "winwidth()" instead of "'winwidth'", and
it seems there's no easy way to move to the next best match.

> I suppose we need a character that gets you out of wildmenu mode,
> without side effects.  Then you can map cursor-left.  Hmm, doesn't
> this work: :cnoremap <Left> <Space><BS><Left>

Ha!  Yep, that works, and will do me for now :-)

> >     - The Edit menu has the usual Cut, Copy and Paste, but then it
> >     has Put Before and Put After, which use vim's yank buffer
> >     rather than the clipboard like the previous commands.  Maybe
> >     we should also have Paste Before and Paste After to avoid
> >     confusion?
>
> What does Paste normally do?  I guess it puts the text before the
> cursor (at least in Insert mode).  Perhaps we should make it
> "Paste", "Paste after", "put" and "put after"?

The difference is that the "Before" and "After" commands use "[p" and
"]p" which also indents the pasted text to line up with surrounding
text.  Don't know whether we need a whole set of all combinations, but
I would like to see Paste Before and Paste After.

Rob.

I made multibyte support about word search.
Attached patch will bring vim below multibyte features.
     1) */# under cursor word search.
     2) Word completion with i_CTRL-N/P
----
Muraoka Taro  <koron@...>

On Mon, 26 Feb 2001, Neil Bird wrote:

> Benoit Cerrina wrote:
> > Tags file not sorted: tags
> > seems to say that the file is sorted.
>
>   Yes, but *is* it? Do 'sort tags > tags.sorted' and compare the two.
>
>   You may need to use 'LC_ALL=C sort' if you have locale stuff set up
> fully, as sort will mis-equate 'A' with 'a', etc.

Ctags sets LC_ALL=c in the environment prior to calling the system
"sort" utility. If this is still not resulting in a correct sort,
we need to find the cause and solution.

--
Darren Hiebert <darren@...>
http://darren.hiebert.com

compiler is  microsoft compiler,cl  and makefile is make_mvc.mak
vipin
----- Original Message -----
From: Benji Fisher <benji@...>
To: vipin aravind <vipin.aravind@...>
Cc: VIM Mailing list <vim-dev@...>
Sent: Wednesday, February 28, 2001 8:30 PM
Subject: Re: broken build


> > vipin aravind wrote:
> >
> > Build  for win32 breaks in ex_cmds.c due to undefined VIMINFO.How do I
> > avert it?
> > vipin
>
>      We need a lot more details.  What files did you get?  What compiler
> are you using?  What command did you give to the compiler?
>
> --Benji Fisher

Hi,

My clean machine [Mandrake Linux 7.2, with the addition of 'libiconv' added],
fails compiling 6.0w:

	 make distclean
	 ./configure
	 make

The failure is that it seems to be unable to determine the size of an int (!):

configure:5704: checking size of int
configure:5723: gcc -o conftest -g -O2 -Wall  -I/usr/local/include 
-L/usr/local/lib conftest.c -lncurses -lelf  -liconv -lgpm 1>&5
configure:5715: warning: return-type defaults to `int'
configure: failed program was:
#line 5712 "configure"
#include "confdefs.h"
#include <stdio.h>
		 main()
		 {
		   FILE *f=fopen("conftestval", "w");
		   if (!f) exit(1);
		   fprintf(f, "%d\n", (int)sizeof(int));
		   exit(0);
		 }


Far be it from me to whine, but shouldn't inability to determine 'sizeof(int)'
be a FATAL error that causes all the compilation to cease?  I mean, the
current behavior of just setting it to '0' is ludicrous:
	 1) there is never an int size of zero
	 2) it makes it incredibly difficult to pinpoint the problem, since the
	    compile just 'goes on' even though there is something pretty wrong!
	 3) if we just blithely set SIZEOF_INT to something, wouldn't it make
	    somewhat more sense to choose '4' as the value, as that is what 98% of
	    the machines out there are using?

Anyway, I don't have any clue why this behaviour is occurring.  My laptop,
also running Mandrake 7.2 (albeit with *tons* of patches and additions)
compiles just fine.  Sometimes it is interesting to wipe a disk and start
over...

Ron


--
Ron Aaron                                       Moss Bay Engineering
425-649-8817                              Precision Crafted Software
http://www.mossbayeng.com/~ron/ronsresume.html

"If you won't be better tomorrow than you are today,
                     what need have you for tomorrow?"
R' Nahman of Bratslav

>
> 'path' option gives you "...a list of directories which will be searched
> when using the gf, [f, ]f, ^Wf and other commands, provided that the
> file being searched for has a relative path (not starting with '/')".
>
>  --Lyosha

well, that's a start, but I was looking for something a little more
sophisticated. When you say, in perl:

use FileHandle;

perl looks through a variable called @INC to locate the module, and then tags
'.pm' on the end of it. Hence, I'd want to be able to *program* the *f commands,
and furthermore tie them to a given suffix (.pm, .pl, etc)

Ed

(
ps -- this is also true for python and java, which do similar transforms...
doing it really right would involve being able to handle 'import package.*'
and split on multiple files.
)

(
pps -- for some reason, my posts aren't making it to the list from my other
address (edwardp@...). Could someone check to see what's going on/
if I am being accidentally dropped?

thanks much..
)

cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF    -D_DEBUG -DDEBUG /Zi
/Od -D
DYNAMIC_ICONV ex_cmds.c /Fo.\ObjCD/ex_cmds.obj /Fd.\ObjCD/
alias ls =`dir /w`
alias vi =`vim.exe`
alias trace `setdos /y1 & %$`
ex_cmds.c
ex_cmds.c(157) : warning C4013: 'atoi' undefined; assuming extern returning
int
ex_cmds.c(252) : warning C4013: 'strlen' undefined; assuming extern
returning in
t
ex_cmds.c(360) : warning C4013: 'memmove' undefined; assuming extern
returning i
nt
ex_cmds.c(646) : warning C4013: 'strcat' undefined; assuming extern
returning in
t
ex_cmds.c(698) : warning C4013: 'strcpy' undefined; assuming extern
returning in
t
ex_cmds.c(821) : warning C4013: 'strcmp' undefined; assuming extern
returning in
t
ex_cmds.c(919) : warning C4013: 'mch_remove' undefined; assuming extern
returnin
g int
ex_cmds.c(957) : warning C4013: 'can_end_termcap_mode' undefined; assuming
exter
n returning int
ex_cmds.c(1211) : warning C4013: 'strncat' undefined; assuming extern
returning
int
ex_cmds.c(1298) : warning C4013: 'vim_stat' undefined; assuming extern
returning
  int
ex_cmds.c(1526) : error C2065: 'VIMINFO_FILE' : undeclared identifier
ex_cmds.c(1759) : warning C4013: 'atol' undefined; assuming extern returning
int
ex_cmds.c(2874) : warning C4013: 'keymap_init' undefined; assuming extern
return
ing int
ex_cmds.c(4620) : warning C4013: 'strncmp' undefined; assuming extern
returning
int
ex_cmds.c(4703) : warning C4013: 'mch_isdir' undefined; assuming extern
returnin
g int
vipin
~
----- Original Message -----
From: vipin aravind <vipin.aravind@...>
To: Benji Fisher <benji@...>
Cc: VIM Mailing list <vim-dev@...>
Sent: Wednesday, February 28, 2001 9:51 PM
Subject: Re: broken build


> compiler is  microsoft compiler,cl  and makefile is make_mvc.mak
> vipin
> ----- Original Message -----
> From: Benji Fisher <benji@...>
> To: vipin aravind <vipin.aravind@...>
> Cc: VIM Mailing list <vim-dev@...>
> Sent: Wednesday, February 28, 2001 8:30 PM
> Subject: Re: broken build
>
>
> > > vipin aravind wrote:
> > >
> > > Build  for win32 breaks in ex_cmds.c due to undefined VIMINFO.How do I
> > > avert it?
> > > vipin
> >
> >      We need a lot more details.  What files did you get?  What compiler
> > are you using?  What command did you give to the compiler?
> >
> > --Benji Fisher
>
>