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

Vim with Thunderbird

Expand Messages
  • Alan G Isaac
    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. Thank you, Alan
    Message 1 of 8 , Mar 30, 2007
      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.

      Thank you,
      Alan Isaac
    • Michael Henry
      ... 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
      Message 2 of 8 , Mar 31, 2007
        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.

        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.

        The line I changed just removed the ampersand from this line:

        exec "$binary" -g $opts ${1:+"$@"} &

        Hope this helps,
        Michael Henry

        [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


        Contents of "gvimwait" script follow:

        #!/bin/sh
        #
        # This shell script passes all its arguments to the binary inside the
        Vim.app
        # application bundle. If you make links to this script as view, gvim, etc.,
        # then it will peek at the name used to call it and set options
        appropriately.
        #
        # Based on a script by Wout Mertens and suggestions from Laurent Bihanic.
        # This version is the fault of Benji Fisher, 16 May 2005.

        # First, check "All the Usual Suspects" for the location of the Vim.app
        bundle.
        # You can short-circuit this by setting the VIM_APP_DIR environment variable
        # or by un-commenting and editing the following line:
        # VIM_APP_DIR=/Applications

        if [ -z "$VIM_APP_DIR" ]
        then
        myDir="`dirname "$0"`"
        myAppDir="$myDir/../Applications"
        for i in ~/Applications ~/Applications/vim $myDir $myDir/vim $myAppDir
        $myAppDir/vim /Applications /Applications/vim /Applications/Utilities
        /Applications/Utilities/vim; do
        if [ -x "$i/Vim.app" ]; then
        VIM_APP_DIR="$i"
        break
        fi
        done
        fi
        if [ -z "$VIM_APP_DIR" ]
        then
        echo "Sorry, cannot find Vim.app. Try setting the VIM_APP_DIR
        environment variable to the directory containing Vim.app."
        exit 1
        fi
        binary="$VIM_APP_DIR/Vim.app/Contents/MacOS/Vim"

        # Next, peek at the name used to invoke this script, and set options
        # accordingly.

        name="`basename "$0"`"
        gui=
        opts=

        # GUI mode, implies forking
        case "$name" in g*|rg*) gui=true ;; esac

        # Restricted mode
        case "$name" in r*) opts="$opts -Z";; esac

        # vimdiff and view
        case "$name" in
        *vimdiff)
        opts="$opts -dO"
        ;;
        *view)
        opts="$opts -R"
        ;;
        esac

        # Last step: fire up vim.
        # GUI mode will always create a new Vim instance, because Vim can't have
        # more than one graphic window yet.
        # The program should fork by default when started in GUI mode, but it does
        # not; we work around this when this script is invoked as "gvim" or "rgview"
        # etc., but not when it is invoked as "vim -g".
        if [ "$gui" ]; then
        # Note: this isn't perfect, because any error output goes to the
        # terminal instead of the console log.
        # But if you use open instead, you will need to fully qualify the
        # path names for any filenames you specify, which is hard.
        exec "$binary" -g $opts ${1:+"$@"}
        else
        exec "$binary" $opts ${1:+"$@"}
        fi
      • Alan G Isaac
        ... Thanks! I ll try this immediately. But is seems oddly complex compared to doing this on other OSs. Why is that? Thank you, Alan Isaac
        Message 3 of 8 , Mar 31, 2007
          > 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?

          Thank you,
          Alan Isaac
        • Michael Henry
          ... 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
          Message 4 of 8 , Mar 31, 2007
            > 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?

            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.

            Michael Henry
          • Nicolas Weber
            Hi, ... can you try if this patch [1] fixed the ctrl-6 issue for you? [1]: http://wiki.macvim.org/wiki/VimPatches/Ctrl6 Thanks, Nico
            Message 5 of 8 , Mar 31, 2007
              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

              Thanks,
              Nico
            • 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 6 of 8 , Mar 31, 2007
                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 7 of 8 , Apr 1, 2007
                  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 8 of 8 , Apr 1, 2007
                    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.