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

Re: Mac OSX Issues

Expand Messages
  • Benji Fisher
    ... I do not think I will change the defaults, but maybe I can update the FAQ, now that I understand it a bit better. ... I would not be that hard ... ...
    Message 1 of 12 , Mar 21, 2003
      Erik Westra wrote:
      > Hi Benji,
      >> What happens if you use Vim.app to edit a file that already has
      >> the creator code from some other program? Not only what happens, but
      >> what do you want/expect to happen? (I do not use any old-style Mac
      >> programs, so this is pretty much terra incognita for me.)
      > Okay, I did some playing around, and here's what happens. If you set
      > 'backupcopy=yes' and then edit a file created by some other application,
      > that other application stays as the creator for that file, even though
      > it was edited and saved within Vim. If 'backupcopy' is not set
      > beforehand (or set to 'no'), editing a file created by another app and
      > saving it causes Vim to become the file's creator, so that
      > double-clicking on the document will open Vim instead of the other app.

      I do not think I will change the defaults, but maybe I can update the FAQ,
      now that I understand it a bit better.

      > Personally, I prefer the second option -- it makes it easier to switch
      > an existing file to open again in Vim. If you wanted to be absolutely
      > "correct" as far as the Mac's user interface standards go, then I guess
      > you'd have to modify your gvimrc file so that the "Save..." menu command
      > behaves as if 'backupcopy' was set to 'yes', but the "Save As..."
      > command behaves as if 'backupcopy' was set to 'no'. That way, simply
      > saving a document (with "Save") wouldn't affect the file's creator
      > (because you're saving the file in place), but choosing "Save As..."
      > would set Vim as the document's creator (because you're creating a new
      > file, and Vim is the app creating that file). Even if you "Save As..."
      > and overwrite the old file, the creator should still be set.
      > As I say, that's how an "absolutely correct" app would behave, but it's
      > probably more work than it would be worth. I personally almost never
      > use the standard "Open", "Save" or "Save As" commands from the menu, and
      > even if I did I wouldn't be too fussed if the file's creator was changed
      > to Vim. Now that the creator code is correct, I really don't see much
      > value in having 'backupcopy' set at all...

      I would not be that hard ...

      >>> Yup, it'd be great to get this working on Vim right out of the box.
      >>> I don't have the developer tools installed on my OSX machine (yet),
      >>> so I can't test anything, but it seems that the makefile includes
      >>> commands to explicitly build the Info.plist command, so it should be
      >>> easy to change the "????" to "VIM!" there too. That'd make my
      >>> instructions above obsolete...any chance you could try this at some
      >>> time, Benji?
      >> Maybe tomorrow. I have one question. Andrew Trevorrow (of OzTeX
      >> fame) suggested using something other than VIM! for the Carbon
      >> version, to avoid conflicts with the other (Classic) version of vim.
      >> Is he right? I am inclined to stick with VIM! unless someone talks me
      >> out of it.
      > I'd also vote to keep the creator as "VIM!". There really isn't a
      > problem with having more than one version of an app (with the same
      > creator code) on the same hard disk. Apple's developer docs (at:
      > http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Finder/chapter_10_section_13.html)
      > give the details of how the Finder selects which application to use to
      > open a particular file. The rules are quite complicated, but the
      > following is the relevant bit for us:
      > <<<...The Finder gives preference to native applications over Classic
      > applications. It also gives preference to later versions of an
      > application and to applications with a later modification date...if
      > there is an application with the same creator type already running,
      > select that application instead.>>>
      > In other words, Mac OSX should happily handle both classic and OSX
      > versions of Vim co-existing, both with the same creator code. I
      > actually think it's important that we keep the creator code set to
      > "VIM!", so that files created with Vim stay associated with Vim even if
      > they're shifted from one machine to the other.

      Unfortunately, it does not work for me.

      1. If I change the creator code to VIM!, either by editing Info.plist and
      PkgInfo or by recompiling (and letting the Makefile fo it for me), then nothing
      I can do (re-launch Finder, log out, reboot) will convince my Mac that VIM!
      means this version of Vim. If I use

      % /Developer/Tools/SetFile -c 'VIM!' ~/temp/temp.txt

      (as suggested by Peter), then the OS starts up the Classic environment to run my
      old version of Vim. Does anyone else have a copy of Vim on his OS 9 partition?

      2. If I change the creator code to something new, like 'VimX', and use SetFile
      to give temp.txt the same creator code, then Vim starts up as expected. But
      files I create with Vim do not get a creator code, no matter what I try.

      Even if it is not working for me, I am glad that it is starting to work
      for others. If we (some of us) are getting documents associated with Vim, we
      should use Douglas Stebila's icons from http://theorem.ca/~dstebila/code/vim/ .
      I assume I should include the .icns file (or files) in
      Vim.app/Contents/Resources and modify Info.plist accordingly. Do we want to use
      both of the document icons? If so, how do we fix Info.plist to use doc.icns or
      doc-text.icns as appropriate. If not, which of the two icons should I use?

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