Mac OS X will ship on March 4th.
Are we ready for that?
Any new binaries?

Sven [Q650 68040 -> no Mac OS X]

On Fri, Mar 23, 2001 at 01:54:53AM +0100, Sven Guckes wrote:
:
: Mac OS X will ship on March 4th.
: Are we ready for that?
: Any new binaries?

Vim 5.7 compiles just fine, with the latest patches.

Or are you thinking of a Carbon version of MacVim?


--
Eugene Lee
eugene@...

>Or are you thinking of a Carbon version of MacVim?

FYI, the quick carbon port I did many months ago still works fine
under the release candidate of OS X.  There are a couple important
things to do however (aside from merging the source code back in with
CVS):

- support the quit apple event.  Then the user will be able to quit
from the application menu.

- somehow register the app with OS X to say that it can open text
files.  For some odd reason, you can't drag and drop a text file over
macvim in OS X unless its classic creator/type codes match macvim.
This is also annoying because it means that I can't tell the finder
to automatically open all my project builder text files in macvim.

- support live scrolling/window resizing (not as important as the 1st 2).


Unfortunately this will be a very buzy/stressful weekend for me and I
can't look into these issues further.  I currently work around things
in os x by either opening files manually through the open dialog or
switching between xfree68 with the unix version of vim
<http://www.darwinfo.org/devlist.php3?number=3950>.

-Ammon
--
Skidperfect Software 	 <http://www.skidperfect.com/>

On Fri, Mar 23, 2001 at 12:04:37PM -0800, Eugene Lee wrote:
> On Fri, Mar 23, 2001 at 01:54:53AM +0100, Sven Guckes wrote:
> : Are we ready for that?
> : Any new binaries?
>
> Vim 5.7 compiles just fine, with the latest patches.
>
> Or are you thinking of a Carbon version of MacVim?

Cocoa gVim would be great.

Christoph

> Mac OS X will ship on March 24th.
> Are we ready for that?
> Any new binaries?

Well, I just got a mail from Carbon Dater:-)

It told me that the MPW Version of Vim 6.0w has:

2 Functions supported with modifications
3 Functions supported but not recommended
18 Unsupported API
2 Under Evaluation (Whatever that means)

That doesn't look bad, compared to
8 / 24 / 41 / 0
for Vim 5.7 with Code Warrior.

I have added all the suggestions from Carbon Dater to gui_mac.c and will
send a diff to Bram. I hope they will be in 6.0z.

Axel

On Tue, Mar 27, 2001 at 06:13:00AM +0200, Axel Kielhorn wrote:
:
: Well, I just got a mail from Carbon Dater:-)
:
: It told me that the MPW Version of Vim 6.0w has:

[...]

: I have added all the suggestions from Carbon Dater to gui_mac.c and will
: send a diff to Bram. I hope they will be in 6.0z.

Very cool!  If I haven't mentioned it enough, thanks for all the work
you've put into this, Axel!


--
Eugene Lee
eugene@...

I have gotten this to compile, but probably not in the correct way.

First in feature.h I commented in the definition of NO_BUILTIN_TCAPS

#ifdef HAVE_TGETENT
#  define NO_BUILTIN_TCAPS
#endif


