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

Carbon binary with drag & drop

Expand Messages
  • Benji Fisher
    I just uploaded a binary of the Carbon version of vim. Drag-and-drop now works, and I included some of the icons that Douglas Stebila made for us, but they do
    Message 1 of 16 , Dec 6, 2001
      I just uploaded a binary of the Carbon version of vim.
      Drag-and-drop now works, and I included some of the icons that Douglas
      Stebila made for us, but they do not seem to get used. If anyone can
      figure out what I did wrong, please let me know.

      The last time I uploaded a binary, without changing the name of the
      dmg.gz file, the new version could be downloaded from my idisk but the
      old version seemed to be stuck on the home page that supposedly mirrors
      the Public folder on my idisk. If you downloaded via http, you got the
      old binary, without the latest patch from Dany St-Amant. Among other
      things, 'runtimepath' was not set properly...

      Slight change: I enabled the modified menus in the system gvimrc
      file, to encourage you to test them. Standard Mac keyboard shortcuts
      should be defined. Let me know whether you think this should be enabled
      by default in future releases.

      Beware: Cmd-S (Save As...) does not seem to work, because there
      are problems with :browse . Dany: Is this the problem you referred to
      as "Dialog boxes
      (currently in progress)" that nobody paid much attention to? I will not
      post a binary to a wider audience until this gets fixed.

      I tested it by downloading via http, so you should be able to get
      the same version either by http from
      http://homepage.mac.com/fisherbb
      or by connecting to my idisk (user name fisherbb). As always, feedback
      is welcome!

      --Benji Fisher
    • raindog@mediaone.net
      ... They didn t, and here s a patch that enables the display (right-justified, with clover symbol) of command-key equivalents in Vim menus. It does this by
      Message 2 of 16 , Dec 9, 2001
        On Tuesday, November 27, 2001, at 02:37 PM, Benji Fisher wrote:

        > Now that I can map <D-x> again, I will borrow the mac.vim file that
        > Axel Kielhorn distributed. It enables several of the standard Mac
        > keyboard shortcuts.
        >
        > BTW, I see keyboard shortcuts right-justified in several menus.
        > (For example, the Mail and File menus of Mail.app list a few
        > shortcuts.) The Apple developers didn't manually insert the right
        > number of spaces, did they?

        They didn't, and here's a patch that enables the display
        (right-justified,
        with clover symbol) of command-key equivalents in Vim menus. It does
        this
        by looking for a command-key-like keycode in the accelerator text of a
        menu item. Examples include "<D-t>", "<D-C-8>", "<C-p>", and "<S-]>";
        these could be set with :amenu commands along the lines of the following:

        :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
        :amenu MyMenu.MyCmd<Tab><D-C-8> <D-C-8>
        :amenu MyMenu.MyCmd<Tab><C-p> :ls<CR>
        :amenu MyMenu.MyCmd<Tab><S-]> :qa<CR>

        A few remarks:

        o Keycodes of the form "<D-S-x>" are supported, but Vim doesn't seem to
        recognize them (but this was true even before the patch). For example,
        if I type

        :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
        :map <D-t> :ls<CR>

        I can then hit Cmd-T to run :ls. But if I type

        :amenu MyMenu.MyCmd<Tab><D-S-t> <D-S-t>
        :map <D-S-t> :ls<CR>

        then hitting Cmd-Shift-T has no effect. Am I doing something wrong?

        o For the same reason, the Alt modifier is not supported. I thought
        the Option key was supposed to map to Alt, but I can't get Vim to
        recognize it.

        o No distinction is made between Ctrl + uppercase letter and Ctrl +
        lowercase letter. That is, "<C-x>", "<C-X>", and "<C-S-x>" are
        identical for the purposes of command key equivalents. (See the
        comments in the code for the explanation.) This could be corrected
        with a little bit of effort.

        o The code for validating the accelerator text could be more robust.
        I can't guarantee that it will correctly reject Unicode characters
        and the like.

        o I don't have a non-Carbon system on which to test this code for
        backward compatibility. Assuming this is even an issue, the only
        potential trouble spot is the call to SetMenuItemModifiers(), which
        was introduced with the Appearance Manager somewhere around OS 8.0.
        If this is a problem, it can be easily resolved at the cost of reduced
        functionality for non-Carbon systems (only keycodes of the form
        "<D-x>" would be allowed).


        -------------------- cut here --------------------

        *** gui_mac.c_ORIG Mon Aug 27 08:23:35 2001
        --- gui_mac.c Sat Dec 8 19:01:11 2001
        ***************
        *** 3748,3753 ****
        --- 3748,3754 ----
        #endif
        }

        +
        /*
        * Add a menu item to a menu
        */
        ***************
        *** 3758,3763 ****
        --- 3759,3765 ----
        {
        char_u *name;
        vimmenu_T *parent = menu->parent;
        + int menu_inserted;

        /* Cannot add item, if the menu have not been created */
        if (parent->submenu_id == 0)
        ***************
        *** 3779,3788 ****
        idx += gui.MacOSHelpItems;
        #endif

        /* Call InsertMenuItem followed by SetMenuItemText
        * to avoid special character recognition by InsertMenuItem
        */
        ! InsertMenuItem(parent->submenu_handle, "\p ", idx); /* afterItem */
        SetMenuItemText(parent->submenu_handle, idx+1, name);

        #if 0
        --- 3781,3870 ----
        idx += gui.MacOSHelpItems;
        #endif

        + menu_inserted = 0;
        + if (menu->actext)
        + {
        + /* If the accelerator text for the menu item looks like it describes
        + * a command key (e.g., "<D-S-t>" or "<C-7>"), display it as the
        + * item's command equivalent.
        + */
        + int key = 0;
        + int modifiers = 0;
        + char_u *p_actext;
        +
        + p_actext = menu->actext;
        + key = find_special_key(&p_actext, &modifiers, /*keycode=*/0);
        +
        + if (*p_actext != 0)
        + key = 0; /* error: trailing text */
        +
        + /* find_special_key() returns a keycode with as many of the
        + * specified modifiers as appropriate already applied (e.g., for
        + * "<D-C-x>" it returns Ctrl-X as the keycode and MOD_MASK_CMD
        + * as the only modifier). Since we want to display all of the
        + * modifiers, we need to convert the keycode back to a printable
        + * character plus modifiers.
        + * TODO: Write an alternative find_special_key() that doesn't
        + * apply modifiers.
        + */
        + if (key > 0 && key < 32)
        + {
        + /* Convert a control key to an uppercase letter. Note that
        + * by this point it is no longer possible to distinguish
        + * between, e.g., Ctrl-S and Ctrl-Shift-S.
        + */
        + modifiers |= MOD_MASK_CTRL;
        + key += '@';
        + }
        + /* If the keycode is an uppercase letter, set the Shift modifier.
        + * If it is a lowercase letter, don't set the modifier, but convert
        + * the letter to uppercase for display in the menu.
        + */
        + else if (key >= 'A' && key <= 'Z')
        + modifiers |= MOD_MASK_SHIFT;
        + else if (key >= 'a' && key <= 'z')
        + key += 'A' - 'a';
        +
        + /* Note: keycodes below 0x22 are reserved by Apple. */
        + if (key >= 0x22 && vim_isprintc_strict(key))
        + {
        + int valid = 1;
        + char_u mac_mods = kMenuNoModifiers;
        +
        + /* Convert Vim modifier codes to Menu Manager equivalents. */
        + if (modifiers & MOD_MASK_SHIFT)
        + mac_mods |= kMenuShiftModifier;
        + if (modifiers & MOD_MASK_CTRL)
        + mac_mods |= kMenuControlModifier;
        + if (!(modifiers & MOD_MASK_CMD))
        + mac_mods |= kMenuNoCommandModifier;
        + if (modifiers & MOD_MASK_ALT || modifiers & MOD_MASK_MULTI_CLICK)
        + valid = 0; /* TODO: will Alt someday map to Option? */
        +
        + if (valid)
        + {
        + char_u item_txt[10];
        +
        + /* Insert the menu item after idx, with its command key. */
        + item_txt[0] = 3; item_txt[1] = ' '; item_txt[2] = '/';
        + item_txt[3] = key;
        + InsertMenuItem(parent->submenu_handle, item_txt, idx);
        +
        + /* Set the modifier keys. */
        + SetMenuItemModifiers(parent->submenu_handle, idx+1, mac_mods);
        +
        + menu_inserted = 1;
        + }
        + }
        + }
        +
        /* Call InsertMenuItem followed by SetMenuItemText
        * to avoid special character recognition by InsertMenuItem
        */
        ! if (!menu_inserted)
        ! InsertMenuItem(parent->submenu_handle, "\p ", idx); /* afterItem */
        !
        ! /* Set the menu item name. */
        SetMenuItemText(parent->submenu_handle, idx+1, name);

        #if 0
      • Benji Fisher
        ... Is this a problem with :menu or :map? I tried ... and then Cmd-t echos foo and Cmd-T echos Foo as expected. (I suppose you would write Cmd-T and
        Message 3 of 16 , Dec 10, 2001
          On Sunday, December 9, 2001, at 04:44 PM, raindog@... wrote:

          > On Tuesday, November 27, 2001, at 02:37 PM, Benji Fisher wrote:
          >
          > > Now that I can map <D-x> again, I will borrow the mac.vim file that
          > > Axel Kielhorn distributed. It enables several of the standard Mac
          > > keyboard shortcuts.
          > >
          > > BTW, I see keyboard shortcuts right-justified in several menus.
          > > (For example, the Mail and File menus of Mail.app list a few
          > > shortcuts.) The Apple developers didn't manually insert the right
          > > number of spaces, did they?
          >
          > They didn't, and here's a patch that enables the display
          > (right-justified,
          > with clover symbol) of command-key equivalents in Vim menus. It does
          > this
          > by looking for a command-key-like keycode in the accelerator text of a
          > menu item. Examples include "<D-t>", "<D-C-8>", "<C-p>", and "<S-]>";
          > these could be set with :amenu commands along the lines of the
          > following:
          >
          > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
          > :amenu MyMenu.MyCmd<Tab><D-C-8> <D-C-8>
          > :amenu MyMenu.MyCmd<Tab><C-p> :ls<CR>
          > :amenu MyMenu.MyCmd<Tab><S-]> :qa<CR>
          >
          > A few remarks:
          >
          > o Keycodes of the form "<D-S-x>" are supported, but Vim doesn't seem to
          > recognize them (but this was true even before the patch). For
          > example,
          > if I type
          >
          > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
          > :map <D-t> :ls<CR>
          >
          > I can then hit Cmd-T to run :ls. But if I type
          >
          > :amenu MyMenu.MyCmd<Tab><D-S-t> <D-S-t>
          > :map <D-S-t> :ls<CR>
          >
          > then hitting Cmd-Shift-T has no effect. Am I doing something wrong?

          Is this a problem with :menu or :map? I tried

          :map <D-t> :echo "foo"<CR>
          :map <D-S-t> :echo "Foo"<CR>

          and then Cmd-t echos "foo" and Cmd-T echos "Foo" as expected. (I
          suppose you would write Cmd-T and Cmd-S-T.) OTOH, neither <D-T> nor
          <D-S-T> has the same effect.

          > o For the same reason, the Alt modifier is not supported. I thought
          > the Option key was supposed to map to Alt, but I can't get Vim to
          > recognize it.

          I cannot help here, but it would be nice to have some sane behavior
          from the Alt key.

          > o No distinction is made between Ctrl + uppercase letter and Ctrl +
          > lowercase letter. That is, "<C-x>", "<C-X>", and "<C-S-x>" are
          > identical for the purposes of command key equivalents. (See the
          > comments in the code for the explanation.) This could be corrected
          > with a little bit of effort.

          I thought <C-x> and <C-X> were supposed to be different names for
          the same ASCII code. I guess you are saying that this need not be true
          of <D-C-x> and <D-C-X>. I am happy to leave it the way it is.

          > o The code for validating the accelerator text could be more robust.
          > I can't guarantee that it will correctly reject Unicode characters
          > and the like.

          I had a quick look at the patch. (The first hunk looks as though
          it is not entirely necessary.) The line

          + key += '@';

          looks a little suspicious...

          > o I don't have a non-Carbon system on which to test this code for
          > backward compatibility. Assuming this is even an issue, the only
          > potential trouble spot is the call to SetMenuItemModifiers(), which
          > was introduced with the Appearance Manager somewhere around OS 8.0.
          > If this is a problem, it can be easily resolved at the cost of reduced
          > functionality for non-Carbon systems (only keycodes of the form
          > "<D-x>" would be allowed).
          >
          >
          > -------------------- cut here --------------------
          > [patch snipped]

          Thanks, I will try this out some time this week. I am glad that
          someone else can help Dany with the Mac port! Is there any chance of
          getting :browse fixed in the near future?

          --Benji Fisher
        • Dany St-Amant
          ... I got a fix which seem to work, but I still need to check if the MacOS 9 port sufffer the same problem. I ll post the fix I soon as I can. Dany.
          Message 4 of 16 , Dec 10, 2001
            Le Lundi 10 décembre 2001, à 03:32 , Benji Fisher a écrit :

            > [...]
            > Thanks, I will try this out some time this week. I am glad that
            > someone else can help Dany with the Mac port! Is there any chance of
            > getting :browse fixed in the near future?

            I got a fix which seem to work, but I still need to check if the MacOS
            9 port sufffer
            the same problem. I'll post the fix I soon as I can.

            Dany.
          • Dany St-Amant
            ... There s two problem: 1. line 1993 of gui_mac.c in gui_mac_doKeyEvent prohibit the use of shift if ((theEvent- modifiers & (~(cmdKey | btnState |
            Message 5 of 16 , Dec 10, 2001
              Le Dimanche 9 décembre 2001, à 04:44 , raindog@... a écrit :

              > On Tuesday, November 27, 2001, at 02:37 PM, Benji Fisher wrote:
              >
              > [...]
              > They didn't, and here's a patch that enables the display
              > (right-justified,
              > with clover symbol) of command-key equivalents in Vim menus. It does
              > this
              > by looking for a command-key-like keycode in the accelerator text of a
              > menu item. Examples include "<D-t>", "<D-C-8>", "<C-p>", and "<S-]>";
              > these could be set with :amenu commands along the lines of the
              > following:
              >
              > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
              > :amenu MyMenu.MyCmd<Tab><D-C-8> <D-C-8>
              > :amenu MyMenu.MyCmd<Tab><C-p> :ls<CR>
              > :amenu MyMenu.MyCmd<Tab><S-]> :qa<CR>
              >
              > A few remarks:
              >
              > o Keycodes of the form "<D-S-x>" are supported, but Vim doesn't seem to
              > recognize them (but this was true even before the patch). For
              > example,
              > if I type
              >
              > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
              > :map <D-t> :ls<CR>
              >
              > I can then hit Cmd-T to run :ls. But if I type
              >
              > :amenu MyMenu.MyCmd<Tab><D-S-t> <D-S-t>
              > :map <D-S-t> :ls<CR>
              >
              > then hitting Cmd-Shift-T has no effect. Am I doing something wrong?

              There's two problem:

              1. line 1993 of gui_mac.c in gui_mac_doKeyEvent prohibit the use of shift

              if ((theEvent->modifiers & (~(cmdKey | btnState | alphaLock))) == 0)

              2. line 1995, same file, same function is not using the new shortcut

              menu = MenuKey(key_char);

              Note to self: Now I remember why the 'if' was there.

              Note: amenu MyMenu.MyCmd<Tab><D-S-t> :ls<CR> is enough.

              You can replace the code around there by:

              /* TODO: should override be allowed? Require YAO or could use
              'winaltkey' */
              if (theEvent->modifiers & cmdKey)
              /* Only accept CMD alone or with CAPLOCKS and the mouse button.
              * Why the mouse button? */
              #ifndef USE_CARBONIZED
              if ((theEvent->modifiers & (~(cmdKey | btnState | alphaLock))) == 0)
              {
              menu = MenuKey(key_char);
              #else
              menu = MenuEvent(theEvent);
              #endif
              if (HiWord(menu))
              {
              gui_mac_handle_menu(menu);
              return;
              }
              #ifndef USE_CARBONIZED
              }
              #endif

              > o For the same reason, the Alt modifier is not supported. I thought
              > the Option key was supposed to map to Alt, but I can't get Vim to
              > recognize it.

              See comment for control below.

              > o No distinction is made between Ctrl + uppercase letter and Ctrl +
              > lowercase letter. That is, "<C-x>", "<C-X>", and "<C-S-x>" are
              > identical for the purposes of command key equivalents. (See the
              > comments in the code for the explanation.) This could be corrected
              > with a little bit of effort.

              Vim key-sequence is based on ASCII. Where:
              <C-x> = TOUPPER(x)-'@'
              <M-x> = x | 0x80

              So Vim is having a few problem differentiate <C-S-x> or <C-x> as it try
              to reduce the sequence to one single ASCII character. This problem
              doesn't
              affect special keys (e.g: F1, Left) nor the any key sequence including
              the
              Command key, as I make them special all the time.

              As for the problem with the meta (option) key, it still apply when the
              command key is used (unless the control key is also used). The problem
              with the option key have two side.

              a. <M-x> is not equal to (x | 0x80)
              b. <M-x> change depending on the keyboard used.

              To fix this, the Mac port will probably need to:
              a. find the optionless key used.
              b. have either.
              b1. a early mapping conversion in gui_mac_doKeyEvent
              b2. convert to a special key all the time
              b3. figure if key is mapped, if so convert to special key.
              (I prefer option b3)

              > o The code for validating the accelerator text could be more robust.
              > I can't guarantee that it will correctly reject Unicode characters
              > and the like.
              >
              > o I don't have a non-Carbon system on which to test this code for
              > backward compatibility. Assuming this is even an issue, the only
              > potential trouble spot is the call to SetMenuItemModifiers(), which
              > was introduced with the Appearance Manager somewhere around OS 8.0.
              > If this is a problem, it can be easily resolved at the cost of reduced
              > functionality for non-Carbon systems (only keycodes of the form
              > "<D-x>" would be allowed).

              You should wrapped your change in a
              #ifdef USE_CARBONIZED
              #endif

              Final comment.

              The patch seem to be functional (beside special keys), but I don't like
              (and I'm sure Bram agree with me) the idea of having to provide two
              different menu.vim or having to many :if has() in menu.vim or having
              to redefine the same menu definition more than once. However, I do
              not see any problem in supporting this mapping mechanism. This
              should maybe some how be propagated to other ports under a
              "FEAT_AUTOMAP" feature.

              Dany

              P.S; Here's a small file I use to test the various key combo.

              " e
              imap <C-e> [control-e-overided-by-C-S-e]
              imap <M-e> [option-e-broken]
              " <S-e>
              imap <D-e> [command-e-ok]
              imap <C-M-e> [control-option-e-broken]
              imap <C-S-e> [control-shift-e-override-C-e]
              imap <C-D-e> [command-control-e-ok]
              imap <M-S-e> [option-shift-e-broken]
              imap <M-D-e> [command-option-e-broken]
              imap <S-D-e> [command-shift-e-ok]
              imap <C-M-S-e> [control-option-shift-e-broken]
              imap <C-M-D-e> [command-control-option-e-ok]
              imap <C-S-D-e> [command-control-shift-e-ok]
              imap <M-S-D-e> [command-option-shift-e-broken]
              imap <C-M-S-D-e> [command-control-option-shift-e-ok]

              " e -> e (x65)
              " C-e -> ^e (x05)
              " M-e -> ? (xAB)
              " S-e -> E (x45)
              " D-e -> e (x65)
              " C-M-e -> ^e (x05)
              " C-S-e -> ^e (x05)
              " C-D-e -> ^e (x05)
              " M-S-e -> ? (xAB)
              " M-D-e -> ? (xAB)
              " S-D-e -> e (x65)
              " C-M-S-e -> ^e (x05)
              " C-M-D-e -> ^e (x05)
              " C-S-D-e -> ^e (x05)
              " M-S-D-e -> ? (xAB)
              " C-M-S-D-e -> ? (x05)
            • Dany St-Amant
              I don t know why, but I haven t yet learned the lesson Always compile/test code before publishing it . I forgot a set of curly braces. ... { ... }
              Message 6 of 16 , Dec 10, 2001
                I don't know why, but I haven't yet learned the lesson
                "Always compile/test code before publishing it".
                I forgot a set of curly braces.

                Le Lundi 10 décembre 2001, à 10:01 , Dany St-Amant a écrit :

                > You can replace the code around there by:
                >
                > /* TODO: should override be allowed? Require YAO or could use
                > 'winaltkey' */
                > if (theEvent->modifiers & cmdKey)
                {
                > /* Only accept CMD alone or with CAPLOCKS and the mouse button.
                > * Why the mouse button? */
                > #ifndef USE_CARBONIZED
                > if ((theEvent->modifiers & (~(cmdKey | btnState | alphaLock))) == 0)
                > {
                > menu = MenuKey(key_char);
                > #else
                > menu = MenuEvent(theEvent);
                > #endif
                > if (HiWord(menu))
                > {
                > gui_mac_handle_menu(menu);
                > return;
                > }
                > #ifndef USE_CARBONIZED
                > }
                > #endif
                }
              • raindog@mediaone.net
                ... I see now the difficulty of supporting Option mappings--thanks for the explanation. Is this an issue for menu equivalents, though? Since MenuEvent() would
                Message 7 of 16 , Dec 10, 2001
                  On Monday, December 10, 2001, at 07:01 PM, Dany St-Amant wrote:

                  > As for the problem with the meta (option) key, it still apply when
                  > the command key is used (unless the control key is also used).
                  > The problem with the option key have two side.
                  >
                  > a. <M-x> is not equal to (x | 0x80)
                  > b. <M-x> change depending on the keyboard used.
                  > ...

                  I see now the difficulty of supporting Option mappings--thanks for
                  the explanation. Is this an issue for menu equivalents, though?
                  Since MenuEvent() would do the work of extracting the modifiers,
                  it should be possible to use any combination of modifiers safely.
                  Of course, registering these with the Menu Manager in the first
                  place would require parsing a string like "<M-C-x>" to get, say,
                  MOD_MASK_ALT|MOD_MASK_CTRL and the character 'x'. But that seems
                  a simpler problem than the one that find_special_key() addresses
                  already.

                  > The patch seem to be functional (beside special keys), but I don't
                  > like (and I'm sure Bram agree with me) the idea of having to provide
                  > two different menu.vim or having to many :if has() in menu.vim or
                  > having to redefine the same menu definition more than once.

                  I agree. On the other hand, some sort of dichotomy seems inevitable
                  if one wants to respect UI conventions on multiple platforms. Could
                  platform-specific settings like this be handled in the same way that
                  multiple languages (:he multilang) are?


                  P.S. I'm now pretty certain that some of my mapping problems are due
                  to my not having an up-to-date source tree. I've applied patches 1-93
                  to the 6.0 sources, and also vim60_93_mac.diff from your site. Am I
                  missing anything?
                • Benji Fisher
                  ... I tried the patch, and it seems to work fine. Thanks! The only slight worry is that patch reported an offset of 183 lines. Did you base the patch on the
                  Message 8 of 16 , Dec 11, 2001
                    On Sunday, December 9, 2001, at 04:44 PM, raindog@... wrote:

                    > On Tuesday, November 27, 2001, at 02:37 PM, Benji Fisher wrote:
                    >
                    > > Now that I can map <D-x> again, I will borrow the mac.vim file that
                    > > Axel Kielhorn distributed. It enables several of the standard Mac
                    > > keyboard shortcuts.
                    > >
                    > > BTW, I see keyboard shortcuts right-justified in several menus.
                    > > (For example, the Mail and File menus of Mail.app list a few
                    > > shortcuts.) The Apple developers didn't manually insert the right
                    > > number of spaces, did they?
                    >
                    > They didn't, and here's a patch that enables the display
                    > (right-justified,
                    > with clover symbol) of command-key equivalents in Vim menus. It does
                    > this
                    > by looking for a command-key-like keycode in the accelerator text of a
                    > menu item. Examples include "<D-t>", "<D-C-8>", "<C-p>", and "<S-]>";
                    > these could be set with :amenu commands along the lines of the
                    > following:
                    >
                    > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
                    > :amenu MyMenu.MyCmd<Tab><D-C-8> <D-C-8>
                    > :amenu MyMenu.MyCmd<Tab><C-p> :ls<CR>
                    > :amenu MyMenu.MyCmd<Tab><S-]> :qa<CR>
                    >
                    > A few remarks:
                    > [snip]

                    I tried the patch, and it seems to work fine. Thanks! The only
                    slight worry is that patch reported an offset of 183 lines. Did you
                    base the patch on the original vim 6.0 sources (I assume so) or on top
                    of Dany St-Amant's patches?

                    If anyone wants me to post the binary, give a shout. Otherwise, I
                    will wait for further improvements (such as a :browse that works).

                    --Benji Fisher
                  • raindog@mediaone.net
                    ... On top of patches 1-93 and one of Dany s patches (I didn t know there are others). Are there instructions somewhere with a list of the necessary patches?
                    Message 9 of 16 , Dec 12, 2001
                      On Tuesday, December 11, 2001, at 02:06 PM, Benji Fisher wrote:
                      >
                      > > On Sunday, December 9, 2001, at 04:44 PM, raindog@... wrote:
                      > >
                      > > here's a patch that enables the display (right-justified,
                      > > with clover symbol) of command-key equivalents in Vim menus.
                      >
                      > I tried the patch, and it seems to work fine. Thanks! The only slight
                      > worry is that patch reported an offset of 183 lines. Did you base the
                      > patch on the original vim 6.0 sources (I assume so) or on top of Dany
                      > St-Amant's patches?

                      On top of patches 1-93 and one of Dany's patches (I didn't know there
                      are others). Are there instructions somewhere with a list of the
                      necessary patches?

                      RD
                    • Benji Fisher
                      ... I am afraid we are not that organized. Pretty soon, dany should send his patch to Bram, and it will be made official. In the mean time, you just have to
                      Message 10 of 16 , Dec 12, 2001
                        raindog@... wrote:
                        >
                        > On Tuesday, December 11, 2001, at 02:06 PM, Benji Fisher wrote:
                        > >
                        > > > On Sunday, December 9, 2001, at 04:44 PM, raindog@... wrote:
                        > > >
                        > > > here's a patch that enables the display (right-justified,
                        > > > with clover symbol) of command-key equivalents in Vim menus.
                        > >
                        > > I tried the patch, and it seems to work fine. Thanks! The only slight
                        > > worry is that patch reported an offset of 183 lines. Did you base the
                        > > patch on the original vim 6.0 sources (I assume so) or on top of Dany
                        > > St-Amant's patches?
                        >
                        > On top of patches 1-93 and one of Dany's patches (I didn't know there
                        > are others). Are there instructions somewhere with a list of the
                        > necessary patches?

                        I am afraid we are not that organized. Pretty soon, dany should send his
                        patch to Bram, and it will be made official. In the mean time, you just have
                        to watch this list (or have a look at the archive). If you want, I'll send
                        you a copy of the patch off the list (or maybe Dany will send you something
                        more up-to-date).

                        --Benji Fisher
                      • Benji Fisher
                        ... I have been using this for a while but only recently noticed (after all, I am a typical vim user and rarely use the menus, even my own ;) that this only
                        Message 11 of 16 , Jan 11, 2002
                          On Sunday, December 9, 2001, at 04:44 PM, raindog@... wrote:

                          > [snip]
                          > They didn't, and here's a patch that enables the display
                          > (right-justified,
                          > with clover symbol) of command-key equivalents in Vim menus. It does
                          > this
                          > by looking for a command-key-like keycode in the accelerator text of a
                          > menu item. Examples include "<D-t>", "<D-C-8>", "<C-p>", and "<S-]>";
                          > these could be set with :amenu commands along the lines of the
                          > following:
                          >
                          > :amenu MyMenu.MyCmd<Tab><D-t> <D-t>
                          > :amenu MyMenu.MyCmd<Tab><D-C-8> <D-C-8>
                          > :amenu MyMenu.MyCmd<Tab><C-p> :ls<CR>
                          > :amenu MyMenu.MyCmd<Tab><S-]> :qa<CR>
                          >
                          > A few remarks:
                          >
                          > [snip]

                          I have been using this for a while but only recently noticed (after
                          all, I am a typical vim user and rarely use the menus, even my own ;)
                          that this only works with modified keys. Is there any way to get '\t'
                          (my keyboard shortcut for running tex) right-justified in the menu?

                          :menu TeX.run\ tex<Tab>\t \t
                          :map \t :call TeX()<CR>

                          The menu command and the key mapping both work, but I do not see '\t' in
                          the menu.

                          --Benji Fisher

                          P.S. Does anyone need any of the latest 30 patches applied to Vim.app ?
                        • raindog@mediaone.net
                          ... Not without a good deal of effort, I m afraid. Carbon menu routines support only single-key equivalents with optional modifiers. To display arbitrary
                          Message 12 of 16 , Jan 11, 2002
                            On Friday, January 11, 2002, at 11:20 AM, Benji Fisher wrote:

                            > :menu TeX.run\ tex<Tab>\t \t
                            > :map \t :call TeX()<CR>
                            >
                            > Is there any way to get '\t' (my keyboard shortcut for running
                            > tex) right-justified in the menu?

                            Not without a good deal of effort, I'm afraid. Carbon menu routines
                            support only single-key equivalents with optional modifiers. To display
                            arbitrary text, one would have to implement a custom menu (known as an
                            "MDEF")--not an easy task thanks to I18N considerations. (It's a
                            different
                            story in Cocoa, incidentally, where it looks to be a relatively
                            simple matter
                            of overriding a couple of NSMenuItemCell methods.)

                            > The menu command and the key mapping both work, but I do not see
                            > '\t' in
                            > the menu.

                            Out of curiosity, does ":menu TeX.run\ tex<Tab><D-t> :call TeX()<CR>"
                            work for you (i.e., does it allow you to type Cmd-t to run TeX)?
                            Since I applied Dany St-Amant's patch (correctly this time, I think),
                            command-key equivalents such as this don't work for me, unless at least
                            one other modifier key is involved. This one has me stumped.

                            RD
                          • Benji Fisher
                            ... That s too bad. How about a workaround, so that we can use the same menu files in Mac OS X as in other OS s? A couple of spaces between the run TeX and
                            Message 13 of 16 , Jan 12, 2002
                              raindog@... wrote:
                              >
                              > On Friday, January 11, 2002, at 11:20 AM, Benji Fisher wrote:
                              >
                              > > :menu TeX.run\ tex<Tab>\t \t
                              > > :map \t :call TeX()<CR>
                              > >
                              > > Is there any way to get '\t' (my keyboard shortcut for running
                              > > tex) right-justified in the menu?
                              >
                              > Not without a good deal of effort, I'm afraid. Carbon menu routines
                              > support only single-key equivalents with optional modifiers. To display
                              > arbitrary text, one would have to implement a custom menu (known as an
                              > "MDEF")--not an easy task thanks to I18N considerations. (It's a
                              > different
                              > story in Cocoa, incidentally, where it looks to be a relatively
                              > simple matter
                              > of overriding a couple of NSMenuItemCell methods.)

                              That's too bad. How about a workaround, so that we can use the same menu
                              files in Mac OS X as in other OS's? A couple of spaces between the "run TeX"
                              and the "\t" would be good enough. A little extra work might get some
                              approximation to right-justified.

                              > > The menu command and the key mapping both work, but I do not see
                              > > '\t' in
                              > > the menu.
                              >
                              > Out of curiosity, does ":menu TeX.run\ tex<Tab><D-t> :call TeX()<CR>"
                              > work for you (i.e., does it allow you to type Cmd-t to run TeX)?
                              > Since I applied Dany St-Amant's patch (correctly this time, I think),
                              > command-key equivalents such as this don't work for me, unless at least
                              > one other modifier key is involved. This one has me stumped.

                              I cannot test it right now, but I think that <D-s> and <D-S> (or maybe
                              <D-S-s>) are working properly for File.Save and File.Save\ As. The latter
                              brings up a browser window, which still does not work. :-( Maybe someone else
                              is using the binary I posted, with the Mac-customized File menu, and can test
                              it now.

                              --Benji Fisher
                            • Benji Fisher
                              ... I think I see the problem now. Adding to the :menu command does not do anything besides add (right justified) text to the menu item. You
                              Message 14 of 16 , Jan 14, 2002
                                On Saturday, January 12, 2002, at 12:19 PM, Benji Fisher wrote:

                                > raindog@... wrote:
                                >>
                                >> On Friday, January 11, 2002, at 11:20 AM, Benji Fisher wrote:
                                >>> [snip]
                                >> Out of curiosity, does ":menu TeX.run\ tex<Tab><D-t> :call TeX()<CR>"
                                >> work for you (i.e., does it allow you to type Cmd-t to run TeX)?
                                >> Since I applied Dany St-Amant's patch (correctly this time, I think),
                                >> command-key equivalents such as this don't work for me, unless at least
                                >> one other modifier key is involved. This one has me stumped.

                                I think I see the problem now. Adding "<Tab><D-t>" to the :menu
                                command does not do anything besides add (right justified) text to the
                                menu item. You need a :map command as well. From my gvimrc file:

                                aunmenu &File.&New
                                amenu 10.325 &File.&New<Tab><D-n> <D-n>
                                nmap <D-n> :confirm enew<CR>

                                and there are also :[vico]map lines. I just tested it: Cmd-n seems to
                                work. (I think I tested all of the menu commands when I wrote the
                                gvimrc file a couple of months ago.)

                                I think the binary on my i-disk did not include the patch for
                                showing menu equivalents. I have just posted a version that includes
                                this patch, along with the official ones through 131.

                                --Benji Fisher
                              • raindog@mediaone.net
                                ... It s supposed to do more, actually: gui_mac_doKeyEvent() dispatches each keystroke to the Menu Manager, which responds with the ID of a menu if the key is
                                Message 15 of 16 , Jan 14, 2002
                                  On Saturday, January 12, 2002, at 12:19 PM, Benji Fisher wrote:
                                  >
                                  > raindog@... wrote:
                                  >>
                                  >> Out of curiosity, does ":menu TeX.run\ tex<Tab><D-t> :call TeX()<CR>"
                                  >> work for you (i.e., does it allow you to type Cmd-t to run TeX)?
                                  >> Since I applied Dany St-Amant's patch (correctly this time, I think),
                                  >> command-key equivalents such as this don't work for me, unless at
                                  >> least
                                  >> one other modifier key is involved. This one has me stumped.
                                  >
                                  > I think I see the problem now. Adding "<Tab><D-t>" to the
                                  > :menu command does not do anything besides add (right justified)
                                  > text to the menu item. You need a :map command as well.

                                  It's supposed to do more, actually: gui_mac_doKeyEvent() dispatches each
                                  keystroke to the Menu Manager, which responds with the ID of a menu
                                  if the
                                  key is a registered equivalent for one of that menu's items. In
                                  that case,
                                  the command associated with the item is executed.

                                  This works in some cases:

                                  :menu File.Test<Tab><D-S-t> :echo "Test"<CR>

                                  causes Cmd-Shift-t to print "Test", but

                                  :menu File.Test<Tab><D-t> :echo "Test"<CR>

                                  doesn't have the same effect for Cmd-t.

                                  RD
                                • Benji Fisher
                                  ... I would rather not have the menu code define key mappings. Vim scripts written for use on OS X should work the same on other OS s, and vice versa. Of
                                  Message 16 of 16 , Jan 15, 2002
                                    raindog@... wrote:
                                    >
                                    > On Saturday, January 12, 2002, at 12:19 PM, Benji Fisher wrote:
                                    > >
                                    > > raindog@... wrote:
                                    > >>
                                    > >> Out of curiosity, does ":menu TeX.run\ tex<Tab><D-t> :call TeX()<CR>"
                                    > >> work for you (i.e., does it allow you to type Cmd-t to run TeX)?
                                    > >> Since I applied Dany St-Amant's patch (correctly this time, I think),
                                    > >> command-key equivalents such as this don't work for me, unless at
                                    > >> least
                                    > >> one other modifier key is involved. This one has me stumped.
                                    > >
                                    > > I think I see the problem now. Adding "<Tab><D-t>" to the
                                    > > :menu command does not do anything besides add (right justified)
                                    > > text to the menu item. You need a :map command as well.
                                    >
                                    > It's supposed to do more, actually: gui_mac_doKeyEvent() dispatches each
                                    > keystroke to the Menu Manager, which responds with the ID of a menu
                                    > if the
                                    > key is a registered equivalent for one of that menu's items. In
                                    > that case,
                                    > the command associated with the item is executed.
                                    >
                                    > This works in some cases:
                                    >
                                    > :menu File.Test<Tab><D-S-t> :echo "Test"<CR>
                                    >
                                    > causes Cmd-Shift-t to print "Test", but
                                    >
                                    > :menu File.Test<Tab><D-t> :echo "Test"<CR>
                                    >
                                    > doesn't have the same effect for Cmd-t.

                                    I would rather not have the menu code define key mappings. Vim scripts
                                    written for use on OS X should work the same on other OS's, and vice versa.
                                    Of course, there is the difference that <D-> is not available on other
                                    systems, but this difference is visible to the person writing the menu in the
                                    vim script.

                                    --Benji Fisher
                                  Your message has been successfully submitted and would be delivered to recipients shortly.