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

Re: Ctrl-^ (was Re: Vim with Thunderbird)

Expand Messages
  • Michael Henry
    ... Hi, Nico, I just tested your patch, and unfortunately it doesn t fix the problem I have with CTRL-^. If I understand the patch correctly, it hard-wires
    Message 1 of 8 , Mar 31, 2007
    • 0 Attachment
      Nicolas Weber wrote:
      > Hi,
      >
      >> It does seem to me that the OS X port of Vim is somewhat less mature
      >> than the ports for Linux and Windows. I've had some problems with
      >> unicode font rendering, keyboard support (for example, ctrl-^ doesn't
      >> work out-of-the-box), etc. But I expect the rough edges to be
      >> smoothed out over time.
      >
      > can you try if this patch [1] fixed the ctrl-6 issue for you?
      >
      > [1]: http://wiki.macvim.org/wiki/VimPatches/Ctrl6

      Hi, Nico,

      I just tested your patch, and unfortunately it doesn't fix the problem I
      have with CTRL-^. If I understand the patch correctly, it hard-wires
      CTRL-2 and CTRL-6 to their shifted equivalents (CTRL-@ and CTRL-^). I
      believe the patch does as it is intended because the patched version of
      Vim circumvents my work-around for the still-broken CTRL-^ behavior.

      According to the Vim manual, pressing CTRL-^ (that is, ctrl-shift-6)
      should switch to the previously edited file. On Linux and Windows, this
      works for me, but on my mac it doesn't work; instead, pressing CTRL-^
      (and CTRL-6, for that matter) behaves as if I'd pressed '6' without
      either shift or control. So CTRL-^j results in the cursor moving down 6
      lines instead of switching to the previous buffer and going down one line.

      My work-around for this problem is the following map in my .vimrc:

      " mac-vim 7.206 doesn't properly handle CTRL-^ (and CTRL-6) to
      " edit the previous buffer. This mapping is a work-around.
      if has("mac")
      map <c-6> :e #<CR>
      endif

      When I apply your patch, my work-around no longer fixes the problem,
      since CTRL-6 is hard-wired to CTRL-^, and CTRL-^ itself doesn't work
      properly.

      Also, when I'm not using your patch, I'm unable to map CTRL-^ to my
      work-around with either of the following:

      map <c-^> :e #<CR>
      map <c-s-6> :e #<CR>

      But when I map CTRL-6 as I've done in my .vimrc, I can use both CTRL-6
      and CTRL-^ to invoke my mapping.

      I don't really understand what's going on here, but I'm content with my
      work-around until a full solution can be implemented.

      Thanks,
      Michael Henry
      P.S. I'm using Vim 7.0.206 for these tests.
    • Benji Fisher
      ... The earlier response mentioned rough edges, which is pretty accurate. This particular rough edge comes from the fact that the binary does not fork by
      Message 2 of 8 , Apr 1 7:37 AM
      • 0 Attachment
        On Sat, Mar 31, 2007 at 11:35:43AM -0400, Alan G Isaac wrote:
        > > Alan G Isaac wrote:
        > >> Are any of you using gVim with Thunderbird?
        > >> If so, how? I've followed the usual weblinks,
        > >> but asking for ``nofork`` seems not to get me
        > >> there.
        >
        >
        >
        > On Sat, 31 Mar 2007, Michael Henry apparently wrote:
        > > I'm using the Thunderbird "External Editor" plugin[1] along with a
        > > modified script taken from macvim.org[2]. I changed one line of the
        > > "gvim" shell script[3] they provide at macvim.org and saved it as
        > > ~/bin/gvimwait (script included below). Then I just configure the
        > > External Editor plugin to use ~/bin/gvimwait.
        >
        > > [1]: http://globs.org/articles.php?lng=en&pg=2
        > > [2]: http://wiki.macvim.org/wiki/Downloads/ExtraFiles
        > > [3]: http://macvim.org/OSX/files/gvim
        >
        >
        > Thanks! I'll try this immediately.
        > But is seems oddly complex compared to doing this on other OSs.
        > Why is that?

        The earlier response mentioned "rough edges," which is pretty
        accurate. This particular rough edge comes from the fact that the
        binary does not fork by default, as it does on other OS's. (I do not
        know why.) The gvim shell script explicitly adds & to force forking to
        overcome this. See #2 on the bug list at
        http://macvim.org/OSX/index.php#Bugs

        If you do not want vim to fork, why use the gvim shell script? All
        the script does is look in "all the usual places" (/Applications and
        ~/Applications and a couple of others) to find where you have put
        Vim.app; peek at the name by which it was called ($0); set a few flags;
        and pass the rest of the command line to the binary. Unless you change
        your mind about where to put Vim.app, you may as well just tell External
        Editor where the binary is. See also #8 on the FAQ list at
        http://macvim.org/OSX/index.php#FAQ .

        HTH --Benji Fisher
      • Nicolas Weber
        Hi, ... thanks for your feedback. I just realized that I tested this patch without --enable-multibyte, so that my code wasn t used at all. Way to go.
        Message 3 of 8 , Apr 1 2:22 PM
        • 0 Attachment
          Hi,

          >>> It does seem to me that the OS X port of Vim is somewhat less
          >>> mature than the ports for Linux and Windows. I've had some
          >>> problems with unicode font rendering, keyboard support (for
          >>> example, ctrl-^ doesn't work out-of-the-box), etc. But I expect
          >>> the rough edges to be smoothed out over time.
          >> can you try if this patch [1] fixed the ctrl-6 issue for you?
          >> [1]: http://wiki.macvim.org/wiki/VimPatches/Ctrl6

          > I just tested your patch, and unfortunately it doesn't fix the
          > problem I have with CTRL-^. If I understand the patch correctly,
          > it hard-wires CTRL-2 and CTRL-6 to their shifted equivalents (CTRL-
          > @ and CTRL-^). I believe the patch does as it is intended because
          > the patched version of Vim circumvents my work-around for the still-
          > broken CTRL-^ behavior.

          thanks for your feedback. I just realized that I "tested" this patch
          without --enable-multibyte, so that my code wasn't used at all. Way
          to go.

          Anyways, I guess I know why Ctrl-^ doesn't work now (and why my patch
          is completely worthless in its current form). I'll see if I can find
          a way to fix it...

          Bye,
          Nico
        Your message has been successfully submitted and would be delivered to recipients shortly.