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

Re: $VIM and $PATH on Mac OS X

Expand Messages
  • Benji Fisher
    ... Yes, I have several complaints with Mail.app. I would install Pine or mutt, if I could figure out how to get mail sent to a Terminal-based application. I
    Message 1 of 9 , Nov 10, 2001
    • 0 Attachment
      On Friday, November 9, 2001, at 10:18 PM, Dany St-Amant wrote:

      > #$&@# of Mail.App, just did a <DELETE> by error over the DRAFT copy
      > of this reply... and I cannot find it anymore. Rewriting from scratch.

      Yes, I have several complaints with Mail.app. I would install Pine
      or mutt, if I could figure out how to get mail sent to a Terminal-based
      application. I did solve one problem: if you send a patch in the body of
      an e-mail, I can save the mail in rtf (having no other choice), open it in
      TextEdit, change it to plain text using the Format menu, and save it in a
      usable way.

      > Applications under MacOS X inherit the environment of their invoker,
      > so if you change PATH of VIM in Terminal.app and then do
      > "open Vim.app", you'll use those new PATH and VIM.

      This works, but I want to compile, package, and distribute a version
      that can be placed in the Applications/
      directory. Opening from Terminal.app is not the way to go.

      > Vim on MacOS X is defaulting $VIM to the executable path. To use
      > a hardcoded path you'll have to undefine USE_EXE_PATH
      > and maybe change the wrap the use of exe_name in os_mac.c
      > with a #ifdef USE_EXE_PATH.

      Can you be more explicit? Where is USE_EXE_PATH defined? I could
      not find it, even using grep. Since I define OS_X_UNIX, isn't os_mac.c
      skipped? I really think that hard-coding $VIM is the best alternative, if
      Vim.app is going to go in the Applications/ directory (I mean folder).

      > By grep-ping and find-ing around as a root, I finally figure out
      > how to define change the environment that any Application
      > will use when launch from anywhere.
      >
      > In your home directory, create a directory .MacOSX and create
      > an environment.plist file. I just minimally tested this with a dummy
      > user id. When changing PATH you have to be careful has it will be used
      > as is, so you have to add you own bin directory $HOME/bin.
      >
      > <?xml version="1.0" encoding="UTF-8"?>
      > <!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.
      > dtd">
      > <plist version="0.9">
      > <dict>
      > <key>VIM</key>
      > <string>/Users/dstamant/</string>
      > <key>PATH</key>
      > <string>/usr/X11R6/bin</string>
      > </dict>
      > </plist>
      >
      OK, this works. I still prefer a hard-coded value for $VIM. Once I
      have $VIM set, I can install a system vimrc file: I tried

      echo system("source /private/etc/csh.login; printenv PATH")

      and got the right answer, so I can set $PATH from within vim. (BTW, this
      line shows that the @* register is working!)

      I am beginning to think that ProjectBuilder ignores the makefiles.
      Is that right? Either way, what is the recommended way to enable/disable
      features? I guess I can either edit feature.h or define macros (-DSTUFF)
      in ProjectBuilder. Is there a way to compile with +perl?

      --Benji Fisher
    • Dany St-Amant
      ... Doh!. I should have type USE_EXE_NAME and gui_mac.c. The check #ifdef is already there. If Vim is place inside a folder inside the Application folder, the
      Message 2 of 9 , Nov 12, 2001
      • 0 Attachment
        Le Dimanche 11 novembre 2001, à 12:30 , Benji Fisher a écrit :

        > On Friday, November 9, 2001, at 10:18 PM, Dany St-Amant wrote:
        >
        >> Applications under MacOS X inherit the environment of their invoker,
        >> so if you change PATH of VIM in Terminal.app and then do
        >> "open Vim.app", you'll use those new PATH and VIM.
        >
        > This works, but I want to compile, package, and distribute a
        > version that can be placed in the Applications/
        > directory. Opening from Terminal.app is not the way to go.
        >
        >> Vim on MacOS X is defaulting $VIM to the executable path. To use
        >> a hardcoded path you'll have to undefine USE_EXE_PATH
        >> and maybe change the wrap the use of exe_name in os_mac.c
        >> with a #ifdef USE_EXE_PATH.
        >
        > Can you be more explicit? Where is USE_EXE_PATH defined? I could
        > not find it, even using grep. Since I define OS_X_UNIX, isn't os_mac.c
        > skipped? I really think that hard-coding $VIM is the best alternative,
        > if Vim.app is going to go in the Applications/ directory (I mean
        > folder).

        Doh!. I should have type USE_EXE_NAME and gui_mac.c. The check #ifdef is
        already there. If Vim is place inside a folder inside the Application
        folder, the
        current auto-detect should, but won't be nice. In misc1.c, function
        'expand_env'
        we could try to avoid the removal of VIm.app by not calling (unless
        build is
        present)

        pend = remove_tail_with_ext(p, pend, (char_u *)".app");

        Or we could add back the Vim.app (should use the original name removed)
        in the
        function vim_version_dir. This could allow us to put the $VIMRUNTIME
        inside
        VIm.app (which I think is the way recommended by Apple, one big fat
        application
        folder)

        > [...]
        > I am beginning to think that ProjectBuilder ignores the
        > makefiles. Is that right? Either way, what is the recommended way to
        > enable/disable features? I guess I can either edit feature.h or define
        > macros (-DSTUFF) in ProjectBuilder. Is there a way to compile with
        > +perl?

        The os_mac.pbproj is by itself a makefile. Since there's a empty
        auto/config.h supplied
        in the distribution it should not be hard to try to get Project Builder
        to use it as a template.
        But it will require a lot of #ifdef in os_mac.h and gui_mac.h (I didn't
        got ride of os_mac.h for -DMACOS_X.. Another problem (as shown by
        os_macosx.c) is that I haven't yet found
        a way to conditionally compile a file without the use of a wrapper.

        Dany, currently looking at:
        -providing a Console/Carbon combo (works somehow but strangely)
        -how easy to get a Cocoa version (seems easier that I originally though,
        but no time)
        -how to get ./configure to go Carbon (I'm having headaches)
        -fixing small issues
        -can't remember what else
      Your message has been successfully submitted and would be delivered to recipients shortly.