On Wed, Jan 14, 2004 at 11:10:34AM +0100, Bram Moolenaar wrote:
>
> Benji Fisher wrote:
>
> >      Thanks to Ken Scott, there is a new binary of Vim.app available at
> > http://macvim.swdev.org/OSX/#Downloading
> > Since it was compiled with Python support, it will probably run only on
> > OS X 10.3 (Panther), unless you install the Python 2.3 libraries.
>
> I tried it on 10.2 (still don't have 10.3) and got this error message:
>
>  dyld: Vim can't open library: /usr/lib/libiconv.2.dylib
>
> Is that a new library in 10.3?
>
> The Mac OS/X support is high on the voting list, thus I should probably
> do some work on it myself...

      I would expect this version to have problems on 10.2 because of the
Python libraries, but I suppose this is also a problem.  Yes, 10.3 seems
to come with libiconv.dylib :

% ls -l /usr/lib/*iconv*
lrwxr-xr-x  1 root  wheel      16 26 Oct 14:25 /usr/lib/libiconv.2.2.0.dylib ->
libiconv.2.dylib
-rw-r--r--  1 root  wheel  987440  6 Jan 21:18 /usr/lib/libiconv.2.dylib
lrwxr-xr-x  1 root  wheel      20 26 Oct 14:25 /usr/lib/libiconv.dylib ->
libiconv.2.2.0.dylib
-rw-r--r--  1 root  wheel     786 12 Sep 16:59 /usr/lib/libiconv.la

Should configure be looking for the symlink libiconv.dylib instead of
the real library?

      The good news is that, on OS X 10.3, vim compiles with +iconv .
How should I test this?  Does this solve the #1 complaint with the OS X
Carbon version?  I am not sure how to test this, since I am happy with
7-bit ASCII, lucky Anglophone that I am.  I tried to describe the
problem on the web site as follows:

	 Encoding is not always recognized (e.g. :set
	 fileencoding=latin1), resulting in MacRoman output instead of
	 the specified encoding.

Can someone describe an explicit test for this?

      We should have a new binary for 10.2 soon.  Any volunteers for
10.0/10.1?

					 --Benji Fisher

On Jan 14, 2004, at 8:05 AM, Benji Fisher wrote:

> On Wed, Jan 14, 2004 at 11:10:34AM +0100, Bram Moolenaar wrote:
>>
>> Benji Fisher wrote:
>>
>>>      Thanks to Ken Scott, there is a new binary of Vim.app available
>>> at
>>> http://macvim.swdev.org/OSX/#Downloading
>>> Since it was compiled with Python support, it will probably run only
>>> on
>>> OS X 10.3 (Panther), unless you install the Python 2.3 libraries.
>>
>> I tried it on 10.2 (still don't have 10.3) and got this error message:
>>
>>  dyld: Vim can't open library: /usr/lib/libiconv.2.dylib
>>
>> Is that a new library in 10.3?
>>
>> The Mac OS/X support is high on the voting list, thus I should
>> probably
>> do some work on it myself...
>
>      I would expect this version to have problems on 10.2 because of
> the
> Python libraries, but I suppose this is also a problem.  Yes, 10.3
> seems
> to come with libiconv.dylib :

Among other things.  It's pretty hard to build something +python that
works on 10.2 and 10.3 without actually including Python itself (which
is possible and actually pretty easy since Python is a framework).

> % ls -l /usr/lib/*iconv*
> lrwxr-xr-x  1 root  wheel      16 26 Oct 14:25
> /usr/lib/libiconv.2.2.0.dylib -> libiconv.2.dylib
> -rw-r--r--  1 root  wheel  987440  6 Jan 21:18
> /usr/lib/libiconv.2.dylib
> lrwxr-xr-x  1 root  wheel      20 26 Oct 14:25 /usr/lib/libiconv.dylib
> -> libiconv.2.2.0.dylib
> -rw-r--r--  1 root  wheel     786 12 Sep 16:59 /usr/lib/libiconv.la
>
> Should configure be looking for the symlink libiconv.dylib instead of
> the real library?

The linker command "-liconv" is going to use /usr/lib/libiconv.dylib,
so that's probably what you should test for.

-bob

On Wed, Jan 14, 2004 at 06:09:25AM -0600, Emily Jackson wrote:
>
> I tried putting "set transparency=235" in my .vimrc, but transparency
> doesn't take effect; I have to enter the command manually after Vim has
> started up.

      I can confirm this.  The option has been set, but does not seem to
have any effect.  Here is a work-around:

au VimEnter * set transparency=235

					 --Benji Fisher

On Wed, Jan 14, 2004 at 08:11:47AM -0500, Bob Ippolito wrote:
>
> On Jan 14, 2004, at 8:05 AM, Benji Fisher wrote:
>
> >On Wed, Jan 14, 2004 at 11:10:34AM +0100, Bram Moolenaar wrote:
> >>
> >>I tried it on 10.2 (still don't have 10.3) and got this error message:
> >> dyld: Vim can't open library: /usr/lib/libiconv.2.dylib
> >
> >     I would expect this version to have problems on 10.2 because of
> >the Python libraries, but I suppose this is also a problem.  Yes,
> >10.3 seems to come with libiconv.dylib :
>
> Among other things.  It's pretty hard to build something +python that
> works on 10.2 and 10.3 without actually including Python itself (which
> is possible and actually pretty easy since Python is a framework).

      Should we move in this direction?  That is, should we make the
binary distribution for OS X as portable as possible?  It would be
simpler to have two versions (one huge, including the python, perl, ...
libraries that it uses, one with no support for python, perl, etc.) than
to have one version for 10.1, one for 10.2, one for 10.3, ...

      When trying to compile with +perl, configure complains that it will
not use a threaded version of perl.  (This is on 10.3.)  My guess is
that including the perl libraries is the only way to distribute a
version of Vim.app that works with perl on 10.3.

      Can anyone give me instructions?

					 --Benji Fisher

On Jan 14, 2004, at 10:29 AM, Benji Fisher wrote:

> On Wed, Jan 14, 2004 at 08:11:47AM -0500, Bob Ippolito wrote:
>>
>> On Jan 14, 2004, at 8:05 AM, Benji Fisher wrote:
>>
>>> On Wed, Jan 14, 2004 at 11:10:34AM +0100, Bram Moolenaar wrote:
>>>>
>>>> I tried it on 10.2 (still don't have 10.3) and got this error
>>>> message:
>>>>  dyld: Vim can't open library: /usr/lib/libiconv.2.dylib
>>>
>>>     I would expect this version to have problems on 10.2 because of
>>> the Python libraries, but I suppose this is also a problem.  Yes,
>>> 10.3 seems to come with libiconv.dylib :
>>
>> Among other things.  It's pretty hard to build something +python that
>> works on 10.2 and 10.3 without actually including Python itself (which
>> is possible and actually pretty easy since Python is a framework).
>
>      Should we move in this direction?  That is, should we make the
> binary distribution for OS X as portable as possible?  It would be
> simpler to have two versions (one huge, including the python, perl, ...
> libraries that it uses, one with no support for python, perl, etc.)
> than
> to have one version for 10.1, one for 10.2, one for 10.3, ...

I think that this route is good for Mac OS users, to embed the
scripting languages.  It wouldn't be quite as problematic if Apple
didn't make so many sensible improvements to Darwin every major release
:)  Perhaps there should be 3 releases:
	 1) Includes scripting langauges, compatible with 10.1 (10.2 possibly)
	 2) No scripting languages, compatible with 10.1
	 3) Includes scripting language support, but not the scripting
languages themselves (latest OS version only, 10.3 right now).

I would personally pick the 3rd because I keep up with Apple's releases
and because I know it'll be linked to the latest and greatest (like
iconv).

>      When trying to compile with +perl, configure complains that it
> will
> not use a threaded version of perl.  (This is on 10.3.)  My guess is
> that including the perl libraries is the only way to distribute a
> version of Vim.app that works with perl on 10.3.

That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
what the deal is with that?  Is a threaded Python ok because it has the
GIL, or should a non-threaded version be in Vim as well?  Or maybe..
Vim's configure script should take a threaded Perl?

-bob

On Jan 14, 2004, at 8:39 AM, Bob Ippolito wrote:

> [snip]

> That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
> what the deal is with that?  Is a threaded Python ok because it has
> the GIL, or should a non-threaded version be in Vim as well?  Or
> maybe..  Vim's configure script should take a threaded Perl?
>

If someone can talk me through modifying the configure script, I'll try
building it to accept the threaded perl, and see if it can do basic
things or not.

Ken Scott

--
<><      Ken Scott   ken@...   http://hobbes.optikos.net/~ken

         This is the day that the Lord has made;
         Let us rejoice and be glad in it          -- Psalm 118:24

Maybe this should be glaringly obvious to me, but why is it that when I
'set alias' in my vimrc, it doesn't actually set?  It works fine when I
do it once in the program.

--
rjbs

Benji Fisher wrote:

> > Among other things.  It's pretty hard to build something +python that
> > works on 10.2 and 10.3 without actually including Python itself (which
> > is possible and actually pretty easy since Python is a framework).
>
>      Should we move in this direction?  That is, should we make the
> binary distribution for OS X as portable as possible?  It would be
> simpler to have two versions (one huge, including the python, perl, ...
> libraries that it uses, one with no support for python, perl, etc.) than
> to have one version for 10.1, one for 10.2, one for 10.3, ...

I asked the MacPython expert about this.  His reaction was that it's not
a good idea to include Python for 10.3.  For 10.2 installing a recent
MacPython version is best.

It's very likely not possible to make a Vim that runs on both 10.2 and
10.3, unless we leave out things that are new on 10.3 (e.g., iconv).

For now, I would think it's best to make a Vim version for 10.2 and one
for 10.3 in such a way that it doesn't require other installing things.
I dislike the idea of requiring MacPython version n.m first and
including it makes the distribution big and may cause new problems.

It seems that the idea to make one Vim binary for all 10.x versions is
bound to fail... :-(.

--
If I tell you "you have a beautiful body", would you hold it against me?

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Thu, Jan 15, 2004 at 04:32:04AM -0500, Ricardo SIGNES wrote:
> Maybe this should be glaringly obvious to me, but why is it that when I
> 'set alias' in my vimrc, it doesn't actually set?  It works fine when I
> do it once in the program.

      You mean 'anti', not 'alias', right?

      When I announced the binary with +antialias , I said

> Antialiasing:
>
>      Am I the only one who has trouble with this?  When the 'guifont'
> option is empty, I have serious problems.  The characters take up the
> wrong amount of space, and moving the cursor over them changes their
> positions.
>
>      Peter Cucka optimistically made 'antialias' the default.  I
> cautiously wanted to make 'noantialias' the default.  The first version
> of the patch he sent me made it hard to turn it off, so I added
>
>  au VimEnter * set noantialias
>
> to the system vimrc.  I did not update this to a simple
>
>  set noantialias
>
> yet.  Conclusions:  (1) This is still an experimental patch.  (2) If it
> works for you, and you want to set 'antialias' in your vimrc file, go
> fix the system vimrc file.

      I will add a shorter note to the same effect on the web page.

HTH 			 --Benji Fisher

* Benji Fisher <benji@...> [2004-01-15T14:27:28]
>      When I announced the binary with +antialias , I said
>  [ helpful message snipped]

Ah.  I meant to go back and read the announcement for possible
explanations, but I'd deleted it.

It might be nice to include this on :help antialias, actually.

--
rjbs

On Fri, Jan 16, 2004 at 07:19:05AM -0500, Ricardo SIGNES wrote:
> * Benji Fisher <benji@...> [2004-01-15T14:27:28]
> >      When I announced the binary with +antialias , I said
> >  [ helpful message snipped]
>
> Ah.  I meant to go back and read the announcement for possible
> explanations, but I'd deleted it.
>
> It might be nice to include this on :help antialias, actually.

      The next time we compile, it will be fixed.  This was just a
problem with my being one step behind Peter Cucka, who produced the
antialias patch.  As soon as Bram produces another batch of official
patches or there is a new wxperimental one ...

					 --Benji Fisher

On Wed, Jan 14, 2004 at 10:07:32AM -0700, Ken Scott wrote:
>
> On Jan 14, 2004, at 8:39 AM, Bob Ippolito wrote:
>
> >[snip]
>
> >That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
> >what the deal is with that?  Is a threaded Python ok because it has
> >the GIL, or should a non-threaded version be in Vim as well?  Or
> >maybe..  Vim's configure script should take a threaded Perl?
> >
>
> If someone can talk me through modifying the configure script, I'll try
> building it to accept the threaded perl, and see if it can do basic
> things or not.

      Tweaking the configure script is not easy.  I prefer to leave that
for people who understand autoconf.  As for perl, I assume there is a
reason not to link against a threaded version.  Bram?

					 --Benji Fisher

Benji Fisher wrote:

> On Wed, Jan 14, 2004 at 10:07:32AM -0700, Ken Scott wrote:
> >
> > On Jan 14, 2004, at 8:39 AM, Bob Ippolito wrote:
> >
> > >[snip]
> >
> > >That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
> > >what the deal is with that?  Is a threaded Python ok because it has
> > >the GIL, or should a non-threaded version be in Vim as well?  Or
> > >maybe..  Vim's configure script should take a threaded Perl?
> > >
> >
> > If someone can talk me through modifying the configure script, I'll try
> > building it to accept the threaded perl, and see if it can do basic
> > things or not.
>
>      Tweaking the configure script is not easy.  I prefer to leave that
> for people who understand autoconf.  As for perl, I assume there is a
> reason not to link against a threaded version.  Bram?

I do not know why Perl without threads is refused.  There is an explicit
configure check for it, thus there must be a good reason.  But perhaps
it was only for an old version of Perl?  It's also possible that
if_perl.xs is not prepared for threading.

You could edit src/auto/configure, search for "usethreads" and insert
this below the "eval" command:

	 usethreads=undef

Look out or compile errors and warnings in if_perl.c.

--
"Never be afraid to tell the world who you are."
                                         -- Anonymous

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Jan 16, 2004, at 6:03 AM, Bram Moolenaar wrote:

>
> Benji Fisher wrote:
>
>> On Wed, Jan 14, 2004 at 10:07:32AM -0700, Ken Scott wrote:
>>>
>>> On Jan 14, 2004, at 8:39 AM, Bob Ippolito wrote:
>>>
>>>> [snip]
>>>
>>>> That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
>>>> what the deal is with that?  Is a threaded Python ok because it has
>>>> the GIL, or should a non-threaded version be in Vim as well?  Or
>>>> maybe..  Vim's configure script should take a threaded Perl?
>>>>
>>>
>>> If someone can talk me through modifying the configure script, I'll
>>> try
>>> building it to accept the threaded perl, and see if it can do basic
>>> things or not.
>>
>>      Tweaking the configure script is not easy.  I prefer to leave
>> that
>> for people who understand autoconf.  As for perl, I assume there is a
>> reason not to link against a threaded version.  Bram?
>
> I do not know why Perl without threads is refused.  There is an
> explicit
> configure check for it, thus there must be a good reason.  But perhaps
> it was only for an old version of Perl?  It's also possible that
> if_perl.xs is not prepared for threading.
>
> You could edit src/auto/configure, search for "usethreads" and insert
> this below the "eval" command:
>
>  usethreads=undef
>
> Look out or compile errors and warnings in if_perl.c.

I did this; the only warning I saw was a warning for an unused
variable. At the end, near the ld steps, I was getting a message that
/usr/local/lib does not exist, but I do not think that harmed anything.

I ran the Vim.app that was created. It shows +perl, and I am able to
run :perl VIM::Msg("This is from Perl in Vim") and get the message
displayed. I think this means that the perl interface is working on
some very basic level. I do not have the expertise to test this more
fully.

I am now playing in the auto/configure script to see if the Tcl support
can be turned on. It was not finding the includes; I am trying to get
the include from /System/Library/Frameworks/Tcl.framework/Headers to be
recognized.

Onward and upwards...

Ken

--
<><      Ken Scott   ken@...   http://hobbes.optikos.net/~ken

         This is the day that the Lord has made;
         Let us rejoice and be glad in it          -- Psalm 118:24

Ken Scott wrote:

> > Benji Fisher wrote:
> >
> >> On Wed, Jan 14, 2004 at 10:07:32AM -0700, Ken Scott wrote:
> >>>
> >>> On Jan 14, 2004, at 8:39 AM, Bob Ippolito wrote:
> >>>
> >>>> [snip]
> >>>
> >>>> That's bizarre, because Python is threaded on OS X 10.3 ... I wonder
> >>>> what the deal is with that?  Is a threaded Python ok because it has
> >>>> the GIL, or should a non-threaded version be in Vim as well?  Or
> >>>> maybe..  Vim's configure script should take a threaded Perl?
> >>>
> >>> If someone can talk me through modifying the configure script, I'll
> >>> try building it to accept the threaded perl, and see if it can do
> >>> basic things or not.
> >>
> >>      Tweaking the configure script is not easy.  I prefer to leave
> >> that for people who understand autoconf.  As for perl, I assume
> >> there is a reason not to link against a threaded version.  Bram?
> >
> > I do not know why Perl without threads is refused.  There is an
> > explicit configure check for it, thus there must be a good reason.
> > But perhaps it was only for an old version of Perl?  It's also
> > possible that if_perl.xs is not prepared for threading.
> >
> > You could edit src/auto/configure, search for "usethreads" and insert
> > this below the "eval" command:
> >
> >  usethreads=undef
> >
> > Look out or compile errors and warnings in if_perl.c.
>
> I did this; the only warning I saw was a warning for an unused
> variable. At the end, near the ld steps, I was getting a message that
> /usr/local/lib does not exist, but I do not think that harmed anything.
>
> I ran the Vim.app that was created. It shows +perl, and I am able to
> run :perl VIM::Msg("This is from Perl in Vim") and get the message
> displayed. I think this means that the perl interface is working on
> some very basic level. I do not have the expertise to test this more
> fully.
>
> I am now playing in the auto/configure script to see if the Tcl support
> can be turned on. It was not finding the includes; I am trying to get
> the include from /System/Library/Frameworks/Tcl.framework/Headers to be
> recognized.
>
> Onward and upwards...

The patch that added the configure check for threads is 6.1.438, made by
Aron Griffis.  I'll include him in the copy list.

Aron, can you tell us how to test that a threaded Perl will break?
Could this depend on the Perl version somehow?  Perhaps the Perl on Mac
OSX 10.3 does work.

--
Not too long ago, cut and paste was done with scissors and glue...

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Hi,

Have other Mac Vim users noticed an issue with linewise yank/put?

In particular, after doing a yy and a following p, the put
isn't line-oriented, but rather occurs character-oriented
-- i.e. the text is inserted after the cursor character
rather than the cursor line.

This is inconsistent with other versions of Vim where the entire
yanked line is placed as a new line below the line where the
cursor is positioned.  I believe this linewise put behavior is
called out in the documentation when the yank is linewise.

Is this a known/acknowledged bug?  I didn't see it in the known
bugs list.

This occurs in the Mac OS X 10.3 vim6.2.181.tar.bz2 version
(and all previous versions to my knowledge).

Thanks,
Mike

> In particular, after doing a yy and a following p, the put
> isn't line-oriented, but rather occurs character-oriented
> -- i.e. the text is inserted after the cursor character
> rather than the cursor line.

I just tried this with 6.181 and it worked fine. How did you
notice the difference? All I did was do yyp with the cursor
in the middle of the line. I also tried doing the p in the
middle of a different line, but got the expected result (ie:
a line-wise put)

Do you have an exact test (ie: test file and instructions on
what you do to produce the bug?)

Steve

Stephen Riehm wrote:

>> In particular, after doing a yy and a following p, the put
>> isn't line-oriented, but rather occurs character-oriented
>> -- i.e. the text is inserted after the cursor character
>> rather than the cursor line.
>
>
> I just tried this with 6.181 and it worked fine. How did you
> notice the difference? All I did was do yyp with the cursor
> in the middle of the line. I also tried doing the p in the
> middle of a different line, but got the expected result (ie:
> a line-wise put)
>
> Do you have an exact test (ie: test file and instructions on
> what you do to produce the bug?)
>
> Steve
>

I've tracked it down to having this line in my .vimrc

	 set clipboard=unnamed

Without that line everything works fine; with it, I notice
the behavior mentioned.  The interesting thing is that I
also have this line in the vimrc on my Unix systems and
don't have this problem.

Mike

Bram Moolenaar wrote: [Fri Jan 16 2004, 01:56:47PM EST]
> The patch that added the configure check for threads is 6.1.438, made by
> Aron Griffis.  I'll include him in the copy list.

Last time I tested this was 6.1.411 with Perl 5.8.0.  It blew up with
link errors like this:

       gcc  -L/usr/X11R6/lib  -rdynamic   -L/usr/local/lib  -o vim
objects/buffer.o objects/charset.o objects/diff.o objects/digraph.o
objects/edit.o objects/eval.o objects/ex_cmds.o objects/ex_cmds2.o
objects/ex_docmd.o objects/ex_getln.o objects/fileio.o objects/fold.o
objects/getchar.o objects/if_cscope.o objects/if_xcmdsrv.o objects/main.o
objects/mark.o objects/memfile.o objects/memline.o objects/menu.o
objects/message.o objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o
objects/normal.o objects/ops.o objects/option.o objects/os_unix.o
objects/pathdef.o objects/quickfix.o objects/regexp.o objects/screen.o
objects/search.o objects/syntax.o  objects/tag.o objects/term.o objects/ui.o
objects/undo.o objects/window.o  objects/if_perl.o objects/if_perlsfio.o
objects/if_python.o objects/py_config.o objects/version.o    -lSM -lICE -lXpm
-lXt -lX11 -lSM -lICE -lncurses   -lgpm -ldl  -rdynamic  -L/usr/local/lib
/usr/lib/perl5/5.8.0/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.0/i686-linux-thread-multi/CORE -lperl -lpthread -lnsl -ldl
-lm -lcrypt -lutil -L/usr/lib/python2.2/config -lpython2.2 -ldl -lpthread -lutil
-lm -Xlinker -export-dynamic

       objects/if_perl.o(.text+0x21): In function `ex_perl':
       : undefined reference to `Perl_Gthr_key_ptr'
       objects/if_perl.o(.text+0x33): In function `ex_perl':
       : undefined reference to `Perl_Tstack_sp_ptr'

The full build log is at

     http://bugs.gentoo.org/attachment.cgi?id=10073&action=view
     http://bugs.gentoo.org/show_bug.cgi?id=18555

It's possible that this works now with threaded Perl.  I suppose that if
it links it will probably work.  I will give it a try and follow up.

Aron

[snipped to be accepted by the vim-mac ML]

I just tested.  I have perl-5.8.2 installed and I'm testing 6.2.140
(with a workaround to allow threaded perl).  I get the following output:

gcc  -L/usr/X11R6/lib  -rdynamic   -L/usr/local/lib  -o vim objects/buffer.o
objects/charset.o objects/diff.o objects/digraph.o objects/edit.o objects/eval.o
objects/ex_cmds.o objects/ex_cmds2.o objects/ex_docmd.o objects/ex_eval.o
objects/ex_getln.o objects/fileio.o objects/fold.o objects/getchar.o 
objects/if_cscope.o objects/if_xcmdsrv.o objects/main.o objects/mark.o
objects/memfile.o objects/memline.o objects/menu.o objects/message.o
objects/misc1.o objects/misc2.o objects/move.o objects/mbyte.o objects/normal.o
objects/ops.o objects/option.o objects/os_unix.o objects/pathdef.o
objects/quickfix.o objects/regexp.o objects/screen.o objects/search.o
objects/syntax.o  objects/tag.o objects/term.o objects/ui.o objects/undo.o
objects/window.o objects/gui.o objects/gui_gtk.o objects/gui_gtk_x11.o
objects/pty.o objects/gui_gtk_f.o objects/gui_beval.o objects/if_perl.o
objects/if_perlsfio.o      objects/netbeans.o  objects/version.o  
-Wl,--export-dynamic -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl
-lglib-2.0   -lSM -lICE -lXpm -lXt -lX11 -lSM -lICE -lncurses -lgpm -ldl 
-rdynamic  -L/usr/local/lib
/usr/lib/perl5/5.8.2/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/usr/lib/perl5/5.8.2/i686-linux-thread-multi/CORE -lperl -ldl -lutil -lc
objects/if_perl.o(.text+0x5c): In function `perl_init':
/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_perl.xs:370: undefined reference
to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x66):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_perl\
.xs:370: undefined reference to `pthread_getspecific'
objects/if_perl.o(.text+0x156): In function `newWINrv':
/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_perl.xs:467: undefined reference
to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x160):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `pthread_getspecific'
objects/if_perl.o(.text+0x199):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x1a3):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `pthread_getspecific'
objects/if_perl.o(.text+0x1cb):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x1d5):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `pthread_getspecific'
objects/if_perl.o(.text+0x1f8):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x202):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `pthread_getspecific'
objects/if_perl.o(.text+0x222):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `Perl_Gthr_key_ptr'
objects/if_perl.o(.text+0x22c):/var/tmp/portage/vim-6.2-r5/work/vim62/src/if_per\
l.xs:467: undefined reference to `pthread_getspecific'
...

Aron Griffis wrote:

> I just tested.  I have perl-5.8.2 installed and I'm testing 6.2.140
> (with a workaround to allow threaded perl).  I get the following output:

Juan Fuentes suggested that it should work fine without threads and with
the newer thread system, but not with Perl 5.5 threads.  Later Perl
versions can still be build with the 5.5 threads.

I now have the following configure check for Perl threads.  Please try
this with various versions of Perl.


*** ../vim-6.2.181/src/auto/configure Mon Dec 29 21:00:25 2003
--- src/auto/configure Sat Jan 17 12:49:31 2004
***************
*** 1570,1579 ****

     if test "X$vi_cv_path_perl" != "X"; then
       echo $ac_n "checking Perl version""... $ac_c" 1>&6
! echo "configure:1480: checking Perl version" >&5
       if $vi_cv_path_perl -e 'require 5.003_01' >/dev/null 2>/dev/null; then
        eval `$vi_cv_path_perl -V:usethreads`
        if test "X$usethreads" = "XUNKNOWN" -o "X$usethreads" = "Xundef"; then
         echo "$ac_t""OK" 1>&6
         eval `$vi_cv_path_perl -V:shrpenv`
         if test "X$shrpenv" = "XUNKNOWN"; then # pre 5.003_04
--- 1570,1595 ----

     if test "X$vi_cv_path_perl" != "X"; then
       echo $ac_n "checking Perl version""... $ac_c" 1>&6
! echo "configure:1574: checking Perl version" >&5
       if $vi_cv_path_perl -e 'require 5.003_01' >/dev/null 2>/dev/null; then
        eval `$vi_cv_path_perl -V:usethreads`
        if test "X$usethreads" = "XUNKNOWN" -o "X$usethreads" = "Xundef"; then
+        badthreads=no
+      else
+        if $vi_cv_path_perl -e 'require 5.6.0' >/dev/null 2>/dev/null; then
+ 	 eval `$vi_cv_path_perl -V:use5005threads`
+ 	 if test "X$use5005threads" = "XUNKNOWN" -o "X$use5005threads" = "Xundef";
then
+ 	   badthreads=no
+ 	 else
+ 	   badthreads=yes
+ 	   echo "$ac_t"">>> Perl > 5.6 with 5.5 threads cannot be used <<<" 1>&6
+ 	 fi
+        else
+ 	 badthreads=yes
+ 	 echo "$ac_t"">>> Perl 5.5 with threads cannot be used <<<" 1>&6
+        fi
+      fi
+      if test $badthreads = no; then
         echo "$ac_t""OK" 1>&6
         eval `$vi_cv_path_perl -V:shrpenv`
         if test "X$shrpenv" = "XUNKNOWN"; then # pre 5.003_04
***************
*** 1602,1609 ****
   #define FEAT_PERL 1
   EOF

-      else
-       echo "$ac_t"">>> Perl with threads cannot be used <<<" 1>&6
        fi
       else
         echo "$ac_t"">>> too old; need Perl version 5.003_01 or later <<<" 1>&6
--- 1618,1623 ----

--
FATHER:    Who are you?
PRINCE:    I'm ... your son ...
FATHER:    Not you.
LAUNCELOT: I'm ... er ... Sir Launcelot, sir.
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Mac Vim users:

      Thanks to Peter Cucka (10.2) and Ken Scott (10.3), we have new
versions of Vim.app posted at

http://macvim.swdev.org/OSX/#Downloading

10.3:  Currently, the most recent binary is the one I previously
announced; no problems have been reported.  Ken is working on enabling
perl, tcl, and (most problematic, I think) ruby in addition to python.
When he posts a version with some or all of these, I would appreciate
testing and report.

10.2:  The latest version is 10.2.181 with perl support.  This is the
first version we have posted that includes the new transparency and
antialias patches.  I am no longer running 10.2, so I cannot test this
myself.  I do not expect any problems, but I would appreciate feedback.

      There is still one issue with the antialias patch.  So far, I seem
to be the only one who sees this problem, and Peter has not been able to
reproduce it.  The easiest way to see it is

:set antialias
:set antialias?

On the second line, there will be a noticeable space between the "?" and
the cursor position.  Hitting <BS> does not erase the displaye "?" but
does have the effect of removing it.  If no one else sees this problem,
I guess it is something weird about my system.

					 --Benji Fisher

Just tried to build the latest version of Vim, but the build failed:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MAC -arch ppc -fno-common -
fpascal-strings -Wall -Wno-unknown-pragmas -mdynamic-no-pic -pipe -I. -
Iproto -no-cpp-precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -
no-cpp-precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-
precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp  -O2 -fno-
strength-reduce -Wall    -I/sw/include/python2.3 -pthread    -o objects/
ex_cmds.o ex_cmds.c
gcc: unrecognized option `-pthread'
ex_cmds.c: In function `do_filter':
ex_cmds.c:882: error: `CPO_REMMARK' undeclared (first use in this function)
ex_cmds.c:882: error: (Each undeclared identifier is reported only once
ex_cmds.c:882: error: for each function it appears in.)
make: *** [objects/ex_cmds.o] Error 1

I had applied the HitReturn and the transparency patches, but not the
antialiasing patch.

Emily

Emily Jackson wrote:

> Just tried to build the latest version of Vim, but the build failed:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MAC -arch ppc -fno-common -
> fpascal-strings -Wall -Wno-unknown-pragmas -mdynamic-no-pic -pipe -I. -
> Iproto -no-cpp-precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -
> no-cpp-precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-
> precomp -DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
> DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
> DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp -
> DMACOS_X_UNIX -I/Developer/Headers/FlatCarbon -no-cpp-precomp  -O2 -fno-
> strength-reduce -Wall    -I/sw/include/python2.3 -pthread    -o objects/
> ex_cmds.o ex_cmds.c
> gcc: unrecognized option `-pthread'
> ex_cmds.c: In function `do_filter':
> ex_cmds.c:882: error: `CPO_REMMARK' undeclared (first use in this function)
> ex_cmds.c:882: error: (Each undeclared identifier is reported only once
> ex_cmds.c:882: error: for each function it appears in.)
> make: *** [objects/ex_cmds.o] Error 1
>
> I had applied the HitReturn and the transparency patches, but not the
> antialiasing patch.

I forgot to include a patch for option.h in 6.2.190.  Sorry!
Another patch coming up...

--
WOMAN:   King of the who?
ARTHUR:  The Britons.
WOMAN:   Who are the Britons?
ARTHUR:  Well, we all are. we're all Britons and I am your king.
                                   The Quest for the Holy Grail (Monty Python)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

Benji Fisher wrote:

>      Thanks to Peter Cucka (10.2) and Ken Scott (10.3), we have new
> versions of Vim.app posted at
>
> http://macvim.swdev.org/OSX/#Downloading

I tried out the 10.2 version (VimJag.tar.gz2) with Perl, Python and CJK.
This appears to work fine on my 10.2 system.

I moved Vim.app to my desktop, but discovered that the runtime files
then can't be found.  Previously they were inside Vim.app (called
runtime), which sounds logical to me.  Is there a reason to put the
runtime files a directory higher and call them "vim62"?  That spoils the
idea that the Vim application can be moved around with all the necessary
files.

I did not see a version for 10.2 with antialias and transparency
support...

It seems vim6.1.184.tar.gz actually contains Vim 6.2.056.

--
Seen on the back of a biker's vest: If you can read this, my wife fell off.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Mon, Jan 19, 2004 at 03:13:47PM +0100, Bram Moolenaar wrote:
>
> Benji Fisher wrote:
>
> >      Thanks to Peter Cucka (10.2) and Ken Scott (10.3), we have new
> > versions of Vim.app posted at
> >
> > http://macvim.swdev.org/OSX/#Downloading
>
> I tried out the 10.2 version (VimJag.tar.gz2) with Perl, Python and CJK.
> This appears to work fine on my 10.2 system.
>
> I moved Vim.app to my desktop, but discovered that the runtime files
> then can't be found.  Previously they were inside Vim.app (called
> runtime), which sounds logical to me.  Is there a reason to put the
> runtime files a directory higher and call them "vim62"?  That spoils the
> idea that the Vim application can be moved around with all the necessary
> files.

      That's an older version.  I suppose I should "touch" the files in
order of how old they really are; a few days ago, I moved the files
around on the server, and they are sorted by those "modification times."

> I did not see a version for 10.2 with antialias and transparency
> support...

      Try this one:
http://macvim.swdev.org/OSX/files/binaries/vim6.2.181.huge-perl-py.tar.bz2

> It seems vim6.1.184.tar.gz actually contains Vim 6.2.056.

      Does it run at all on OS X 10.2?  If not, then it probably does run
on 10.1 and I should change the name and comments.  If not, then I can
just delete it.

					 --Benji Fisher

Benji Fisher wrote:

> > >      Thanks to Peter Cucka (10.2) and Ken Scott (10.3), we have new
> > > versions of Vim.app posted at
> > >
> > > http://macvim.swdev.org/OSX/#Downloading
> >
> > I tried out the 10.2 version (VimJag.tar.gz2) with Perl, Python and CJK.
> > This appears to work fine on my 10.2 system.
> >
> > I moved Vim.app to my desktop, but discovered that the runtime files
> > then can't be found.  Previously they were inside Vim.app (called
> > runtime), which sounds logical to me.  Is there a reason to put the
> > runtime files a directory higher and call them "vim62"?  That spoils the
> > idea that the Vim application can be moved around with all the necessary
> > files.
>
>      That's an older version.  I suppose I should "touch" the files in
> order of how old they really are; a few days ago, I moved the files
> around on the server, and they are sorted by those "modification times."

It helps a lot if someone can download the right version without
guessing!  Perhaps you could split the list into a "recommended, will
always work" section for 10.1, 10.2 and 10.3, and another section for
fancy versions that might not always work or haven't been verified yet.

> > I did not see a version for 10.2 with antialias and transparency
> > support...
>
>      Try this one:
> http://macvim.swdev.org/OSX/files/binaries/vim6.2.181.huge-perl-py.tar.bz2

OK, that one works fine.  Antialias works, transparency too (although it
looks weird, try ":set transparency=1" :-).  Python and Perl work.
Looks like this should be the recommended version for 10.2.

Shall I include the antialias patch in the mainstream version?

One thing that I'm missing while trying this out is a menu to select a
font.

> > It seems vim6.1.184.tar.gz actually contains Vim 6.2.056.
>
>      Does it run at all on OS X 10.2?  If not, then it probably does run
> on 10.1 and I should change the name and comments.  If not, then I can
> just delete it.

I ran it, thus it works on 10.2.

--
"It's so simple to be wise.  Just think of something stupid to say
and then don't say it."        -- Sam Levenson

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

On Tue, Jan 20, 2004 at 12:11:40PM +0100, Bram Moolenaar wrote:
>
> Benji Fisher wrote:
>
> It helps a lot if someone can download the right version without
> guessing!  Perhaps you could split the list into a "recommended, will
> always work" section for 10.1, 10.2 and 10.3, and another section for
> fancy versions that might not always work or haven't been verified yet.

      I will break it up into 10.1, 10.2, 10.3.  Judging from another
letter in my inbox this morning, putting this information into the
comments in the table is not clear enough. :-(  I think I will try
putting "stable" or "experimental" into the first line of the comments.
If more people download the experimental versions, we get more testing.
;)

> > > I did not see a version for 10.2 with antialias and transparency
> > > support...
> >
> >      Try this one:
> > http://macvim.swdev.org/OSX/files/binaries/vim6.2.181.huge-perl-py.tar.bz2
>
> OK, that one works fine.  Antialias works, transparency too (although it
> looks weird, try ":set transparency=1" :-).  Python and Perl work.
> Looks like this should be the recommended version for 10.2.

      OK, I will list it as "stable."  It does not have CJK support.  But
maybe with +iconv that is no longer an issue?  I need some guidance
here.

> Shall I include the antialias patch in the mainstream version?

      I think so.  I am the only one to have any problems with it.  As
long as the default is 'noantialias', it will not make any trouble OOTB.
If it is standard, then maybe we will find someone else with the same
problem I have, and then we can figure out what oddity our systems
share.

> One thing that I'm missing while trying this out is a menu to select a
> font.

      This is #8 on http://macvim.swdev.org/OSX/#Bugs .

> > > It seems vim6.1.184.tar.gz actually contains Vim 6.2.056.
> >
> >      Does it run at all on OS X 10.2?  If not, then it probably does run
> > on 10.1 and I should change the name and comments.  If not, then I can
> > just delete it.
>
> I ran it, thus it works on 10.2.

      Then I probably lost the version for 10.1.  I have not had any
complaints about this, so maybe everyone who wants Vim.app has upgraded
to at least OS X.ii.

					 --Benji Fisher

Benji Fisher wrote:

>      OK, I will list it as "stable."  It does not have CJK support.  But
> maybe with +iconv that is no longer an issue?  I need some guidance
> here.

I think only the 10.3 version has +iconv.  At least the 10.2 version I
was testing doesn't support iconv.

> > Shall I include the antialias patch in the mainstream version?
>
>      I think so.  I am the only one to have any problems with it.  As
> long as the default is 'noantialias', it will not make any trouble OOTB.
> If it is standard, then maybe we will find someone else with the same
> problem I have, and then we can figure out what oddity our systems
> share.

OK, where can I find this patch?

--
Advice to worms:  Sleep late.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        Sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\              Project leader for A-A-P -- http://www.A-A-P.org        ///
  \\\  Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html  ///

I think it should be possible to make only the buffer area of the Vim
window transparent.  As it stands now, even the title bar is
transparent.  Terminal.app, for one, does this correctly.  I can look
and see if I can figure out how to do this, but I'm sure there's someone
out there more able than I.

--
rjbs