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

Re: request for comment on how to implement menus

Expand Messages
  • Bram Moolenaar
    ... That sounds very good to me. ... Well, if someone wants to map he will have to remove any menu item that captures this key. I don t think this is a
    Message 1 of 6 , Jul 28, 2007
      Bjorn Winckler wrote:

      > I think I was a bit unclear in my previous post, so in order to understand
      > the problem I will say something about the menu handling in Cocoa.
      > Hopefully this will clarify the situation.
      > 1. The text on that goes on the right hand side of the menu item is handled
      > by Cocoa. You can only specify which "accelerator key" should go there
      > (specifically, you can specify a printable key, e.g. "o", and modifiers, e.g.
      > "Cmd") and Cocoa will do the drawing. Hence, it is not possible to display
      > things like ":e". (I'm just restating what Jiang said in his post here.)
      > 2. There are no "menu accelerators", where one letter of the menu item is
      > underlined and pressing Alt+'that letter' brings up a menu and then pressing
      > another letter will select a menu item in that menu. That is, you cannot
      > navigate through menus with the keyboard (correct me if I'm wrong here, but
      > I don't know of any way to do so).
      > 3. Cocoa intercepts key presses, checks if any menu item is "bound" to that
      > key combination (the Cmd key is always part of such a binding). If Cocoa
      > finds a menu item bound the key combination, it briefly highlights the menu
      > on the menu bar which contains that menu item, and calls the 'action
      > message' of that menu item. This 'feature' can be disabled by hacking a
      > little, so that key presses go straight to Vim, but this means that the menu
      > won't get highlighted (a minor disturbance, but this is the behaviour you
      > expect from an OS X application, so I would like to preserve it.)
      > Now to get back to my proposal. If there was a command like this in Vim:
      > :menukeyequiv File.Open <D-o>
      > Then, you could make all the usual bindings (i.e. the usual ones for an OS X
      > app) in a .vim file which gets sourced some time after menu.vim has been
      > sourced (thus also making it possible to internationalize key equivalents).
      > The implementation of :menukeyequiv itself would simply pass the key
      > combination (e.g. <D-o>) and the appropriate vimmenu_T* ( File.Open) to the
      > GUI, which can then set the key equivalent of the menu item. Then, if the
      > user presses <D-o>, Cocoa intercepts this event, sees that it is bound to
      > the "Open" menu item under the "File" menu and calls its action message (in
      > this case, vimMenuItemAction:, which tells Vim to execute a menu item with
      > gui_menu_cb()).

      That sounds very good to me.

      > The negative side effect of this is noticed if somebody tries to remap <D-o>
      > with :map, since :map will think that <D-o> is not already bound to
      > something. When the user then presses <D-o> it is intercepted by the GUI
      > and the <D-o> event never reaches Vim. Of course, if you make it clear (
      > e.g. in :help MacVim) what is going on, then this should not be such a big
      > problem. (The key equivalent would be forced to contain the Cmd modifier
      > because this is expected behaviour.)

      Well, if someone wants to map <D-o> he will have to remove any menu item
      that captures this key. I don't think this is a problem, people are
      aware a key may already be in use. The only problem may be that
      removing the menu can be a bit complicated. Ideally there would be a
      menu command to delete the menu associated with a specific key. But
      having the user find the menu and using the menu name itself would also
      be OK.

      > Without something like I outline above, you can of course do what the Carbon
      > port does: make all the usual (as in "OS X app usual") bindings in a .vim
      > file (<D-o>, <D-c>, etc.) with :map, but this means that the text on the
      > right hand side of all menu items will be empty, and the menu highlighting I
      > mentioned above won't work. From a OS X point of view this is quite
      > confusing, but it I guess it makes "Vim-sense".

      It also means you have to keep key mappings and menu entries in sync,
      everything is there twice.

      > Since I am trying to make Vim more OS X like I would strongly prefer the way
      > I suggested above (i.e. I want the key equiv text on the right hand side
      > _and_ the highlighting), but I will not do it if it is deemed to clash too
      > much with how Vim works.


      > I agree...this is how it could be done: I would implement a Vim command
      > called e.g. ':action' which is used like this:
      > :action vimNewWindow:
      > When executed, ':action' passes the argument (vimNewWindow:, the name of an
      > action message) to the GUI. Then it would be possible to do this:
      > :menu File.New\ Window :action vimNewWindow:
      > That seems like a good solution to me...any objections?

      Sounds good to me.

      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/ \\\
      \\\ download, build and distribute -- http://www.A-A-P.org ///
      \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

      You received this message from the "vim_mac" maillist.
      For more information, visit http://www.vim.org/maillist.php
    Your message has been successfully submitted and would be delivered to recipients shortly.