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

Re: Mac OS X: location for vim scripts?

Expand Messages
  • Benji Fisher
    ... [snip my half-baked ideas and the reply] ... I could not figure out how to do this. ... The main advantage of this is that it works with the default
    Message 1 of 19 , Nov 26, 2001
    • 0 Attachment
      Gregory Seidman wrote:
      >
      [snip my half-baked ideas and the reply]
      > Dany St-Amant sez:
      > [...]
      > } So the shared file should go in one of the following:
      > }
      > } 1. in the application bundled itself (../Vim.app/..)
      >
      > I like this idea. It fits well with the way applications are intended to be
      > packaged on OS X. I like it second-best, though. If this were the decision,
      > I would move it elsewhere (/usr/local/share, in fact) and leave a symbolic
      > link in its place.

      I could not figure out how to do this.

      > } 2. the folder containing the application (current behavior)
      >
      > Sure, it works, but I don't like my /Applications directory to be littered
      > with non-applications. The point of having a single repository of
      > applications is for quick access to them, and the more irrelevant items
      > that get thrown in there, the slower the access to the relevant apps.

      The main advantage of this is that it works with the default behavior of
      setting $VIM. If I put Vim.app inside /Applications/vim then $VIM gets set to
      /Applications/vim and I can put a system vimrc in there.

      A possible advantage is that we could put a few more apps in the vim/
      folder: eVim.app, View.app . There is something similar in the Windows
      self-extracting binary distribution. I am not saying that I have figured out
      how to do this...

      > } 3. in the shared user home (/Users/Shared/)
      >
      > Yuck. It's not really something shared by the users, but something that
      > supports the app.

      No argument there.

      > } 4. in /Library/Application\ Support/
      >
      > A reasonable place for someone to go looking for it, but not an ideal place
      > to keep it. There should definitely be a symbolic link to the real
      > location, though.

      Symbolic links are OK with me.

      > } 5. in /usr/local/share/vim
      >
      > Yes! Put it where it would be on any other Unix.
      >
      > } I need to scan Apple web's site about the use of /Library/Application
      > } Support, but I would use that one if possible as the first choice.
      > } There's probably a need to support also option 1 or 2 (for old-times
      > } MacOS users) and option 5 (for Unix gurus, XDarwin users)
      >
      > As I said, /Library/Application Support is a good place to expect it to be,
      > but not a good place to actually put it. I fully intend to use vim on my OS
      > X box as a .app, as an X11 app, and as a shell app. The Carbon (or,
      > eventually, Cocoa) version is nothing more than a GUI frontend for the same
      > editor I use with other frontends in other environments.
      >
      > OS X is Unix, and we should stay as close to the Unix way of doing things
      > as possible. Symbolic links are an appropriate nod to the Mac way of doing
      > things, but there is no need for anything more.
      >
      > } Dany
      > --Greg

      I think Dany is already working on having a single binary with three
      different front ends. In the mean time, I should start packaging more than
      one binary. If someone installs the terminal vim 6.1 and is still using
      Carbon vim 6.0 then things will get ugly: they will not want to use the same
      runtime files for the two versions!

      I hope to build a new binary of the carbon version some time this week.
      I will probably stick with Option 2 ($VIM = /Applications/vim/) because I know
      how to make it work. Maybe by the next release I'll know how to implement
      some combination of 1, 4, and 5 with symbolic links.

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