Then in config.h I manually commented  out the define of
HAVE_TERMCAP_H (I know this is auto-generated and there probably
something else I could change but I couldn't find it).  This file
does not appear to be present on Mac OSX.

/* Define if you have the <termcap.h> header file.  */
/*#define HAVE_TERMCAP_H 1*/

This seemed to compile correctly and VIM now recognizes my vt100 terminal type.


>Can you help Bill here?
>Do we have testers for Mac OS X here?  Ripley?
>
>Sven
>
>===
>From: Bill Tschumy <bill@...>
>Newsgroups: comp.editors
>Subject: Re: How to get keypad keys to work [MacOSX, vim]
>Date: Thu, 29 Mar 2001 21:44:01 -0600
>Message-ID: <01HW.B6E95D21004A388C11C99950@...>
>
>One other bit of info.  When I "make" using the stock system it dies
>trying to compile term.c because termcap.h is not found.  This file isn't
>on my MacOSX system (although I've installed  all the developer files).
>
>Here is the compile output:
>
>localhost% make
>CC="cc -Iproto -DHAVE_CONFIG_H     -O2 --traditional-cpp     "
>srcdir=. sh ./osdef.sh
>osdef0.c:8: termcap.h: No such file or directory
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      buffer.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      charset.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      digraph.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      edit.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      eval.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_cmds.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_docmd.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_getln.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      fileio.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      getchar.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      if_cscope.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      main.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      mark.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      memfile.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      memline.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      menu.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      message.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      misc1.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      misc2.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      multbyte.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      normal.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ops.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      option.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      os_unix.c
>creating pathdef.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      pathdef.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      quickfix.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      regexp.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      screen.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      search.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      syntax.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      tag.c
>cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      term.c
>term.c:32: termcap.h: No such file or directory
>make: *** [term.o] Error 1
>
>* Bill Tschumy <bill@...>:
>>  I am trying to use vim (non-gui version) on the
>>  new MacOSX operating system (finally Unix on Mac).
>>  The "Terminal" app that comes with the OS does vt100 emulation.
>>  When I start up vim I get the opening message:
>>       Terminal entry not found in terminfo
>>       vt100 not known
>>         <lists 4 terminal options>
>>       defaulting to 'ansi'
>>  I assume my arrow keys and other keypad keys are not working
>>  (generally just beeps) because it doesn't know about vt100.
>>  What do I need to do to get this working?
>
>* Sven Guckes:
>>  Install vim with "+builtin_terms"?  Please try.
>
>--
>Bill Tschumy
>Otherwise -- Austin, TX
>bill@...

--
Bill Tschumy
Otherwise -- Austin, TX
bill@...

Can you help Bill here?
Do we have testers for Mac OS X here?  Ripley?

Sven

===
From: Bill Tschumy <bill@...>
Newsgroups: comp.editors
Subject: Re: How to get keypad keys to work [MacOSX, vim]
Date: Thu, 29 Mar 2001 21:44:01 -0600
Message-ID: <01HW.B6E95D21004A388C11C99950@...>

One other bit of info.  When I "make" using the stock system it dies
trying to compile term.c because termcap.h is not found.  This file isn't
on my MacOSX system (although I've installed  all the developer files).

Here is the compile output:

localhost% make
CC="cc -Iproto -DHAVE_CONFIG_H     -O2 --traditional-cpp     "
srcdir=. sh ./osdef.sh
osdef0.c:8: termcap.h: No such file or directory
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      buffer.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      charset.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      digraph.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      edit.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      eval.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_cmds.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_docmd.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ex_getln.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      fileio.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      getchar.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      if_cscope.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      main.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      mark.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      memfile.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      memline.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      menu.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      message.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      misc1.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      misc2.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      multbyte.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      normal.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      ops.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      option.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      os_unix.c
creating pathdef.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      pathdef.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      quickfix.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      regexp.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      screen.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      search.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      syntax.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      tag.c
cc -c -I. -Iproto -DHAVE_CONFIG_H -O2 --traditional-cpp      term.c
term.c:32: termcap.h: No such file or directory
make: *** [term.o] Error 1

* Bill Tschumy <bill@...>:
> I am trying to use vim (non-gui version) on the
> new MacOSX operating system (finally Unix on Mac).
> The "Terminal" app that comes with the OS does vt100 emulation.
> When I start up vim I get the opening message:
>      Terminal entry not found in terminfo
>      vt100 not known
>        <lists 4 terminal options>
>      defaulting to 'ansi'
> I assume my arrow keys and other keypad keys are not working
> (generally just beeps) because it doesn't know about vt100.
> What do I need to do to get this working?

* Sven Guckes:
> Install vim with "+builtin_terms"?  Please try.

--
Bill Tschumy
Otherwise -- Austin, TX
bill@...

At 11:21 AM -0500 3/30/01, Dave Chen wrote:
>Bill Tschumy wrote:
>
>>  I have gotten this to compile, but probably not in the correct way.
>>
>>  First in feature.h I commented in the definition of NO_BUILTIN_TCAPS
>>
>>  #ifdef HAVE_TGETENT
>>  #  define NO_BUILTIN_TCAPS
>>  #endif
>>
>>  Then in config.h I manually commented  out the define of
>>  HAVE_TERMCAP_H (I know this is auto-generated and there probably
>>  something else I could change but I couldn't find it).  This file
>>  does not appear to be present on Mac OSX.
>>
>>  /* Define if you have the <termcap.h> header file.  */
>>  /*#define HAVE_TERMCAP_H 1*/
>>
>>  This seemed to compile correctly and VIM now recognizes my vt100
>>terminal type.
>
>When I do a "configure" and then "make"  it does the right thing.
>
>If uses termios.h, not termcap.h.  Not sure why your configure doesn't
>
>get it right.
>
>Dave
>

I definitely did a configure before make, but it got it wrong.  Not
sure either.

--
Bill Tschumy
Otherwise -- Austin, TX
bill@...

Bill Tschumy wrote:

> One other bit of info.  When I "make" using the stock system it dies
> trying to compile term.c because termcap.h is not found.  This file isn't
> on my MacOSX system (although I've installed  all the developer files).
>
> Here is the compile output:
>
> localhost% make
> CC="cc -Iproto -DHAVE_CONFIG_H     -O2 --traditional-cpp     "
> srcdir=. sh ./osdef.sh
> osdef0.c:8: termcap.h: No such file or directory

Since this inside a #ifdef HAVE_TERMCAP_H, there must be something
wrong with running configure.  Any idea why HAVE_TERMCAP_H was defined
while the compiler can't find it?

--
ARTHUR:       Now stand aside worthy adversary.
BLACK KNIGHT: (Glancing at his shoulder) 'Tis but a scratch.
ARTHUR:       A scratch?  Your arm's off.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Bill Tschumy wrote:

> I have gotten this to compile, but probably not in the correct way.
>
> First in feature.h I commented in the definition of NO_BUILTIN_TCAPS
>
> #ifdef HAVE_TGETENT
> #  define NO_BUILTIN_TCAPS
> #endif

You could also do this with a compiler argument -DNO_BUILTIN_TCAPS

> Then in config.h I manually commented  out the define of
> HAVE_TERMCAP_H (I know this is auto-generated and there probably
> something else I could change but I couldn't find it).  This file
> does not appear to be present on Mac OSX.
>
> /* Define if you have the <termcap.h> header file.  */
> /*#define HAVE_TERMCAP_H 1*/

Strange.  This is checked with the standard autoconf check
AC_CHECK_HEADERS.  Perhaps the shell isn't 100% compatible?

--
Any resemblance between the above views and those of my employer, my terminal,
or the view out my window are purely coincidental.  Any resemblance between
the above and my own views is non-deterministic.  The question of the
existence of views in the absence of anyone to hold them is left as an
exercise for the reader.  The question of the existence of the reader is left
as an exercise for the second god coefficient.  (A discussion of
non-orthogonal, non-integral polytheism is beyond the scope of this article.)
						 (Ralph Jennings)

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Bill Tschumy wrote:

> I have gotten this to compile, but probably not in the correct way.
>
> First in feature.h I commented in the definition of NO_BUILTIN_TCAPS
>
> #ifdef HAVE_TGETENT
> #  define NO_BUILTIN_TCAPS
> #endif
>
> Then in config.h I manually commented  out the define of
> HAVE_TERMCAP_H (I know this is auto-generated and there probably
> something else I could change but I couldn't find it).  This file
> does not appear to be present on Mac OSX.
>
> /* Define if you have the <termcap.h> header file.  */
> /*#define HAVE_TERMCAP_H 1*/
>
> This seemed to compile correctly and VIM now recognizes my vt100 terminal
type.

When I do a "configure" and then "make"  it does the right thing.

If uses termios.h, not termcap.h.  Not sure why your configure doesn't

get it right.

Dave

--
___( mailto:dave@..., http://visual.nlm.nih.gov/~dave )___
The only thing that allows me to keep my slender grip on reality
is the friendship I share with my collection of singing potatoes.
                 -- Holly, "Red Dwarf"

Quoting Sven Guckes (guckes@...):
> Can you help Bill here?
> Do we have testers for Mac OS X here?  Ripley?

No time at all from me, but you're welcome to visit me at
my place and use my G3 for it.


Greetings,
				 Ripley
--
H. Eckert, 12051 Berlin
ISO 8859-1: �=Ae, �=Oe, �=Ue, �=ae, �=oe, �=ue, �=sz.

Wanted to let the list know that I did get this to work.  The config
problem seemed to be due to the distribution I used (downloaded from
someone who said he had compiled for Mac OS X).  When I downloaded
the "official" distribution and configed/compiled  it there was no
problem.  It now recognizes the vt100 terminal and I have my arrow
keys working.

If anyone needs anything checked out on OSX just let me know.

BTW: Has there been any discussion of getting gvim running on OSX?

At 9:05 AM +0200 4/3/01, H. Eckert wrote:
>Quoting Sven Guckes (guckes@...):
>>  Can you help Bill here?
>>  Do we have testers for Mac OS X here?  Ripley?
>
>No time at all from me, but you're welcome to visit me at
>my place and use my G3 for it.
>
>
>Greetings,
> 		 Ripley
>--
>H. Eckert, 12051 Berlin
>ISO 8859-1: �=Ae, �=Oe, �=Ue, �=ae, �=oe, �=ue, �=sz.

--
Bill Tschumy
Otherwise -- Austin, TX
bill@...

Hi everyone,

last weekend I have downloaded the Carbon SDK and started to look
through the code.

I have added all the suggestion from Carbon Dater as comments and
started to #ifdef non-Carbon functions. While doing this I discovered
that Carbon Dater and the Universal Interface 3.4 often disagree about
what is in Carbon.

If someone wants to help porting please get in contact with me to avoid
doing the work twice.

I hope the Makefile patch will survive e-mail, if not you hae to fix it
manually, it is only one line.

Axel


*** CodeWarrior:Source:vim60w:src.orig:gui_mac.c        Sat Mar 10
17:04:29 2001
--- CodeWarrior:Source:vim60w:src:gui_mac.c.classic     Sun Apr  8
00:25:43 2001
***************
*** 417,422 ****
--- 417,427 ----
         {
             appleMenu = GetMenuHandle (menu);
             GetMenuItemText (appleMenu, item, itemName);
+ /*
+ OpenDeskAcc
+
+ Desk accessories are not supported in Carbon. Not available in Carbon.
+ */
             (void) OpenDeskAcc (itemName);
         }
       }
***************
*** 545,551 ****
--- 550,599 ----
   #ifdef USE_CTRLCLICKMENU
       long      gestalt_rc;
   #endif
+ /*
+ MaxApplZone
+
+ This routine is not needed by PowerPC-based applications because they
can
+ specify a stack size in the cfrg resource. Not available in Carbon.
+
+ InitGraf
+
+ In Carbon, the Mac OS automatically initializes Quickdraw for every
+ application. When the Mac OS initializes QuickDraw, the Mac OS also
+ automatically calls InitGraf. Not available in Carbon.
+
+ InitFonts
+
+ There is no need to initialize the Font Manager because the shared
library
+ is loaded as needed. Not available in Carbon.
+
+
+ InitWindows
+
+ InitWindows is not supported in Carbon. There is no need to initialize
the
+ Window Manager because the shared library is loaded as needed. Not
+ available in Carbon.
+
+ InitMenus
+
+ InitMenus is not supported in Carbon. There is no need to initialize
the
+ Menu Manager because the shared library is loaded as needed. Not
available
+ in Carbon.
+
+ InitDialogs
+
+ InitDialogs is not supported in Carbon. There is no need to initialize
the
+ Dialog Manager because the shared library is loaded as needed. Not
+ available in Carbon.

+ TEInit
+
+ There is no need to initialize TextEdit because the shared library is
+ loaded as needed. Not available in Carbon.
+
+ */
+
+ #if ! TARGET_API_MAC_CARBON
       MaxApplZone();
       InitGraf(&qd.thePort);
       InitFonts();
***************
*** 553,558 ****
--- 601,607 ----
       InitMenus();
       TEInit();
       InitDialogs(nil);
+ #endif
       InitCursor();

   #ifdef USE_AEVENT
***************
*** 587,593 ****
   #else
       SetRect (&windRect, 300, 40, 300+80*7 + 16, 40+24*11);
   #endif
!
       gui.VimWindow = NewCWindow(nil, &windRect, "\pgVim on Macintosh",
true, documentProc,
                         (WindowPtr) -1, false, 0);

--- 636,646 ----
   #else
       SetRect (&windRect, 300, 40, 300+80*7 + 16, 40+24*11);
   #endif
! /* NewCWindow:
!    In Carbon, you cannot pass your own storage in to the wStorage
parameter.
!    Available in Carbon 1.0.2 and later when running Mac OS 8.1 or
later.
!    Here: nil
!    */
       gui.VimWindow = NewCWindow(nil, &windRect, "\pgVim on Macintosh",
true, documentProc,
                         (WindowPtr) -1, false, 0);

***************
*** 614,623 ****
       DrawMenuBar();

   #ifdef USE_HELPMENU
       (void) HMGetHelpMenuHandle(&gui.MacOSHelpMenu); /* Getting a
handle to the Help menu */

       if (gui.MacOSHelpMenu != nil)
!       gui.MacOSHelpItems = CountMItems (gui.MacOSHelpMenu);
       else
         gui.MacOSHelpItems = 0;
   #endif
--- 667,687 ----
       DrawMenuBar();

   #ifdef USE_HELPMENU
+ /*
+ HMGetHelpMenuHandle
+
+ Not available in Carbon.
+
+ CountMItems
+
+ CountMItems has been renamed to CountMenuItems in Carbon. Not
available in
+ Carbon.
+ */
+
       (void) HMGetHelpMenuHandle(&gui.MacOSHelpMenu); /* Getting a
handle to the Help menu */

       if (gui.MacOSHelpMenu != nil)
!       gui.MacOSHelpItems = CountMenuItems (gui.MacOSHelpMenu);
       else
         gui.MacOSHelpItems = 0;
   #endif
***************
*** 833,839 ****
--- 897,913 ----
       STRCPY(&pFontName[1], font_name);
       pFontName[0] = STRLEN(font_name);
       *p = c;
+ /* GetFNum
+
+ You should instead use FMGetFontFamilyFromName. Available in Carbon
+ 1.0.2 and later when running Mac OS 8.1 or later.

+ EXTERN_API( void )
+ GetFNum                         (ConstStr255Param       name,
+                                  short *                familyID)
+ EXTERN_API_C( FMFontFamily )
+ FMGetFontFamilyFromName         (ConstStr255Param       iName);
+ */
       GetFNum (pFontName, &font_id);

       if (font_id == 0)
***************
*** 840,845 ****
--- 914,933 ----
       {
         /* Oups, the system font was it the one the user want */

+ /*
+ GetFontName
+
+ You should instead use FMGetFontFamilyName. Available in Carbon 1.0.2
and
+ later when running Mac OS 8.1 or later.
+
+ EXTERN_API( void )
+ GetFontName                     (short                  familyID,
+                                  Str255                 name)
+ EXTERN_API_C( OSStatus )
+ FMGetFontFamilyName             (FMFontFamily           iFontFamily,
+                                  Str255                 oName);
+ */
+
         GetFontName (0, systemFontname);
         if (!EqualString(pFontName, systemFontname, false, false))
             return NOFONT;
***************
*** 1966,1972 ****
--- 2054,2071 ----
       int               type;
       char      *searchCR;
       char      *tempclip;
+ /*
+ LoadScrap

+ Carbon applications may continue calling this function on Mac OS 8;
+ however, on Mac OS X it does nothing and is no longer necessary.
+ Available in Carbon 1.0.2 and later when running Mac OS 8.1 or later.
+
+ GetScrap
+
+ You should instead use the functions ScrapHasFlavor,
GetScrapFlavorSize,
+ and GetScrapFlavorData. Not available in Carbon.
+ */
       scrapSize = LoadScrap (); /* This seem to avoid problem with crash
on first paste */
       scrapSize = GetScrap ( nil, 'TEXT', &scrapOffset);

***************
*** 2044,2049 ****
--- 2143,2155 ----
       if (type >= 0)
       {

+ /*
+ ZeroScrap
+
+ You should instead use the function ClearCurrentScrap. Not available
in
+ Carbon.
+
+ */
         ZeroScrap ();

         textOfClip = NewHandle(scrapSize);
***************
*** 2051,2056 ****
--- 2157,2169 ----
         HLock (textOfClip);

             STRNCPY (*textOfClip, str, scrapSize);
+ /*
+ PutScrap
+
+ You should instead use the function PutScrapFlavor. Not available in
+ Carbon.
+
+ */
             PutScrap (scrapSize, 'TEXT', *textOfClip);

         HUnlock (textOfClip);
***************
*** 2315,2333 ****
   /*
       index = menu->index;
   */
       if (grey)
       {
         if (menu->children)
!           DisableItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           DisableItem(menu->menu_handle, index);
       }
       else
       {
         if (menu->children)
!           EnableItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           EnableItem(menu->menu_handle, index);
       }
   }

--- 2428,2456 ----
   /*
       index = menu->index;
   */
+ /*
+ DisableItem
+
+ Replaced by DisableMenuItem. Not available in Carbon.
+
+ EnableItem
+
+ Replaced by EnableMenuItem. Not available in Carbon.
+
+ */
       if (grey)
       {
         if (menu->children)
!           DisableMenuItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           DisableMenuItem(menu->menu_handle, index);
       }
       else
       {
         if (menu->children)
!           EnableMenuItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           EnableMenuItem(menu->menu_handle, index);
       }
   }

***************
*** 2347,2362 ****
       if (hidden)
       {
         if (menu->children)
!           DisableItem(menu->submenu_handle, menu->index);
         if (menu->menu_handle)
!           DisableItem(menu->menu_handle, menu->index);
       }
       else
       {
         if (menu->children)
!           EnableItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           EnableItem(menu->menu_handle, index);
       }
   }

--- 2470,2485 ----
       if (hidden)
       {
         if (menu->children)
!           DisableMenuItem(menu->submenu_handle, menu->index);
         if (menu->menu_handle)
!           DisableMenuItem(menu->menu_handle, menu->index);
       }
       else
       {
         if (menu->children)
!           EnableMenuItem(menu->submenu_handle, index);
         if (menu->menu_handle)
!           EnableMenuItem(menu->menu_handle, index);
       }
   }

***************
*** 2585,2590 ****
--- 2708,2719 ----
       if (saving)
       {
         /* Use a custon filter instead of nil FAQ 9-4 */
+ /*
+ StandardPutFile
+
+ Not available in Carbon.
+
+ */
         StandardPutFile (Prompt, DefaultName,  &reply);
         if (!reply.sfGood)
             return NULL;
***************
*** 2591,2596 ****
--- 2720,2730 ----
       }
       else
       {
+ /*
+ StandardGetFile
+
+ Not available in Carbon.
+ */
         StandardGetFile (nil, -1, fileTypes, &reply);
         if (!reply.sfGood)
             return NULL;
***************
*** 3502,3507 ****
--- 3636,3650 ----
         }
         else
         {
+ /* GetProcessInformation:
+    The processActiveTime field of the returned ProcessInfoRec
structure is
+    not used in Carbon on Max OS X. In Carbon on Mac OS 8 and 9, the
+    accumulated amount of CPU time used by the process is returned in
this
+    field. In Carbon on Mac OS X, the value returned in this field is
always
+    0. Other fields in the ProcessInfoRec structure may also no longer
be
+    applicable. Available in Carbon 1.0.2 and later when running Mac OS
8.1
+    or later.
+ */
             anErr = GetProcessInformation( psnPtr, &infoRec );
             if ( ( anErr == noErr )
                  && ( infoRec.processType == targetType )


*** CodeWarrior:Source:vim60w:Make_mpw.mak.orig
--- CodeWarrior:Source:vim60w:Make_mpw.mak
***************
*** 117,122 ****
--- 117,133 ----
                                   "{SharedLibraries}InterfaceLib" �
                                   "{SharedLibraries}MathLib" �
                                   "{SharedLibraries}StdCLib" �
+                                 "{SharedLibraries}MenusLib" �
                                   "{PPCLibraries}StdCRuntime.o" �
                                   "{PPCLibraries}PPCStdCLib.o" �
                                   "{PPCLibraries}PPCCRuntime.o" �
***************

--
There is nothing left to try
There is nothing left to choose
There is no greater power
Than the power of VI

Hi everyone,

it is a little early to talk about success but the following patches compile
and link with MPW. (All patches against 6.0w, the makefile is new because it
got broken in the release.)

The classic version is still working as good as before the patches, while
the Carbon version crashes or doesn't find the CarbonLib.

My environment:
Universal headers 3.4 (included in the Carbon 1.2.5 SDK), I haven't checked
against 3.3.2 yet.

Maybe someone has some time over the Easter break to play with these files.
I'm planning to send the patches to Bram the week after Easter.

The list doesn't accept mailings with large attachements, I you are
interested, please send me an email.

Axel

Axel,

It's not garanty i'll be able to find any time, but can you move the
complete project to an iDisk so I (or anyone else) can take a look. It's
very easy to setup if you don't already have one (itools.apple.com)

stephane


On Wednesday, April 11, 2001, at 12:13 PM, Axel Kielhorn wrote:

> Hi everyone,
>
> it is a little early to talk about success but the following patches
> compile
> and link with MPW. (All patches against 6.0w, the makefile is new
> because it
> got broken in the release.)
>
> The classic version is still working as good as before the patches,
> while
> the Carbon version crashes or doesn't find the CarbonLib.
>
> My environment:
> Universal headers 3.4 (included in the Carbon 1.2.5 SDK), I haven't
> checked
> against 3.3.2 yet.
>
> Maybe someone has some time over the Easter break to play with these
> files.
> I'm planning to send the patches to Bram the week after Easter.
>
> The list doesn't accept mailings with large attachements, I you are
> interested, please send me an email.
>
> Axel
>
>

Since I can't send attachments via this list, I put new versions of the
Mac-related files on the macvim iDisk.

You can get some 5.7 and 6.0w patches there.

I'm planning to put the 6.0z version there soon.

Axel

Axel,

So far all I can see there are the binaries for 5.7 and the
corresponding runtime. No source code or project.

stephane


On Wednesday, April 18, 2001, at 05:55 AM, Axel Kielhorn wrote:

> Since I can't send attachments via this list, I put new versions of the
> Mac-related files on the macvim iDisk.
>
> You can get some 5.7 and 6.0w patches there.
>
> I'm planning to put the 6.0z version there soon.
>
> Axel
>
>

actualy, my mistake. It's there..

stephane


On Wednesday, April 18, 2001, at 09:51 AM, Stephane Huaulme wrote:

> Axel,
>
> So far all I can see there are the binaries for 5.7 and the
> corresponding runtime. No source code or project.
>
> stephane
>
>
> On Wednesday, April 18, 2001, at 05:55 AM, Axel Kielhorn wrote:
>
>> Since I can't send attachments via this list, I put new versions of the
>> Mac-related files on the macvim iDisk.
>>
>> You can get some 5.7 and 6.0w patches there.
>>
>> I'm planning to put the 6.0z version there soon.
>>
>> Axel
>>
>>
>

I just downloaded VIM 5.7.1 [or whatever it is exactly] and the runtime
archive from Alex's iDisk (user macvim, of course -- was this announced
here?  I don't recall it if so.  Neato!)  I've not used VIM in a while,
so I backed up my old vimrc's, and started up a clean copy of VIM.

When VIM launches, it complains that it can't find "_vim.bracketing".
This, of course, is because selfsame file is sourced in vimrc, but is
nowhere to be found in the distribution.  (What is it?  Should I care?)

Forgive me for nitpicking, but it strikes me that a plain vanilla
distribution of VIM ought to launch for the first time without error :-)
[Or is this some sort of geeks-only hazing process?]

Question, while I'm being annoying: do Axel and Dan ever plan on
deciding what is the "official" MacVIM?  Or is there some sort of
agreement on this?

David Craig


<http://cda.mrs.umn.edu/~dac/>

I've stumped our local vi-types on this one: what is the basic unix vi
equivalent of VIM's "gq<move>" for re-formatting text?  (We're on
Digital Unix 4.0D here, not that that should be especially relevant.) In
particular, it seems excessively hard to simply re-justify a paragraph's
text.  Or am I just too accustomed to VIM?

David Craig


<http://cda.mrs.umn.edu/~dac/>

On Thu, Apr 19, 2001 at 02:03:12AM -0500, david craig wrote:
:
: Forgive me for nitpicking, but it strikes me that a plain vanilla
: distribution of VIM ought to launch for the first time without error :-)
: [Or is this some sort of geeks-only hazing process?]

The plain vanilla distribution of Vim does work quite well.  It's the
Mac port that's fallen behind.  But don't blame the Mac folks; it's
more due to the lack of developers working on MacVim compared to the
other platforms, and that getting Vim to run on the Mac seems to take
lots more work than on other other platforms.  Then again, the console
version of Vim 5.7 (not GVim) compiles fairly cleanly on Mac OS X.

: Question, while I'm being annoying: do Axel and Dan ever plan on
: deciding what is the "official" MacVIM?  Or is there some sort of
: agreement on this?

MacVim is a work in progress.  There's the binaries that you can
download and use.  I'm looking forward to the Carbon port for 6.0,
whenever it comes out.


--
Eugene Lee
eugene@...

On Thu, Apr 19, 2001 at 02:07:55AM -0500, david craig wrote:
:
: I've stumped our local vi-types on this one: what is the basic unix vi
: equivalent of VIM's "gq<move>" for re-formatting text?  (We're on
: Digital Unix 4.0D here, not that that should be especially relevant.) In
: particular, it seems excessively hard to simply re-justify a paragraph's
: text.  Or am I just too accustomed to VIM?

Short answer: you're too accustomed to Vim.  :)

Long answer: pipe the lines to an external filter, like fmt or par, that
does the job.  I used to use this mapping to format my emails:

	 map gp !par -gqr 72^M


--
Eugene Lee
eugene@...

I don't mean to "blame" anyone.  In fact, I greatly appreciate the work
put in by all concerned.  However, every time I go looking for MacVIM,
it's still true that there's some ambiguity about where I should go to
get it, and about the relationship between the available choices in
terms of bugs (new and old), features, documentation, synchronicity with
releases of VIM on other platforms, and so on.

Mac OS X seems to me to hold much promise for MacVIM.  The more
organized is the current MacVIM community as the transition to a vastly
more vi-friendly world proceeds, the brighter the future of MacVIM. Or
so it seems from here.

David Craig


<http://cda.mrs.umn.edu/~dac/>

Finally, the first book about Vim is here!
It's written by Steve Oualline and published by New Riders.

It is about 600 pages, and contains an awful lot of information.
For beginners it starts with explaining the basic commands, with pictures and
lots of examples.  Gradually more advanced commands are introduced.  Although
these are explained with less detail.

There is a large appendix that lists all the commands and options.  A quick
reference as well.

You can find more information through this link:

	 http://www.iccf.nl/click5.html

This also allows you to order the book with a few on-line book stores where a
percentage of the sales goes to ICCF holland, to help children in Uganda.
You can find the book in other stores as well (might take some time before it
is available).

The book is published under the Open Publication License.  I plan to include
parts of the text in the user manual for Vim 6.0.  But that is still many
months away.

--
If VIM were a woman, I'd marry her.  Slim, organized, helpful
and beautiful; what's not to like?     --David A. Rogers

  ///  Bram Moolenaar -- Bram@... -- http://www.moolenaar.net  \\\
(((   Creator of Vim - http://www.vim.org -- ftp://ftp.vim.org/pub/vim   )))
  \\\  Help me helping AIDS orphans in Uganda - http://iccf-holland.org  ///

Hi everyone!

Over the easter break Bram released a new version of Vim.
I have added all patches I had to this version and put it on my iDisk
(macvim). I'm planning to add web-download support over the weekend, the URL
will be http://homepage.mac.com/macvim/.

As with 6.0w, it compiles and runs in classic, but doesn't run in carbon.


Axel

Ok, I did it.

On the macvim idisk you can now find a new version of MacVim called
vim57bin26new.sea.

This version includes some of the Carbon patches, thus it is PPC only.
I have included the source and the CW project I used to build this version
as well as an additional patch that isn't working as supposed.

The only thing broken in this binary is the removal of menus, you have to
live with two buffer menus until that is fixed.

This time I rememberd to include the correct vimrc:-)

Axel

am 2001-04-19 9:03 Uhr schrieb david craig unter dac@...:

>
> I just downloaded VIM 5.7.1 [or whatever it is exactly] and the runtime
> archive from Alex's iDisk

>From the Archive name vim57bin26.sea I would guess it is Vim 5.7.26, but who
knows what is really in there:-)

> When VIM launches, it complains that it can't find "_vim.bracketing".

Oops, sorry.
I included my vimrc, maybe I should create a special vimrc for the
distribution.

> This, of course, is because selfsame file is sourced in vimrc, but is
> nowhere to be found in the distribution.  (What is it?  Should I care?)

It is a collection of macros to format brackets.
Don't care, just remove the line.

> Forgive me for nitpicking, but it strikes me that a plain vanilla
> distribution of VIM ought to launch for the first time without error :-)
> [Or is this some sort of geeks-only hazing process?]

Vim is for geeeks only, didn't you now?

A new version with Navigation Service Support (and a fixed vimrc) is on the
way, including a better download page. I hope I find some time this weekend.

> Question, while I'm being annoying: do Axel and Dan ever plan on
> deciding what is the "official" MacVIM?  Or is there some sort of
> agreement on this?

You will have noticed that there is a subfolder "Axel" on the iDisk. Since
we have about 20 MB there, it should be possible to have a folder "Dany"
next to it. (Dany has a more recent compiler with newer libraries, thus he
may be able to compile a CodeWarrior Version for Carbon.)

I know of 4 different official versions, compiled with different compilers
and different features. The goal should be to make Vim compile with Apple's
free MPW compiler, then everyone can make a version according to his needs.
(Well, Vim 6.0ab + patches already compiles, but it is lacking many
features.)

Axel

Axel-

> I included my vimrc, maybe I should create a special vimrc for the
> distribution.

One that doesn't source files not included, certainly!

> It is a collection of macros to format brackets.
> Don't care, just remove the line.

Done.  Thanks for the info!

> You will have noticed that there is a subfolder "Axel" on the iDisk. Since
> we have about 20 MB there, it should be possible to have a folder "Dany"
> next to it.
>
> I know of 4 different official versions

That would be great!  It would be even greater if at the top level there
might be "read me" that all of you wonderful authors had access to in
which you could explain the differences between the different builds, so
people could figure out which of the bleeding-edge versions they need
most.

How about it?  Could all of the VIM authors -- or a few of you, at least
-- agree to maintain copies of your current build of VIM on the VIM
iDisk?  (If space ran out, it's easy to create additional accounts.)

David Craig


<http://cda.mrs.umn.edu/~dac/>