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

11944Re: Meta and Option keys simultaneously in MacVim

Expand Messages
  • Fabien Cazenave
    Nov 10, 2010
      2010/11/10 björn <bjorn.winckler@...>:
      > On 10 November 2010 17:15, Fabien Cazenave <fabi1.cazenave@...> wrote:
      >> 2010/11/9 björn <bjorn.winckler@...>:
      >>> On 7 November 2010 16:56, Kazé <fabi1.cazenave@...> wrote:
      >>>> Hello,
      >>>> with MacVim, the "macmeta" currently allows to use both "Option" keys
      >>>> either as "Meta" or "AltGr". Like a lot of European users, I'd prefer
      >>>> the "macmeta" pref to set only one "Option" key as "Meta" (e.g. the
      >>>> left one, as it works on Windows and GNU/Linux) and keep the other one
      >>>> for special characters on non-English keyboard layouts.
      >>>> In case someone is interested if having both a Meta key *and* an
      >>>> Option key when "macmeta" is set, here's a quick and dirty patch:
      >>>>  diff --git a/src/MacVim/MMTextViewHelper.m b/src/MacVim/
      >>>> MMTextViewHelper.m
      >>>>  index 4d10432..42f311b 100644
      >>>>  --- a/src/MacVim/MMTextViewHelper.m
      >>>>  +++ b/src/MacVim/MMTextViewHelper.m
      >>>>  @@ -22,6 +22,9 @@
      >>>>  #import "MMWindowController.h"
      >>>>  #import "Miscellaneous.h"
      >>>>  +// asymetric meta keys
      >>>>  +#define NSLeftAlternateKeyMask  (0x000020 | NSAlternateKeyMask)
      >>>>  +#define NSRightAlternateKeyMask (0x000040 | NSAlternateKeyMask)
      >>>>  // The max/min drag timer interval in seconds
      >>>>  static NSTimeInterval MMDragTimerMaxInterval = 0.3;
      >>>>  @@ -165,7 +168,8 @@ KeyboardInputSourcesEqual(TISInputSourceRef
      >>>> a,TISInputSourceRef b)
      >>>>     // ASCII chars in the range after space (0x20) and before
      >>>> backspace (0x7f).
      >>>>     // Note that this implies that 'mmta' (if enabled) breaks input
      >>>> methods
      >>>>     // when the Alt key is held.
      >>>>  -    if ((flags & NSAlternateKeyMask) && [mmta boolValue] && [unmod
      >>>> length] == 1
      >>>>  +    if (((flags & NSLeftAlternateKeyMask) == NSLeftAlternateKeyMask)
      >>>>  +            && [mmta boolValue] && [unmod length] == 1
      >>>>             && [unmod characterAtIndex:0] > 0x20
      >>>>             && [unmod characterAtIndex:0] < 0x7f) {
      >>>>         ASLogDebug(@"MACMETA key, don't interpret it");
      >>>> This is just a trivial adaptation of this iTerm patch:
      >>>> http://swissarmyhammer.wordpress.com/2010/06/07/osx-terminal-meta-key-national-characters/
      >>>> I think a proper MacVim integration would require to modify the
      >>>> 'macmeta' stuff, e.g. by using a string pref instead of a boolean one:
      >>>>  * set macmeta=l     => left Option key is Meta
      >>>>  * set macmeta=r     => right Option key is Meta
      >>>>  * set macmeta=rl    => both Option keys are Meta
      >>>>  * set macmeta=      => no Meta key
      >>>> Thoughts?
      >>> Hi,
      >>> I can see that this sort of behavior would be useful for non-english
      >>> keyboard layouts.  Perhaps an easier solution (implementation-wise)
      >>> than modifying the 'macmeta' option (and one that doesn't break
      >>> backwards compatibility) would be to have a user default to set which
      >>> key is used as meta when 'macmeta' is enabled.  This way it would be
      >>> an app-level setting so all windows would use the same setting -- I
      >>> don't know if this is a disadvantage or not (perhaps it is a bit
      >>> confusing?).
      >>> Anyway, that was just a though...I don't know which solution is better
      >>> (making 'macmeta' a string option, or adding a user default).  Does
      >>> anybody else have any comments about this?
      >>> I'm not against merging such a patch...
      >>> Björn
      >> I think it won't make a big difference to the user if we keep a
      >> boolean pref for "macmeta" and add a string pref (e.g. "macmetakeys")
      >> to define which Option keys should be handled as Meta. The only
      >> problem I can see is that it could be a little confusing if "macmeta"
      >> is set to "true" but "macmetakeys" is empty -- though that could be
      >> partly avoided if "macmetakeys" is set to "l" or "rl" by default.
      > This sounds bad.  My suggestion was to have a user default, e.g.
      > MMWhichMeta with values 0=both (default), 1=left, 2=right.  This avoid
      > cluttering the core Vim source code (something I try hard to avoid)
      > and the patch would not require much source code.
      > Alternately turn 'macmeta' into a string option ("lr","l","r") but I
      > was under the impression that you'd once and for all decide which
      > option key works as meta and then set 'macmeta' on/off per buffer.  If
      > this is true then this alternative seems worse to me.

      I'm not sure I'm following you. To try to make it clear: the
      MMWhichMeta would be fine, a string option for "macmeta" would be fine

      I hadn't thought of the global/buffer scope because I'm used to set
      the Meta behavior once for all (i.e. in my ~/.Xmodmap and
      ~/.Xresources files) when I use Vim in a terminal. I don't think we
      need any per-buffer setting for these Meta keys.

      >> However, if we have two prefs for the Meta keys we might want to add a
      >> third one to define whether the Meta key sets the 8th bit (= current
      >> behavior, like on gVim and xterm) or if it sends Escape instead (=
      >> like on most modern terminal emulators like *rxvt by default):
      >>   * set nomacmetaescape  => map <M-a> :exe "myFunc()"<CR>
      >>   * set macmetaescape      => map <Esc>a :exe "myFunc()"<CR>
      >> With such a setting, Meta-* shortcuts wouldn't be easy to use in
      >> insert mode but it could be appreciated by users who want an 8-bit
      >> clean MacVim *and* an Option key *and* a Meta key (if I'm the only one
      >> in this category, please don't tell me :-/). That's what has been
      >> implemented in the final iTerm patch I mentioned in my first message.
      > You are losing me now.  All I see is "let's add LOTS more options!
      > (tm)".  The general philosophy here should be "avoid adding more
      > (Vim-) options at all cost".
      > I don't really understand the issue with setting the 8th bit or
      > sending escape, but since Vim already sets the 8th bit it seems like a
      > very bad idea to change this behavior for the Mac only.  Remember that
      > Vim is not a terminal emulator (as opposed to iTerm which you
      > mentioned in passing).

      To make it shorter: if we can have a Meta key *and* an Option key on
      MacVim, it'll be awesome -- even if Meta sets the 8th bit.

      Vim itself leaves the question of the 8th bit to the terminal emulator
      -- and nowadays, most terminal emulators rather send Escape to avoid
      conflicts with non-ASCII charsets (which is a good thing). But you're
      right, gVim *does* set the 8th bit (which is bad) and it wouldn't make
      much sense to add a "MetaSendsEscape" pref for the Mac only: I'll go
      bother the gVim team about that. ^^

      Thanks again for your efforts!

      You received this message from the "vim_mac" 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
    • Show all 11 messages in this topic