Loading ...
Sorry, an error occurred while loading the content.
 

Little problems going from 5.7a to 6.0w.

Expand Messages
  • Robert Webb
    Hi folks, Well, I finally upgraded to vim6.0w from 5.7a. Been very busy lately and was happy enough with 5.7 so I didn t try out the new version (thought I d
    Message 1 of 6 , Feb 27, 2001
      Hi folks,

      Well, I finally upgraded to vim6.0w from 5.7a. Been very busy lately
      and was happy enough with 5.7 so I didn't try out the new version
      (thought I'd wait until it had time to get somewhat stable :-)).

      I've also not been reading vimdev too carefully, so sorry if I repeat
      anything already said. Here are some comments on the new version,
      tested on Win2000 (using gvim):

      Vertical splitting:

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

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

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

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

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

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

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

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

      - ":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.

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

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

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

      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!

      Rob.

      --

      Robert Webb <RobertW@...>,
      Senior Programmer,
      Famous3D Pty Ltd <http://www.famous3d.com>
      Phone: (613) 9826 9433 ext 222, Fax: (613) 9826 9115
    • Bram Moolenaar
      ... I can see why this happens. Patch below. ... I ll fix that. ... Was there a WinEnd group in Vim 5.7? I can t find it. Perhaps we should use NonText for
      Message 2 of 6 , Feb 28, 2001
        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 ///
      • Robert Webb
        ... Maybe it was from an even older version, but still worked for back-compatibility only. ... Yeah, sounds good to me. ... Ah, right you are! The name didn t
        Message 3 of 6 , Feb 28, 2001
          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.
        • Bram Moolenaar
          ... Well, I did a grep in the 5.7 source directory and the runtime/syntax directory and couldn t find it. Spelling? Or do you set the highlight option to
          Message 4 of 6 , Mar 1 4:19 AM
            Robert Webb 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.

            Well, I did a grep in the 5.7 source directory and the runtime/syntax
            directory and couldn't find it. Spelling? Or do you set the 'highlight'
            option to refer to this group?

            > > Perhaps we should use NonText for the "~" lines and 'showbreak', and
            > > use SpecialKey for unprintable characters?
            >
            > Yeah, sounds good to me.

            I'll make it like that then.

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

            I don't remember where that name came from. Nothing else is called "Fill".
            If nobody objects, I'll rename it to "VertSplit".

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

            That would be a new mechanism. And there always is the default setting, which
            is equal to StatusLineNC.

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

            It's also not very nice to put the cursor in a window and having to resize it
            manually to be able to read the text. This is one of those things where you
            want the automatic behavior sometimes but not always. I think the default is
            OK. If you are working with narrow vertical windows you can set 'winwidth' to
            get the behavior you want.

            > 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 :-)

            It's indeed a tree structure, thus it requires searching up in the tree to
            find out if the statusline continues to the right. This isn't easy, but since
            it was solved for redrawing the statusline, the rest shouldn't be too
            difficult.

            > 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 can understand that doing ":tn" to find other matching help tags would be
            nice. The problem is that the way it currently works doesn't keep the list of
            matching tags but selects one and jumps to that. It's not a simple change to
            make this work.

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

            I've seen programs that have a "Paste" entry and then a "Paste special"
            submenu with several ways of pasting. However, I don't know if someone using
            the menus will understand the different kinds of pasting. Would be difficult
            to make a short name to explain what it does.

            --
            hundred-and-one symptoms of being an internet addict:
            31. You code your homework in HTML and give your instructor the URL.

            /// 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 ///
          • Ron Aaron
            ... If I may suggest, something which I think is needed in the Windows version: In Windows, the system clipboard has tags specifying the type of data on it.
            Message 5 of 6 , Mar 1 9:19 AM
              >> 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.
              >
              >I've seen programs that have a "Paste" entry and then a "Paste special"
              >submenu with several ways of pasting. However, I don't know
              >if someone using
              >the menus will understand the different kinds of pasting.
              >Would be difficult
              >to make a short name to explain what it does.

              If I may suggest, something which I think is needed in the Windows version:

              In Windows, the system clipboard has tags specifying the type of data on it.
              For example, plain text, rtf, HTML...

              We should have a mechanism for dealing with this properly. For example,
              when yanking to the sys clipboard, we should put the text on both in plain
              text, and HTML if it's an HTML page. When pasting from it, and we see there
              are formats we know about, we should [optionally] ask the user what formats
              to paste. This could also be an option, e.g.:

              clipboardformats=html,text,rtf

              Perhaps then, you could have a menu item which did:

              confirm paste *

              which would give a list of formats we can paste. Otherwise, we could use
              the first format in 'clipboardformats' which exists on the clipboard [ and
              is compatible with the file type? ]

              This will let us play more nicely with other apps, for example, IE which has
              problems with non-HTML clip formats.

              Ron
            • Bram Moolenaar
              ... Hmm, this sounds quite advanced. Is there a limited list of these tags? Or could any application invent one? If this isn t much code, and a patch is made
              Message 6 of 6 , Mar 1 10:52 AM
                Ron Aaron wrote:

                > If I may suggest, something which I think is needed in the Windows version:
                >
                > In Windows, the system clipboard has tags specifying the type of data on it.
                > For example, plain text, rtf, HTML...
                >
                > We should have a mechanism for dealing with this properly. For example,
                > when yanking to the sys clipboard, we should put the text on both in plain
                > text, and HTML if it's an HTML page. When pasting from it, and we see there
                > are formats we know about, we should [optionally] ask the user what formats
                > to paste. This could also be an option, e.g.:
                >
                > clipboardformats=html,text,rtf
                >
                > Perhaps then, you could have a menu item which did:
                >
                > confirm paste *
                >
                > which would give a list of formats we can paste. Otherwise, we could use
                > the first format in 'clipboardformats' which exists on the clipboard [ and
                > is compatible with the file type? ]
                >
                > This will let us play more nicely with other apps, for example, IE which has
                > problems with non-HTML clip formats.

                Hmm, this sounds quite advanced. Is there a limited list of these tags? Or
                could any application invent one?

                If this isn't much code, and a patch is made that works well, perhaps I'll
                include it.

                --
                On the other hand, you have different fingers.
                -- Steven Wright

                /// 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 ///
              Your message has been successfully submitted and would be delivered to recipients shortly.