160Re: Practical development of Mac vim
- Feb 3, 2001Hi Ben,
on 31/01/01 14:58, Ben Fowler at ben@... wrote:
> It would be nice to report that Santa Claus, the famous gentlemanWelcome to the small MacVim community...
> 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.
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 KielhornAre your in VI compatible mode? The option.h from 6.0r is causing the Vi
> < 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.
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
# define DFLT_FF "unix"
# define DFLT_FFS_VIM "unix,dos"
# define DFLT_FFS_VI ""
# define DFLT_TEXTAUTO FALSE
> 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
> b) Establish a 'prefs' file (which should contain a pointer to theCurrently the runtime is found the same ways as UNIX or Windows, but I was
> runtime folder, allowing the runtime folder, or pouch, to be placed
> anywhere on the system
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'I totally agree on that one. We just need to find the perfect trick for
> and byp[ass other initialisation.
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)I still think the best is to stick with the Vim core code.
> < 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/ >.
> e) We could have a scheme for running plugins such as BBEditCould be cool, but in this concept the I think the most important is to get
> 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
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 <I emailed them a year or two ago, and it seemed to be O.K at the time. If
> 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.
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 theDidn't look at that yet, but the previous versions of explorer.vim or its
> 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.
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.
> 5. Is there anyone using MacVIm for serious work willing toI'm just using MacVim when working on MacVim ;) They don't let me use Mac at
> comment on how we are getting on?
> Please don't think I am being ungrateful, asking for more and moreNo problem, the guy who brought back MacVim somewhat in sync with the rest
> information. Effectively I would like to know what I should be doing next,
> and what you would like to see from me.
of the world should maintain his WebSite more appropriately. Shame on me,
for such bad house keeping...
- << Previous post in topic Next post in topic >>