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

menuonly

Expand Messages
  • mzyzik@gmail.com
    All, In a previous email I mentioned the idea of a menuonly option to completeopt . I realized today some other reasons why this is important: 1. If I want
    Message 1 of 1 , Feb 26, 2006
    • 0 Attachment
      All,

      In a previous email I mentioned the idea of a "menuonly" option to
      'completeopt'. I realized today some other reasons why this is important:

      1. If I want to view the "info" of a menu item (which would contain the
      kind of information Visual Studio does when I hover over menu items), I
      need to be able to select the menu item first. If there is only one
      completion, I won't be able to view the "info" for that item.
      2. Many completion plugins seem to be popping up function prototypes in
      the menu. If I want to view them rather than complete them, and there is
      only one prototype, then the menu won't come up.
      3. The menu itself is a big new addition, IMPO, to Vim; and thus it
      should be, like the rest of vim, configurable.

      --Matt

      On Mon, Feb 20, 2006 at 12:14:15PM +0100, Bram Moolenaar wrote:
      >
      > Mat Mzyzik wrote:
      >
      > > Now that you can set completeopt=longest,menu ... Vim's completion is
      > > amazing. I feel like I'm in eclipse or something. However, there are 3
      > > things I would like to bring up:
      > >
      > > 1.
      > > In the help, it mentions that <Up> and <Down> don't insert the "newly
      > > selected word" while <PageUp> and <PageDown> do. This is really
      > > unreasonable. What are the chances that someone pressing PageDown would
      > > hit on the menu entry there were looking for?
      > > It should be like this: <Up><Down><PageUp><PageDown> don't insert the
      > > newly selected text, and <c-p><c-n><c-b><c-f> do insert the newly
      > > selected text (I only mention <c-b> and <c-f> in case the current page
      > > up/down behavior is desired).
      > > This relates to clicking also. If/when mouse clicking on the menu items
      > > is implemented, a single click could "highlight but not insert", and a
      > > double click would do what <c-j> does (select and insert the menu item).
      >
      > Right, <PageUp> and <PageDown> should work like <Up> and <Down>, only
      > jump more entries.

      What's your take on the single/double clicks on the menu?

      >
      > > 2.
      > > Another problem I've seen is in reference to case matching when
      > > typing while completions are up. If I type "satur<c-n>" it could show
      > > "SATURDAY" in the completions menu. If I start hitting backspace and
      > > typing saturday again in lower case, the completion no longer shows up
      > > in the popup. (I'm talking about the "second state" as mentioned in the
      > > help.) Clearly this is a bug. However, it leads me to think whether Vim
      > > handles what I'm talking about, when there is omni-completion. I
      > > believe the completion plugin handles the "updates" to the menu;
      > > although I'm not sure because it would be faster if Vim handled it.
      > > It's important cause some languages are case-sensitive and some
      > > aren't; and the completion plugin has to determine the behavior of the
      > > menu. However, once again, with keyword completion, it seems like it's
      > > not working correctly.
      >
      > I was still working on this. One might argue that even with a
      > case-sensitive language it's nice to do case-insensitive completion.
      > You find more matches, which helps when you don't know exactly what the
      > case is. But it might result in matches you don't want to see, esp.
      > with C. I suppose this needs to be an option.
      >
      > > 3.
      > > If I press <c-n> followed by <c-p> to get back "to the original", then I
      > > type, the menu disappears instead of functioning at that "second state".
      > > I'm not sure if this is desired. It would be nice if it worked after
      > > <c-p> because I could map "." to do "<c-x><c-o><c-p>" so that Vim
      > > wouldn't complete the longest string. This would match the behavior of
      > > other IDEs.
      >
      > It's difficult to decide what to do when typing normal characters. In
      > Vim 6 it would abort the completion. In Vim 7 we now have an extra
      > state where typing characters is used to reduce the number of matches,
      > without leaving completion mode.
      >
      > When going back to the original text and typing something, what does the
      > user intend to do? Perhaps forget about completion and type it
      > directly, or reduce the number of matches?

      If you're in "-- (insert) SELECT --" mode, and you hit ESC, Vim goes
      back to INSERT mode, rather than NORMAL mode. So I don't see why ESC
      wouldn't escape the "Completion Mode" and go to INSERT mode, instead of
      going to NORMAL mode as it does now. Just a thought.

      >
      > Perhaps the second feels more natural. But the question is when to
      > leave completion mode, one might just continue typing. You can't do
      > this when there are no matches, you might just have made a typo and hit
      > BS next to correct it.

      I'm not sure if you're referring to the "<c-x><c-o><c-p>" idea; but if
      you are, and saying that it wouldn't work, maybe you could add something
      like "menuonly" option to 'completeopt'. This option would popup the
      menu, without inserting any text, and ready for the user to type in that
      "second state".

      >
      > --
      > BEDEVERE: How do you know so much about swallows?
      > ARTHUR: Well you have to know these things when you're a king, you know.
      > "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
      >
      > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
      > /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
      > \\\ download, build and distribute -- http://www.A-A-P.org ///
      > \\\ help me help AIDS victims -- http://www.ICCF.nl ///
    Your message has been successfully submitted and would be delivered to recipients shortly.