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

160Re: Practical development of Mac vim

Expand Messages
  • Dany St-Amant
    Feb 3, 2001
      Hi Ben,

      on 31/01/01 14:58, Ben Fowler at ben@... wrote:
      > It would be nice to report that Santa Claus, the famous gentleman
      > from Turkey brought me a copy of CodeWarrior 6
      > < URL:http://www.metrowerks.com/ > (new series), but
      > this would not be at all true; I was however able to use CW 6
      > for a few days over the Christmas break & have taken the opportunity to
      > make my own executable of Mac vim.

      Welcome to the small MacVim community...

      But you should have encountered a few compile error... I didn't got time to
      ship my deltas to Bram... anyway
      Unless Alex already did so or CW 6 libraries are
      better than CW 5

      > This was the fruit of the file, os_mac.c, that Axel Kielhorn
      > < URL:http://www-public.tu-bs.de:8080/~i0080108/macvim.html >
      > kindly sent me, though it might be worth
      > noting that the file of that name in the main distribution is virtually
      > (if not absolutely) identical
      > I am bursting to ask several questions:
      > 1. How many people actually possess the vis, vim or vigor
      > < URL:http://www.dictionary.com/cgi-bin/dict.pl?db=*&term=vim > to
      > compile either a 68k or PPC executable for themselves?
      > It may as few as 3 or 4; in which case it might be considered
      > helpful if I wrote up what I had to do create my edition. Let me stress
      > that it was a little time consuming, but quite straightforward. The only
      > problems in the main sources were that I found that in some places
      > vim uses unsigned chars for C strings where I expected plain chars,
      > exempli gratia: char *getenv(const char *name); and one of the files
      > needed an extra header for something trivial like chdir (probably fixable
      > with a minor edit to os_mac.h or vim.h).
      > 2. I am have difficulty with Mac line endings in that some files which
      > the standard executable can read, mine cannot. For this reason alone,
      > I am reluctant to post my work, as it might be confusing.

      Are your in VI compatible mode? The option.h from 6.0r is causing the Vi
      compatible mode to misbehave, at line 60 the code should look like:

      # ifdef USE_CR
      # define DFLT_FF "mac"
      # define DFLT_FFS_VIM "mac,unix,dos"
      # define DFLT_FFS_VI "mac,unix,dos"
      # define DFLT_TEXTAUTO TRUE
      # else
      # define DFLT_FF "unix"
      # define DFLT_FFS_VIM "unix,dos"
      # define DFLT_FFS_VI ""
      # define DFLT_TEXTAUTO FALSE
      # endif

      > 3. What objectives on the to do list achievable for the non expert as
      > I am? Here are some possibilities:
      > a) Fix up an MPW makefile to avoid the dependence on CodeWarrior

      Good idea

      > b) Establish a 'prefs' file (which should contain a pointer to the
      > runtime folder, allowing the runtime folder, or pouch, to be placed
      > anywhere on the system

      Currently the runtime is found the same ways as UNIX or Windows, but I was
      thinking of adding in the future the following possible location:

      -the Application Support folder (if available)
      -the Preferences folder
      -the Documents folder

      I think the MacOS port should not differ to much from the other port. So I
      don't think we should create new files to find the location of the runtime.

      > c) Double clicking on a prefs or settings file should act as 'vim -u'
      > and byp[ass other initialisation.

      I totally agree on that one. We just need to find the perfect trick for

      a) use the Stationary file attribute as a "executable" attribute
      b) user a different file type than 'TEXT'

      The option a) whould work fine as long as we only execute file ending by

      > d) I think that adopting Powerplant (proprietary)
      > < URL:http://www.metrowerks.com/desktop/mactools/powerplant/ >
      > would be a strange move,
      > but there might be some purpose in using WASTE
      > < URL:http://www.metrowerks.com/desktop/mactools/powerplant/ >.

      I still think the best is to stick with the Vim core code.

      > e) We could have a scheme for running plugins such as BBEdit
      > plugins < URL:http://www.barebones.com/support/bbedit/bbedit-plugins.html >
      > or (much more work?) MPW tools,
      > < URL:http://devworld.apple.com/tools/mpw-tools/books.html#ToolServer > but
      > perhaps also
      > useful...

      Could be cool, but in this concept the I think the most important is to get
      the interaction with the compiler to work perfectly. Vim currently have
      somewhat of a support as an external editor for CodeWarrior, but we still
      cannot use the quickfix, the make.

      I admit that to attact BBEdit user...

      > f) See whether Mindvision <
      > URL:http://www.mindvision.com/pricing/shareware.asp >
      > would let us use Installer Vise, as is the case
      > with MacPerl, <
      > URL:http://devworld.apple.com/tools/mpw-tools/books.html#ToolServer >
      > another open source cross platform project that
      > predates Linux.

      I emailed them a year or two ago, and it seemed to be O.K at the time. If
      the runtime file are to be "tossed" outside the main application folder,
      it's to be looked at more deeply. This would be also needed if Vim in its
      carbonization (see below) require some librart to be included to the

      Another point of the Mac TODO:

      g) Allow a CARBON compile. Currently the source use some non-Carbon calls,
      which are needed to support older version of MacOS. For some reason Vim seem
      unable to compile without SIOUX which is not CARBONized (even in CW 6, i

      > 4. I have copied the vim 6.0t sources into my Mac tree, and the
      > project compiles, IIRC, without a hitch; but it does not run smoothly
      > because it appears not to grok the explorer.vim plugin, but the
      > error messages (basically that a backslash was found where it was not
      > allowed does not appear to be Mac specific.

      Didn't look at that yet, but the previous versions of explorer.vim or its
      precursors were using to many shell command to even take a look at the

      On the backslash note, syntax.vim (from version 6.0r) need a tiny change at
      line 19. Strangely enough, the / to : doesn't seem required just a few line
      above... (Man, I really need to cleanuo the filename convcersion code...)

      " Load the Syntax autocommands and set the default methods for highlighting.
      if has("mac")
      runtime syntax:synload.vim
      runtime syntax/synload.vim

      > 5. Is there anyone using MacVIm for serious work willing to
      > comment on how we are getting on?

      I'm just using MacVim when working on MacVim ;) They don't let me use Mac at
      work :(

      > Please don't think I am being ungrateful, asking for more and more
      > information. Effectively I would like to know what I should be doing next,
      > and what you would like to see from me.

      No problem, the guy who brought back MacVim somewhat in sync with the rest
      of the world should maintain his WebSite more appropriately. Shame on me,
      for such bad house keeping...


    • Show all 15 messages in this topic