Skip to search.

Breaking News Visit Yahoo! News for the latest.

×Close this window

vim-mac · Vim (Vi IMproved) text editor Macintosh list

The Yahoo! Groups Product Blog

Check it out!

Group Information

? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Hear how Yahoo! Groups has changed the lives of others. Take me there.

Messages

Advanced
Messages Help
Messages 1282 - 1396 of 13685   Oldest  |  < Older  |  Newer >  |  Newest
Messages: Show Message Summaries Sort by Date ^  
#1282 From: Benji Fisher <benji@...>
Date: Tue Jan 20, 2004 2:41 pm
Subject: Re: updated Vim.app binaries (Jaguar and Panther)
benji@...
Send Email Send Email
 
On Tue, Jan 20, 2004 at 02:07:09PM +0100, Bram Moolenaar wrote:
>
> 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.

      Right, I will keep the version for 10.2 with CJK support.  I just
rearranged the listing.

Ken Scott and Peter Cucka:

      Please upload new binaries to the new subfolders.  I think it will
be clear.

> > > 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?

      I will send you a copy directly.  In general, I list the
experimental patches at http://macvim.swdev.org/OSX/#configure

					 --Benji Fisher

#1283 From: Bob Ippolito <bob@...>
Date: Tue Jan 20, 2004 3:32 pm
Subject: Can we have separate operating system windows?
bob@...
Send Email Send Email
 
Is it at all possible to have more than one vim window in the same
process, so that it acts like a standard Mac app (one dock icon, cmd-~
window shuffling, etc)?

I've really liked splitting a text console beyond the usual status bar
and input line, unless I am using a textmode terminal (which hasn't
happened in a LONG time).  I'm used to using lots of Vim instances
inside lots of Terminal windows, but I'd like to use some of the
additional features that Carbon Vim has in GUI mode.

I'd also love if the 'odoc' event opened a new one of these windows
instead of replacing the current session (this should be configurable,
of course).

-bob

#1284 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 20, 2004 3:36 pm
Subject: Re: transparency scope
Bram@...
Send Email Send Email
 
Ricardo Signes wrote:

> 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.

I think only the background should be transparent, not the text.  Then
":set transparency=1" would still show the text, instead of make it all
disappear.  Don't know if this is possible...

--
If your life is a hard drive,
Christ can be your backup.

  /// 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  ///

#1285 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 20, 2004 5:11 pm
Subject: Re: Can we have separate operating system windows?
Bram@...
Send Email Send Email
 
Bob Ippolito wrote:

> Is it at all possible to have more than one vim window in the same
> process, so that it acts like a standard Mac app (one dock icon, cmd-~
> window shuffling, etc)?
>
> I've really liked splitting a text console beyond the usual status bar
> and input line, unless I am using a textmode terminal (which hasn't
> happened in a LONG time).  I'm used to using lots of Vim instances
> inside lots of Terminal windows, but I'd like to use some of the
> additional features that Carbon Vim has in GUI mode.
>
> I'd also love if the 'odoc' event opened a new one of these windows
> instead of replacing the current session (this should be configurable,
> of course).

No, currently this is not possible.  You can start multiple instances of
Vim, and use the viminfo stuff to exchange registers et al.  But that
doesn't do it all.

Supporting multiple toplevel windows has been a todo item for some time.
Main problems to take care of are how to handle the multiple command
lines and avoiding the GUI version drifting away from the console
version.

--
Yesterday is history.
Tomorrow is a mystery.
Today is a gift.
That's why it is called 'present'.

  /// 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  ///

#1286 From: Bob Ippolito <bob@...>
Date: Tue Jan 20, 2004 5:26 pm
Subject: Re: Can we have separate operating system windows?
bob@...
Send Email Send Email
 
On Jan 20, 2004, at 12:11 PM, Bram Moolenaar wrote:

> Bob Ippolito wrote:
>
>> Is it at all possible to have more than one vim window in the same
>> process, so that it acts like a standard Mac app (one dock icon, cmd-~
>> window shuffling, etc)?
>>
>> I've really liked splitting a text console beyond the usual status bar
>> and input line, unless I am using a textmode terminal (which hasn't
>> happened in a LONG time).  I'm used to using lots of Vim instances
>> inside lots of Terminal windows, but I'd like to use some of the
>> additional features that Carbon Vim has in GUI mode.
>>
>> I'd also love if the 'odoc' event opened a new one of these windows
>> instead of replacing the current session (this should be configurable,
>> of course).
>
> No, currently this is not possible.  You can start multiple instances
> of
> Vim, and use the viminfo stuff to exchange registers et al.  But that
> doesn't do it all.

ick :)

> Supporting multiple toplevel windows has been a todo item for some
> time.
> Main problems to take care of are how to handle the multiple command
> lines and avoiding the GUI version drifting away from the console
> version.

Well, the user only has one set of input devices.. you could "context
switch" based upon which one gets activated.  I have not looked at Vim
source at all so I really don't know what the right way to do it would
be.

By GUI version drifting away from the console version, do you mean
source code or what?

-bob

#1287 From: Ricardo SIGNES <rjbs-vim-mac@...>
Date: Tue Jan 20, 2004 6:13 pm
Subject: Re: transparency scope
rjbs-vim-mac@...
Send Email Send Email
 
* Bram Moolenaar <Bram@...> [2004-01-20T10:36:51]
> > 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.
>
> I think only the background should be transparent, not the text.  Then
> ":set transparency=1" would still show the text, instead of make it all
> disappear.  Don't know if this is possible...

Absolutely.  That's what Terminal.app does...

--
rjbs

#1288 From: Ricardo SIGNES <rjbs-vim-mac@...>
Date: Tue Jan 20, 2004 6:14 pm
Subject: Re: Can we have separate operating system windows?
rjbs-vim-mac@...
Send Email Send Email
 
* Bram Moolenaar <Bram@...> [2004-01-20T12:11:12]
> Bob Ippolito wrote:
> > Is it at all possible to have more than one vim window in the same
> > process, so that it acts like a standard Mac app (one dock icon, cmd-~
> > window shuffling, etc)?
>
> No, currently this is not possible.  You can start multiple instances of
> Vim, and use the viminfo stuff to exchange registers et al.  But that
> doesn't do it all.

Can this actually be done with Carbon gVim?

--
rjbs

#1289 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 20, 2004 6:24 pm
Subject: Re: Can we have separate operating system windows?
Bram@...
Send Email Send Email
 
Bob Ippolito wrote:

> > Supporting multiple toplevel windows has been a todo item for some
> > time.
> > Main problems to take care of are how to handle the multiple command
> > lines and avoiding the GUI version drifting away from the console
> > version.
>
> Well, the user only has one set of input devices.. you could "context
> switch" based upon which one gets activated.  I have not looked at Vim
> source at all so I really don't know what the right way to do it would
> be.

You could type a few words in the command line, then go to another Vim
window and execute a command there.  This means there are multiple
command lines to take care of.  Multiple states as well (one window in
Insert mode, another editing the command line).

> By GUI version drifting away from the console version, do you mean
> source code or what?

Displaying text in on the screen (toplevel window) is a large part of
the code.  When this differs between the GUI and the console version
large parts of code could be duplicated.  More code, more bugs, more
maintenance...

--
MESKIMEN'S LAW
     There's never time to do it right, but always time to do it over.

  /// 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  ///

#1290 From: Bob Ippolito <bob@...>
Date: Tue Jan 20, 2004 6:42 pm
Subject: Re: Can we have separate operating system windows?
bob@...
Send Email Send Email
 
On Jan 20, 2004, at 1:24 PM, Bram Moolenaar wrote:

>
> Bob Ippolito wrote:
>
>>> Supporting multiple toplevel windows has been a todo item for some
>>> time.
>>> Main problems to take care of are how to handle the multiple command
>>> lines and avoiding the GUI version drifting away from the console
>>> version.
>>
>> Well, the user only has one set of input devices.. you could "context
>> switch" based upon which one gets activated.  I have not looked at Vim
>> source at all so I really don't know what the right way to do it would
>> be.
>
> You could type a few words in the command line, then go to another Vim
> window and execute a command there.  This means there are multiple
> command lines to take care of.  Multiple states as well (one window in
> Insert mode, another editing the command line).

Three cheers for global variables :)

>> By GUI version drifting away from the console version, do you mean
>> source code or what?
>
> Displaying text in on the screen (toplevel window) is a large part of
> the code.  When this differs between the GUI and the console version
> large parts of code could be duplicated.  More code, more bugs, more
> maintenance...

Makes it sound like I might just be better off writing another editor
that acts enough like Vim to make me happy.  *sigh*

-bob

#1291 From: Eckehard Berns <ecki@...>
Date: Tue Jan 20, 2004 6:56 pm
Subject: Re: transparency scope
ecki@...
Send Email Send Email
 
>>> 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.
>>
>> I think only the background should be transparent, not the text.  Then
>> ":set transparency=1" would still show the text, instead of make it
>> all
>> disappear.  Don't know if this is possible...
>
> Absolutely.  That's what Terminal.app does...

I did this once in Cocoa, but I don't know if it is possible in this
limited Carbon version (with limited I mean avoiding to much
MacOSX-ness to allow for backward compatibility with MacOS <=9). I'm
completely new to Carbon programming but would do some testing if
nobody else already knows how to achieve this.

--
Eckehard Berns

#1292 From: Eckehard Berns <ecki@...>
Date: Tue Jan 20, 2004 7:42 pm
Subject: experimental mouse wheel patch
ecki@...
Send Email Send Email
 
Hi!

I have tried to make the mouse wheel work natively (e.g. without
USB overdrive) in Vim for Mac OS X. I'm new to Carbon programming
and haven't hacked Vim before.  So I have a few questions on this
patch. First of all I don't know if there are any resources being
freed on program exit. Second I don't know to much about the mixture
of the Event Manager with the Carbon Event Manager. I just followed
the few guidelines in the Apple Developer Documentation. Also I
don't know whether the bogus event I post will wake up WaitNextEvent
on all versions of Mac OS X.

You could also argument that the wheel should be handled in a window
event handler as opposed to the application event handler approach
I took. At the moment you don't have to place the mouse pointer
above Vim's window to make the scroll wheel work. I don't know what
other people think about this.

It would be nice to here whether this patch works for other people
than me. And maybe someone has answers to some of my questions or
can correct my code where I'm mistaken.

*** ../vim62.195/src/gui_mac.c Tue Jan 20 19:39:56 2004
--- src/gui_mac.c Tue Jan 20 20:06:02 2004
***************
*** 82,87 ****
--- 82,98 ----
   # endif
   #endif

+ #undef USE_MOUSEWHEEL
+ #if defined(MACOS_X) && defined(USE_CARBONIZED)
+ # define USE_MOUSEWHEEL
+ /* TODO: do we need to free these resources later? Where? */
+ static EventHandlerUPP mouseWheelHandlerUPP;
+ static EventHandlerRef mouseWheelHandlerRef;
+ /* TODO: do we need to break out of the WaitNewEventWrp loop or is the
+  * bogus event enough to update the window instantly? */
+ static int had_mouse_wheel = 0;
+ #endif
+
   /* Debugging feature: start Vim window OFFSETed */
   #undef USE_OFFSETED_WINDOW

***************
*** 2231,2236 ****
--- 2242,2315 ----
         (MOUSE_RELEASE, thePoint.h, thePoint.v, FALSE, vimModifiers);
   }

+ #ifdef USE_MOUSEWHEEL
+ static pascal OSStatus
+ gui_mac_mouse_wheel(EventHandlerCallRef nextHandler, EventRef theEvent,
+     void *data)
+ {
+     EventRef bogusEvent;
+     Point point;
+     UInt32 mod;
+     SInt32 delta;
+     int_u vim_mod;
+
+     /*
+      * TODO: can that ever happen? In theory allow_scrollbar is TRUE
+      * throughout the WaitNextEvent loop and the callback could only
+      * happen when the application called WaitNextEvent first
+      */
+     if (!allow_scrollbar)
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamMouseWheelDelta,
+  typeSInt32, NULL, sizeof(SInt32), NULL, &delta))
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamMouseLocation,
+  typeQDPoint, NULL, sizeof(Point), NULL, &point))
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamKeyModifiers,
+  typeUInt32, NULL, sizeof(UInt32), NULL, &mod))
+  goto bail;
+
+     vim_mod = 0;
+     if (mod & shiftKey)
+  vim_mod |= MOUSE_SHIFT;
+     if (mod & controlKey)
+  vim_mod |= MOUSE_CTRL;
+     if (mod & optionKey)
+  vim_mod |= MOUSE_ALT;
+
+     if (noErr != CreateEvent(NULL, kEventClassMouse, kEventMouseMoved, 0,
+  kEventAttributeNone, &bogusEvent))
+  goto bail;
+     if (noErr != PostEventToQueue(GetMainEventQueue(), bogusEvent,
+  kEventPriorityLow))
+  goto bail;
+
+     gui_send_mouse_event((delta > 0) ? MOUSE_4 : MOUSE_5,
+  point.h, point.v, FALSE, vim_mod);
+     /*
+      * TODO: do I need to send the MOUSE_RELEASE after a MOUSE_4 event?
+      * And if so, will the bogus mUp event cause this MOUSE_RELEASE for me?
+      */
+     /* gui_send_mouse_event(MOUSE_RELEASE, point.h, point.v,
+  FALSE, vim_mod); */
+     /* TODO: see definition of had_mouse_wheel */
+     had_mouse_wheel = 1;
+
+     return noErr;
+
+   bail:
+     /*
+      * when we fail give any additional callback handler a chance to perform
+      * it's actions
+      */
+     return CallNextEventHandler(nextHandler, theEvent);
+ }
+ #endif /* defined(USE_MOUSEWHEEL) */
+
   #if 0

   /*
***************
*** 2666,2671 ****
--- 2745,2753 ----
   #ifdef USE_CTRLCLICKMENU
       long gestalt_rc;
   #endif
+ #ifdef USE_MOUSEWHEEL
+     EventTypeSpec   eventTypeSpec;
+ #endif
   #if 1
       InitCursor();

***************
*** 2794,2799 ****
--- 2876,2893 ----
       gui.scrollbar_height = gui.scrollbar_width = 15; /* cheat 1 overlap */
       gui.border_offset = gui.border_width = 2;

+ #ifdef USE_MOUSEWHEEL
+     eventTypeSpec.eventClass = kEventClassMouse;
+     eventTypeSpec.eventKind = kEventMouseWheelMoved;
+     /* TODO: do we need to free these handlers at exit? Where? */
+     mouseWheelHandlerUPP = NewEventHandlerUPP(gui_mac_mouse_wheel);
+     if (noErr != InstallApplicationEventHandler(mouseWheelHandlerUPP, 1,
+  &eventTypeSpec, NULL, &mouseWheelHandlerRef)) {
+  mouseWheelHandlerRef = NULL;
+  DisposeEventHandlerUPP(mouseWheelHandlerUPP);
+     }
+ #endif /* defined(USE_MOUSEWHEEL) */
+
       /* TODO: Load bitmap if using TOOLBAR */
       return OK;
   }
***************
*** 3546,3551 ****
--- 3640,3652 ----
  		 return OK;
  	     }
  	 }
+ #ifdef USE_MOUSEWHEEL
+  /* is this needed? see definition of had_mouse_wheel */
+  if (had_mouse_wheel) {
+ 	    had_mouse_wheel = 0;
+ 	    break;
+  }
+ #endif
  	 currentTick = TickCount();
       }
       while ((wtime == -1) || ((currentTick - entryTick) < 60*wtime/1000));

--
Eckehard Berns

#1293 From: Eckehard Berns <ecki@...>
Date: Fri Jan 23, 2004 8:12 pm
Subject: Bug in definition of vk_Delete in gui_mac.c?
ecki@...
Send Email Send Email
 
Hi!

I was always wondering why I couldn't interrupt a compile run or
spawned process in the GUI Version of Vim for Mac OS X. While
debugging the problem I got to a #define for vk_Delete, which later
is used in special_keys and defined as 0x08. Might it be that the
person inserting this code tried to match the char code (ASCII 8
-> Backspace) instead the sym code (which seems to be 51 or 0x33--at
least on MacOS X). On my system the key C has the key sym 8 and
therefor will be modified to result in the char sequence for
backspace. This doesn't show up in normal editing, because the
got_int global is set and the input queue will be cleared anyway.
But when Vim spawned a shell or another command got_int seems to
be ignored and the interrupt signal is sent only upon reading the
char 0x03 in the input queue.

Since I have no idea whether this code would break classic Mac OS
versions of Vim I prepared a small patch that only skips vk_Delete
from being listed in the special_keys when compiling on Mac OS X.
But I do think that the correct thing to do would be to either
remove vk_Delete completely or to define it as 0x33.

*** ../vim62.195/src/gui_mac.c Tue Jan 20 19:39:56 2004
--- src/gui_mac.c Fri Jan 23 20:36:23 2004
***************
*** 236,241 ****
--- 236,242 ----
   #define vk_Space 0x31 /* -> 20 */
   #define vk_Tab  0x30 /* -> 09 */
   #define vk_Return 0x24 /* -> 0D */
+ /* why this? key_sym 8 is the key "c" on MacOS X */
   #define vk_Delete 0X08 /* -> 08 BackSpace */

   #define vk_Help  0x72 /* -> 05 */
***************
*** 293,299 ****
--- 294,302 ----

   /*  {XK_Help,  '%', '1'}, */
   /*  {XK_Undo,  '&', '8'}, */
+ #ifndef MACOS_X
       {vk_Delete,  'k', 'b'},
+ #endif
       {vk_Insert,  'k', 'I'},
       {vk_FwdDelete, 'k', 'D'},
       {vk_Home,  'k', 'h'},

--
Eckehard Berns

#1294 From: Eckehard Berns <ecki@...>
Date: Sat Jan 24, 2004 2:20 pm
Subject: Re: transparency scope
ecki@...
Send Email Send Email
 
After a lot of searching I had a bit of luck with the transparency for
the GUI Version of Vim for Mac OS X. I made a diff to Vim 6.2.195 that
enables transparency for the background of the editing version of the
window only. Use it like the original transpareny:

Completely opaque (bypassing my routines to keep is speedy):
set transparency=255

Most transparency:
set transparency=1

If you use a transparency value other than 255 (or 0) my handlers will
snap in and the drawing speed will decrease a lot. Every time a string
is drawn I need to build a CGContext for the current Port, transform the
coordinates, setup the fill color and finally flush and destroy the
CGContext. That's extremly slow. I will experiment with a parrallel
CGContext for the VimWindow which can live besides the QuickDraw port,
that I don't need to flush every time. But I'd like to know if this
patch works for other poeple besides me. There are some issues with the
shadow generated by Mac OS X (which are to some extend reproducable in
Terminal.app) and the part under the scrollbar that get's reviealed when
resizing the window. Everything else works fine for me.

Here's the patch for a vanilla 6.2.195:

diff -cr ../vim62.195/src/gui_mac.c ./src/gui_mac.c
*** ../vim62.195/src/gui_mac.c Tue Jan 20 19:39:56 2004
--- ./src/gui_mac.c Sat Jan 24 14:14:57 2004
***************
*** 82,87 ****
--- 82,93 ----
   # endif
   #endif

+ #ifdef USE_CARBONIZED
+ # undef USE_TRANSPARENTBACKGROUND
+ # define USE_TRANSPARENTBACKGROUND
+ static float mytrans_alpha = 1.0f;
+ #endif
+
   /* Debugging feature: start Vim window OFFSETed */
   #undef USE_OFFSETED_WINDOW

***************
*** 321,326 ****
--- 327,335 ----
   #ifdef USE_AEVENT
   OSErr HandleUnusedParms (const AppleEvent *theAEvent);
   #endif
+ #ifdef USE_TRANSPARENCY
+ static void carbon_set_transparency(WindowRef w, float alpha);
+ #endif

   /*
    * ------------------------------------------------------------
***************
*** 1813,1818 ****
--- 1822,1868 ----
    * ------------------------------------------------------------
    */

+ #ifdef USE_TRANSPARENTBACKGROUND
+ /*
+  * A transparent version of EraseRect. This is slow.
+  *
+  * TODO: is it possible to use an independent CGContextRef that can be
+  * reused. If so, we could CGContextFlush() later in gui_mch_flush(),
+  * I assume.
+  */
+ static void
+ EraseRectTrans(Rect *r)
+ {
+     CGrafPtr p;
+     CGContextRef ctx;
+     CGRect cgr;
+     Rect pb;
+     RGBColor rgb;
+
+     if (mytrans_alpha == 1.0f) {
+  EraseRect(r);
+  return;
+     }
+
+     p = GetWindowPort(gui.VimWindow);
+     if (noErr == QDBeginCGContext(p, &ctx)) {
+  GetPortBounds(p, &pb);
+  cgr = CGRectMake(pb.left + r->left, pb.bottom - r->bottom,
+ 	    r->right - r->left, r->bottom - r->top);
+  CGContextClearRect(ctx, cgr);
+  GetBackColor(&rgb);
+  CGContextSetRGBFillColor(ctx,
+ 	    (float)rgb.red / 65535.0f,
+ 	    (float)rgb.green / 65535.0f,
+ 	    (float)rgb.blue / 65535.0f,
+ 	    mytrans_alpha);
+  CGContextFillRect(ctx, cgr);
+  CGContextFlush(ctx);
+  QDEndCGContext(p, &ctx);
+     }
+ }
+ #endif /* defined(USE_TRANSPARENTBACKGROUND) */
+
   /*
    * Handle the Update Event
    */
***************
*** 1893,1916 ****
--- 1943,1982 ----
  	   if (updateRectPtr->left < FILL_X(0))
  	   {
  	     SetRect (&rc, 0, 0, FILL_X(0), FILL_Y(Rows));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->top < FILL_Y(0))
  	   {
  	     SetRect (&rc, 0, 0, FILL_X(Columns), FILL_Y(0));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->right > FILL_X(Columns))
  	   {
  	     SetRect (&rc, FILL_X(Columns), 0,
  			    FILL_X(Columns) + gui.border_offset, FILL_Y(Rows));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->bottom > FILL_Y(Rows))
  	   {
  	     SetRect (&rc, 0, FILL_Y(Rows), FILL_X(Columns) + gui.border_offset,
  					     FILL_Y(Rows) + gui.border_offset);
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	 HUnlock ((Handle) updateRgn);
   #ifdef USE_CARBONIZED
***************
*** 2653,2658 ****
--- 2719,2804 ----
   }
   #endif

+ #if defined(USE_TRANSPARENTBACKGROUND)
+ /*
+  * this handler does nothing more than return an empty region if
+  * the system asks for the kWindowOpaqueRgn of the window. Everythin
+  * else is passed through to the next handler.
+  */
+ static OSStatus
+ gui_mac_window_getrgn(EventHandlerCallRef inHandlerCallRef,
+     EventRef inEvent, void *inUserData)
+ {
+     OSStatus err;
+     RgnHandle rgn, contentRgn;
+     WindowRegionCode rgnCode;
+
+     if (mytrans_alpha == 1.0f)
+  goto nextHandler;
+
+     if (kEventClassWindow != GetEventClass(inEvent) ||
+  kEventWindowGetRegion != GetEventKind(inEvent))
+  goto nextHandler;
+     if (noErr != GetEventParameter(inEvent, kEventParamWindowRegionCode,
+  typeWindowRegionCode, NULL, sizeof(WindowRegionCode), NULL,
+  &rgnCode))
+  goto nextHandler;
+     if (rgnCode != kWindowOpaqueRgn)
+  goto nextHandler;
+     err = CallNextEventHandler(inHandlerCallRef, inEvent);
+     if (noErr != GetEventParameter(inEvent, kEventParamRgnHandle,
+  typeQDRgnHandle, NULL, sizeof(RgnHandle), NULL, &rgn))
+  goto nextHandler;
+     contentRgn = NewRgn();
+     GetWindowRegion(gui.VimWindow, kWindowContentRgn, contentRgn);
+     SetEmptyRgn(rgn);
+     return err;
+   nextHandler:
+     return CallNextEventHandler(inHandlerCallRef, inEvent);
+ }
+ #endif /* defined(USE_TRANSPARENTBACKGROUND) */
+
+ #if defined(USE_TRANSPARENTBACKGROUND) && 1
+ /*
+  * clear the window background and fill it with a transparent version
+  * of the gui.back_pixel color.
+  */
+ static OSStatus
+ gui_mac_window_paint_upp(GDHandle dev, GrafPtr qdContext,
+     WindowRef window, RgnHandle inClientPaintRgn,
+     RgnHandle outSystemPaintRgn, void *refCon)
+ {
+     CGContextRef cgc;
+     CGRect rect;
+     Rect pb;
+
+     /*
+      * without transparency just return an error to let the system paint
+      * the background
+      */
+     if (mytrans_alpha == 1.0f)
+  return -1;
+
+     /* otherwise do some conversation and paint using a transparent color */
+     if (noErr != QDBeginCGContext(qdContext, &cgc))
+  return noErr;
+     GetWindowBounds(window, kWindowContentRgn, &pb);
+     rect = CGRectMake(0, 0, pb.right - pb.left, pb.bottom - pb.top);
+     CGContextClearRect(cgc, rect);
+     CGContextSetRGBFillColor(cgc,
+  (float)Red(gui.back_pixel) / 255.0f,
+  (float)Green(gui.back_pixel) / 255.0f,
+  (float)Blue(gui.back_pixel) / 255.0f,
+  mytrans_alpha);
+     CGContextFillRect(cgc, rect);
+     if (inClientPaintRgn != 0)
+  RectRgn(outSystemPaintRgn, (Rect *)&rect);
+     CGContextFlush(cgc);
+     QDEndCGContext(qdContext, &cgc);
+     return noErr;
+ }
+ #endif /* defined(USE_TRANSPARENTBACKGROUND) */
+
   /*
    * Initialise the GUI.  Create all the windows, set up all the call-backs
    * etc.
***************
*** 2722,2728 ****
--- 2868,2900 ----
       gui.VimWindow = NewCWindow(nil, &windRect, "\pgVim on Macintosh", true,
documentProc,
  			 (WindowPtr) -1L, false, 0);
   #ifdef USE_CARBONIZED
+ #ifdef USE_TRANSPARENTBACKGROUND
+     {
+  /* install the event handler for kEventWindowGetRegion */
+  EventTypeSpec ets[] = {
+ 	    { kEventClassWindow, kEventWindowGetRegion }
+  };
+  EventHandlerRef ehr;
+  EventHandlerUPP handlerUPP = NewEventHandlerUPP(gui_mac_window_getrgn);
+  if (noErr != InstallEventHandler(
+ 	    GetWindowEventTarget(gui.VimWindow),
+ 	    handlerUPP, 1, ets, NULL, &ehr))
+ 	    printf("couldn't install handler for kEventWindowGetRegion\n");
+     }
+     {
+  /* install the WindowPaintUPP */
+  WindowPaintUPP windowPaintUPP;
+  windowPaintUPP = NewWindowPaintUPP(gui_mac_window_paint_upp);
+  if (noErr != InstallWindowContentPaintProc(gui.VimWindow,
+ 	    windowPaintUPP, 0, NULL)) {
+ 	    printf("couldn't install window paint proc UPP\n");
+  }
+     }
+ #endif
       SetPortWindowPort ( gui.VimWindow );
+ #ifdef USE_TRANSPARENCY
+     carbon_set_transparency(gui.VimWindow, 1.0f);
+ #endif
   #else
       SetPort(gui.VimWindow);
   #endif
***************
*** 2816,2821 ****
--- 2988,2995 ----
       int
   gui_mch_open()
   {
+     gui_mac_window_paint_upp(0, GetWindowPort(gui.VimWindow),
+  gui.VimWindow, 0, 0, NULL);
       ShowWindow(gui.VimWindow);

       if (gui_win_x != -1 && gui_win_y != -1)
***************
*** 3265,3275 ****
--- 3439,3463 ----
       int  len;
       int  flags;
   {
+ #ifdef USE_TRANSPARENTBACKGROUND
+     Rect r;
+ #endif
       TextMode (srcCopy);
       TextFace (normal);

   /*  SelectFont(hdc, gui.currFont); */

+ #ifdef USE_TRANSPARENTBACKGROUND
+     if (mytrans_alpha != 1.1f) {
+  r.left = TEXT_X(col);
+  r.top = row * gui.char_height + gui.border_width;
+  r.right = TEXT_X(col + len);
+  r.bottom = (row + 1) * gui.char_height + gui.border_width;
+  EraseRectTrans(&r);
+  TextMode(transparent);
+     }
+ #endif
+
       if (flags & DRAW_TRANSP)
       {
  	 TextMode (srcOr);
***************
*** 3322,3327 ****
--- 3510,3519 ----
       /* Do a visual beep by reversing the foreground and background colors */
       Rect    rc;

+ #if defined(USE_TRANSPARENTBACKGROUND) && 0
+     printf("gui_mch_flash called\n");
+ #endif
+
       /*
        * Note: InvertRect() excludes right and bottom of rectangle.
        */
***************
*** 3348,3353 ****
--- 3540,3549 ----
   {
       Rect rc;

+ #if defined(USE_TRANSPARENTBACKGROUND) && 0
+     printf("gui_mch_invert_rectangle called\n");
+ #endif
+
       /*
        * Note: InvertRect() excludes right and bottom of rectangle.
        */
***************
*** 3592,3598 ****
--- 3788,3798 ----
       rc.bottom = FILL_Y(row2 + 1);

       gui_mch_set_bg_color(gui.back_pixel);
+ #ifdef USE_TRANSPARENTBACKGROUND
+     EraseRectTrans(&rc);
+ #else
       EraseRect (&rc);
+ #endif
   }

   /*
***************
*** 3609,3615 ****
--- 3809,3819 ----
       rc.bottom = Rows * gui.char_height + 2 * gui.border_width;

       gui_mch_set_bg_color(gui.back_pixel);
+ #ifdef USE_TRANSPARENTBACKGROUND
+     EraseRectTrans(&rc);
+ #else
       EraseRect(&rc);
+ #endif
   /*  gui_mch_set_fg_color(gui.norm_pixel);
       FrameRect(&rc);
   */
***************
*** 5449,5451 ****
--- 5653,5693 ----
  	     && script == GetScriptManagerVariable(smSysScript)) ? 1 : 0;
   }
   #endif /* defined(USE_IM_CONTROL) || defined(PROTO) */
+
+ #ifdef USE_TRANSPARENCY
+     void
+ carbon_set_transparency(WindowRef w, float alpha)
+ {
+     if (!w)
+  w = gui.VimWindow;
+ #ifdef USE_TRANSPARENTBACKGROUND
+     /*
+      * if we want a transparent window background the system must be fooled
+      * that the window isn't fully opaque. I do this by setting the alpha
+      * value a bit below 1.0f
+      */
+     if (alpha == 1.0f)
+  SetWindowAlpha(w, 1.0f);
+     else
+  SetWindowAlpha(w, 0.9999999f);
+     mytrans_alpha = alpha;
+     {
+  Rect r;
+  GetWindowBounds(gui.VimWindow, kWindowContentRgn, &r);
+  r.right -= r.left;
+  r.left = 0;
+  r.bottom -= r.top;
+  r.top = 0;
+  InvalWindowRect(gui.VimWindow, &r);
+     }
+ #else
+     SetWindowAlpha(w, alpha);
+ #endif
+ }
+
+     void
+ gui_mch_set_transparency(int alpha)
+ {
+     carbon_set_transparency(NULL, (float)alpha / 255);
+ }
+ #endif
diff -cr ../vim62.195/src/option.c ./src/option.c
*** ../vim62.195/src/option.c Tue Jan 20 19:41:47 2004
--- ./src/option.c Tue Jan 20 20:47:59 2004
***************
*** 2094,2099 ****
--- 2094,2104 ----
  			     (char_u *)&p_tbis, PV_NONE,
  			     {(char_u *)"small", (char_u *)0L}},
   #endif
+ #ifdef USE_TRANSPARENCY
+     {"transparency", "tra", P_NUM|P_VI_DEF,
+ 			    (char_u *)&p_transparency, PV_NONE,
+ 			    {(char_u *)255L, (char_u *)0L}},
+ #endif
       {"ttimeout",    NULL,   P_BOOL|P_VI_DEF|P_VIM,
  			     (char_u *)&p_ttimeout, PV_NONE,
  			     {(char_u *)FALSE, (char_u *)0L}},
***************
*** 6552,6557 ****
--- 6557,6571 ----
  	     foldUpdateAll(curwin);
       }
   #endif /* FEAT_FOLDING */
+
+ #ifdef USE_TRANSPARENCY
+     else if ((long *)varp == &p_transparency)
+     {
+  if (p_transparency < 1 || p_transparency > 255)
+ 	    p_transparency = 255;
+  gui_mch_set_transparency(p_transparency);
+     }
+ #endif

       else if (pp == &curbuf->b_p_iminsert)
       {
diff -cr ../vim62.195/src/option.h ./src/option.h
*** ../vim62.195/src/option.h Tue Jan 20 19:41:47 2004
--- ./src/option.h Tue Jan 20 20:47:59 2004
***************
*** 688,693 ****
--- 688,696 ----
   #ifdef FEAT_INS_EXPAND
   EXTERN char_u *p_tsr;  /* 'thesaurus' */
   #endif
+ #ifdef USE_TRANSPARENCY
+ EXTERN long p_transparency; /* 'transparency'*/
+ #endif
   EXTERN int p_ttimeout; /* 'ttimeout' */
   EXTERN long p_ttm;  /* 'ttimeoutlen' */
   EXTERN int p_tbi;  /* 'ttybuiltin' */
diff -cr ../vim62.195/src/os_mac.h ./src/os_mac.h
*** ../vim62.195/src/os_mac.h Tue Jan 20 19:39:52 2004
--- ./src/os_mac.h Tue Jan 20 20:47:59 2004
***************
*** 118,123 ****
--- 118,124 ----
   #if defined(TARGET_API_MAC_OSX) && TARGET_API_MAC_OSX
   # undef COLON_AS_PATHSEP
   # define USE_UNIXFILENAME
+ # define USE_TRANSPARENCY
   #else
   # define COLON_AS_PATHSEP
   # define DONT_ADD_PATHSEP_TO_DIR
diff -cr ../vim62.195/src/proto/gui_mac.pro ./src/proto/gui_mac.pro
*** ../vim62.195/src/proto/gui_mac.pro Tue Jan 20 19:39:52 2004
--- ./src/proto/gui_mac.pro Tue Jan 20 20:47:59 2004
***************
*** 134,139 ****
--- 134,140 ----
   void gui_mac_doMouseDownEvent __ARGS((EventRecord *theEvent));
   void gui_mac_doMouseMovedEvent __ARGS((EventRecord *event));
   void gui_mac_doMouseUpEvent __ARGS((EventRecord *theEvent));
+ void gui_mch_set_transparency __ARGS((int alpha));

   int C2PascalString (char_u *CString, Str255 *PascalString);
   int GetFSSpecFromPath ( char_u *file, FSSpec *fileFSSpec);

--
Eckehard Berns

#1295 From: Eckehard Berns <ecki@...>
Date: Sun Jan 25, 2004 2:54 pm
Subject: Re: transparency scope
ecki@...
Send Email Send Email
 
Hi!

I updated my patch for a transparent background to use a persistent
CGContext. Drawing with a transparent background is a lot faster now.
If you don't change the transparency there is practically no speed
impact. The new patch can be found at
http://ecki.to/vim-icns/TransBack.diff. There's still a problem when
resizing the Vim window with the grow handle. A Ctrl-L helps in this
case.

To make the transparent background work with antialias.diff by Peter
Cucka I also made a combined diff including transparent background,
antialiased fonts, mouse wheel support, a working Ctrl-C in child
processes and the HitReturn.diff. It can be downloaded from
http://ecki.to/vim-icns/Combined.diff.

--
Eckehard Berns

#1296 From: Eckehard Berns <ecki@...>
Date: Mon Jan 26, 2004 6:52 pm
Subject: Re: transparency scope
ecki@...
Send Email Send Email
 
Hi!

Since the antialiased fonts patch has become official now, I updated my
transparent background patch to cleanly apply to Vim 6.2.211. It can be
fetched from http://ecki.to/vim-icns/TransBack.diff.

--
Eckehard Berns

#1316 From: Benji Fisher <benji@...>
Date: Tue Jan 27, 2004 2:19 am
Subject: Multiple copies of Vim.app running in OS X
benji@...
Send Email Send Email
 
Vim Mac fans:

      I am sorry about the broken threading.  I seem to have been
unsubscribed from the list.  I got a digest of the messages I missed,
but that does not let me respond to the individual messages ...

      Anyway, someone asked about whether it is possible to have multiple
copies of Vim.app running on OS X.  This is easy if you start Vim.app
from the command line.  (See the FAQ on the web page.)  It is also the
raison d'etre of gvim.app , which is included in the recent binary
distributions and also from a link in the News section.  (Currently the
oldest news item listed.  Thanks to Peter Cucka for this!)

HTH 			 --Benji Fisher

#1318 From: Benji Fisher <benji@...>
Date: Tue Jan 27, 2004 3:46 am
Subject: Re: bug in linewise yy followed by p
benji@...
Send Email Send Email
 
> Date: Fri, 16 Jan 2004 14:19:09 -0800
> From: Michael DeMoney <Michael.Demoney@...>
> Subject: Re: bug in linewise yy followed by p?
>
> 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

      Sorry about the broken threading.  Same explanation as for my last
post.

      I can confirm this problem.  Another way to reproduce it:

"*yy
"*p

or

"+yy
"+p

If I run vim in a Terminal window, the problem is not there.  If I run
it (the same binary) in the GUI window, the problem is there.  This is
vim 6.2.195 on OS X 10.3.2.

					 --Benji Fisher

P.S.  The @* and @+ registers seem to be different names for the same
thing.  I guess that's OK.  If I put something in the @* register while
running in a terminal, then start the GUI with :gui , then what I put in
the @* register is no longer there, which seems odd.

#1326 From: Thomas Koch <tom@...>
Date: Tue Jan 27, 2004 8:42 am
Subject: Re: Server Report
tom@...
Send Email Send Email
 
Hello,

is nobody out there feeling responsible for this? Maybe the list
administrator should disallow messages from non subscribed users!!

Please stop that!!

Tom.

  From koron@... Tue Jan 27 09:40:14 2004
Return-Path: <vim-mac-return-1331-tom=harhar.net@...>
Delivered-To: harhar-net-tom@...
Received: (qmail 9262 invoked from network); 27 Jan 2004 08:38:47 -0000
Received: from foobar.math.fu-berlin.de (160.45.45.151)
    by higgens.harhar.net with SMTP; 27 Jan 2004 08:38:47 -0000
Received: (qmail 27770 invoked by uid 200); 27 Jan 2004 08:39:19 -0000
Mailing-List: contact vim-mac-help@...; run by ezmlm
Precedence: bulk
Delivered-To: mailing list vim-mac@...
Received: (qmail 27757 invoked from network); 27 Jan 2004 08:39:18 -0000
Received: from ice.42.org (194.77.3.162)
    by foobar.math.fu-berlin.de with SMTP; 27 Jan 2004 08:39:18 -0000
Received: from tka.att.ne.jp
(dialup-32.229.220.203.acc01-seve-mub.comindico.com.au
[203.220.229.32])
	 by ice.42.org (Postfix) with ESMTP id E4EF31C8EA
	 for <vim-mac@...>; Tue, 27 Jan 2004 09:38:21 +0100 (CET)
From: koron@...
To: vim-mac@...
Subject: Server Report
Date: Tue, 27 Jan 2004 19:08:16 +1030
MIME-Version: 1.0
Content-Type: multipart/mixed;
	 boundary="----=_NextPart_000_0009_C6638D07.16143C9F"
X-Priority: 3
X-MSMail-Priority: Normal
Message-Id: <20040127083821.E4EF31C8EA@...>



------=_NextPart_000_0009_C6638D07.16143C9F
Content-Type: text/plain;
	 charset="Windows-1252"
Content-Transfer-Encoding: 7bit

The message cannot be represented in 7-bit ASCII encoding and has been
sent as a binary attachment.


------=_NextPart_000_0009_C6638D07.16143C9F--

#1329 From: Benji Fisher <benji@...>
Date: Tue Jan 27, 2004 12:57 pm
Subject: Re: Server Report
benji@...
Send Email Send Email
 
On Tue, Jan 27, 2004 at 09:42:51AM +0100, Thomas Koch wrote:
>
> Hello,
>
> is nobody out there feeling responsible for this? Maybe the list
> administrator should disallow messages from non subscribed users!!
>
> Please stop that!!
>
> Tom.

      The list *does* disallow messages from non subscribed users.  This
is an unusually bad worm, causing problems all over the net.  The worm
is spoofing the addresses of list members; it is likely that the
messages that appear to be from mac@... (an alias for me),
bram@..., etc. are from entirely different computers.  Bear with us
for a few days, you are not alone.

HTH 			 --Benji Fisher

#1330 From: Bram Moolenaar <Bram@...>
Date: Tue Jan 27, 2004 12:55 pm
Subject: More runtime files available et al.
Bram@...
Send Email Send Email
 
A collection of items this time.


NEW ITEM TO VOTE ON

Upon request I have added one item to vote on:

   add autocommand events for Insert mode, before/after inserting a character

I also corrected the description for improving Mac OS 9.  Don't know how
it became corrupted, hopefully this doesn't happen again.

More info about voting can be found here:
	 http://www.vim.org/sponsor/faq.php


TRANSLATED MESSAGES AVAILABLE

I have made the most recent message translations available on the ftp
site.  Like the runtime files, you can run an Aap script to download
them.  Or just get the one you need.  Info is here:
	 ftp://ftp.vim.org/pub/vim/messages/README
Note that you must have the gettext tools to be able to use these files.


DOS VERSION OF RUNTIME FILES

Updating the runtime files on Dos/MS-Windows systems had the
disadvantage that all files were downloaded with a unix fileformat.
The dos version of the files are now also available, and the Aap script
has been adjusted to automatically select the filetype to use.  This
works by checking the filetype.vim file, thus make sure that file has
the right fileformat for you.  Info is here:
	 ftp://ftp.vim.org/pub/vim/runtime/README.txt

You can download the dos runtime files directly from:
	 ftp://ftp.vim.org/pub/vim/runtime/dos/


MAILLISTS DOWN

The Vim maillists were down on Sunday and Monday morning.  The
connection to the maillist server was broken.  No messages should be
lost, the backup mail server did its work.  But messages were not
distributed until the maillist server was back online.  Thanks to the
people at math.fu-berlin.de for fixing the problem!


VIRUS FLOOD

There is a very busy virus/worm active now.  Although my system won't be
affected, the number of messages I receive is so big that I can hardly
manage to keep up with downloading them from my mail server.  A few
messages might get lost in the masses (I already got more than 10000).

- If you have an MS-Windows system, you MUST have a virus scanner and
   update it daily.  There are too many ways to catch a virus or worm
   now.  Don't think it won't harm you.

- If you maintain a mail server, please install a virus filter.  And set
   it up so that it won't bounce a message back (the From address is
   mostly fake, it will just generate more traffic and tell innocent
   people that their system is infected).

- If you wrote that virus, please report to the nearest police station
   and go to jail.

--
If you don't get everything you want, think of
everything you didn't get and don't want.

  /// 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  ///

#1348 From: Culley Harrelson <culley@...>
Date: Tue Jan 27, 2004 7:09 pm
Subject: Upgrading to panther while resting in the eye of a spam hurricane!
culley@...
Send Email Send Email
 
I just upgraded to panther.  All is well-- the latest binary package is
working great.  Anything you guys want tested?  I would be happy to
test scripts that use tcl/perl/ruby interfaces.  Send them my way.

culley

#1360 From: Bram Moolenaar <Bram@...>
Date: Wed Jan 28, 2004 10:36 am
Subject: Re: Server Report
Bram@...
Send Email Send Email
 
Thomas Koch wrote:

> is nobody out there feeling responsible for this? Maybe the list
> administrator should disallow messages from non subscribed users!!
>
> Please stop that!!

This virus is causing lots of trouble everywhere.  Considering that I
received thousands of these messages, it's not too bad that only a few
appear on the maillist.

The maillist is already subscriber-only.  But since the virus fakes the
"From" address some message do get through.  Only moderation would
prevent that, but that's too much work.

--
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   \\\
///        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  ///

#1361 From: Bram Moolenaar <Bram@...>
Date: Wed Jan 28, 2004 10:36 am
Subject: Re: bug in linewise yy followed by p
Bram@...
Send Email Send Email
 
Benji Fisher wrote:

> P.S.  The @* and @+ registers seem to be different names for the same
> thing.  I guess that's OK.  If I put something in the @* register while
> running in a terminal, then start the GUI with :gui , then what I put in
> the @* register is no longer there, which seems odd.

On X11 there is the "current selection" and a clipboard.  The * and +
registers are different then.  On systems with only a clipboard they are
the same.

--
BLACK KNIGHT: I'm invincible!
ARTHUR:       You're a looney.
                  "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  ///

#1388 From: Benji Fisher <benji@...>
Date: Fri Jan 30, 2004 7:36 pm
Subject: some new patches to try out
benji@...
Send Email Send Email
 
Vim Mac fans:

      There are some new patches to try out at
http://macvim.swdev.org/OSX/#configure .

1. antitag.diff (Peter Cucka)

Peter Cucka's antialias patch was made official (6.2.210) but the
official patch does not change the tags file.  If you are already
applying custom patches, then this may be more convenient than running
:helptags $VIMRUNTIME
after compiling.

2. MouseWheel.diff (Eckehard Berns)

This enables a scroll wheel.  In my (limited) testing, it works like a
charm!

3. TransBack.diff (Eckehard Berns)

This is an alternative to Muraoka Taro's  transparency.diff .  Only the
background of the window, not the text nor the title bar, becomes
transparent when the new 'transparency' option is set less than 255.
There is no danger of having the window totally disappear.

Drawbacks:  Scrolling in the command-line area is slow.  (Try :version .)
There are some redrawing problems when the main window is resized.

Peter Cucka and Ken Scott:

      Can you compile new versions with the latest official patches and
at least the first two of these?  It is up to you which version of
transparency you use.

					 --Benji Fisher

P.S.  Hardware update:  I verified (with Apple Hardware Test) that my
RAM was defective, so I replaced it.  Unfortunately, my hard drive has
been corrupted.  It looks like I will have to reformat and reinstall...

#1389 From: Eckehard Berns <ecki@...>
Date: Fri Jan 30, 2004 8:55 pm
Subject: Re: experimental mouse wheel patch
ecki@...
Send Email Send Email
 
> I have tried to make the mouse wheel work natively (e.g. without
> USB overdrive) in Vim for Mac OS X.

I fixed an issue with split windows. This patch is diffed against
6.2.214.

diff -cr ../vim62.214/src/gui_mac.c ./src/gui_mac.c
*** ../vim62.214/src/gui_mac.c Mon Jan 26 18:16:14 2004
--- ./src/gui_mac.c Fri Jan 30 20:37:36 2004
***************
*** 82,87 ****
--- 82,98 ----
   # endif
   #endif

+ #undef USE_MOUSEWHEEL
+ #if defined(MACOS_X) && defined(USE_CARBONIZED)
+ # define USE_MOUSEWHEEL
+ /* TODO: do we need to free these resources later? Where? */
+ static EventHandlerUPP mouseWheelHandlerUPP;
+ static EventHandlerRef mouseWheelHandlerRef;
+ /* TODO: do we need to break out of the WaitNewEventWrp loop or is the
+  * bogus event enough to update the window instantly? */
+ static int had_mouse_wheel = 0;
+ #endif
+
   /* Debugging feature: start Vim window OFFSETed */
   #undef USE_OFFSETED_WINDOW

***************
*** 2231,2236 ****
--- 2242,2321 ----
         (MOUSE_RELEASE, thePoint.h, thePoint.v, FALSE, vimModifiers);
   }

+ #ifdef USE_MOUSEWHEEL
+ static pascal OSStatus
+ gui_mac_mouse_wheel(EventHandlerCallRef nextHandler, EventRef theEvent,
+     void *data)
+ {
+     EventRef bogusEvent;
+     Point point;
+     Rect bounds;
+     UInt32 mod;
+     SInt32 delta;
+     int_u vim_mod;
+
+     /*
+      * TODO: can that ever happen? In theory allow_scrollbar is TRUE
+      * throughout the WaitNextEvent loop and the callback could only
+      * happen when the application called WaitNextEvent first
+      */
+     if (!allow_scrollbar)
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamMouseWheelDelta,
+  typeSInt32, NULL, sizeof(SInt32), NULL, &delta))
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamMouseLocation,
+  typeQDPoint, NULL, sizeof(Point), NULL, &point))
+  goto bail;
+
+     if (noErr != GetEventParameter(theEvent, kEventParamKeyModifiers,
+  typeUInt32, NULL, sizeof(UInt32), NULL, &mod))
+  goto bail;
+
+     vim_mod = 0;
+     if (mod & shiftKey)
+  vim_mod |= MOUSE_SHIFT;
+     if (mod & controlKey)
+  vim_mod |= MOUSE_CTRL;
+     if (mod & optionKey)
+  vim_mod |= MOUSE_ALT;
+
+     if (noErr != CreateEvent(NULL, kEventClassMouse, kEventMouseMoved, 0,
+  kEventAttributeNone, &bogusEvent))
+  goto bail;
+     if (noErr != PostEventToQueue(GetMainEventQueue(), bogusEvent,
+  kEventPriorityLow))
+  goto bail;
+
+     if (noErr == GetWindowBounds(gui.VimWindow, kWindowContentRgn, &bounds)) {
+  point.h -= bounds.left;
+  point.v -= bounds.top;
+     }
+
+     gui_send_mouse_event((delta > 0) ? MOUSE_4 : MOUSE_5,
+  point.h, point.v, FALSE, vim_mod);
+     /*
+      * TODO: do I need to send the MOUSE_RELEASE after a MOUSE_4 event?
+      * And if so, will the bogus mUp event cause this MOUSE_RELEASE for me?
+      */
+     /* gui_send_mouse_event(MOUSE_RELEASE, point.h, point.v,
+  FALSE, vim_mod); */
+     /* TODO: see definition of had_mouse_wheel */
+     had_mouse_wheel = 1;
+
+     return noErr;
+
+   bail:
+     /*
+      * when we fail give any additional callback handler a chance to perform
+      * it's actions
+      */
+     return CallNextEventHandler(nextHandler, theEvent);
+ }
+ #endif /* defined(USE_MOUSEWHEEL) */
+
   #if 0

   /*
***************
*** 2720,2725 ****
--- 2805,2813 ----
   #ifdef USE_CTRLCLICKMENU
       long gestalt_rc;
   #endif
+ #ifdef USE_MOUSEWHEEL
+     EventTypeSpec   eventTypeSpec;
+ #endif
   #if 1
       InitCursor();

***************
*** 2856,2861 ****
--- 2944,2967 ----
       vim_setenv((char_u *)"QDTEXT_MINSIZE", (char_u *)"1");
   #endif

+ #ifdef USE_MOUSEWHEEL
+     eventTypeSpec.eventClass = kEventClassMouse;
+     eventTypeSpec.eventKind = kEventMouseWheelMoved;
+     /* TODO: do we need to free these handlers at exit? Where? */
+     mouseWheelHandlerUPP = NewEventHandlerUPP(gui_mac_mouse_wheel);
+ #if 0
+     if (noErr != InstallWindowEventHandler(gui.VimWindow,
+  mouseWheelHandlerUPP, 1, &eventTypeSpec, NULL, &mouseWheelHandlerRef))
+ #else
+     if (noErr != InstallApplicationEventHandler(mouseWheelHandlerUPP, 1,
+  &eventTypeSpec, NULL, &mouseWheelHandlerRef))
+ #endif
+     {
+  mouseWheelHandlerRef = NULL;
+  DisposeEventHandlerUPP(mouseWheelHandlerUPP);
+     }
+ #endif /* defined(USE_MOUSEWHEEL) */
+
       /* TODO: Load bitmap if using TOOLBAR */
       return OK;
   }
***************
*** 3662,3667 ****
--- 3768,3780 ----
  		 return OK;
  	     }
  	 }
+ #ifdef USE_MOUSEWHEEL
+  /* is this needed? see definition of had_mouse_wheel */
+  if (had_mouse_wheel) {
+ 	    had_mouse_wheel = 0;
+ 	    break;
+  }
+ #endif
  	 currentTick = TickCount();
       }
       while ((wtime == -1) || ((currentTick - entryTick) < 60*wtime/1000));

--
Eckehard Berns

#1391 From: Eckehard Berns <ecki@...>
Date: Sat Jan 31, 2004 3:22 pm
Subject: Re: transparency scope
ecki@...
Send Email Send Email
 
Hi!

I have updated my patch for a transparent background. It fixes some
drawing problems and improves speed a bit. Resizing the window works
as expected now, besides a small area at the bottom of the window
(a few pixels high), which might under certain circumstances be
drawn in opaque white.

diff -cr ../vim62.215/src/gui_mac.c ./src/gui_mac.c
*** ../vim62.215/src/gui_mac.c Mon Jan 26 18:16:14 2004
--- ./src/gui_mac.c Sat Jan 31 15:35:25 2004
***************
*** 82,87 ****
--- 82,94 ----
   # endif
   #endif

+ #ifdef USE_CARBONIZED
+ # undef USE_TRANSPARENTBACKGROUND
+ # define USE_TRANSPARENTBACKGROUND
+ static float mytrans_alpha = 1.0f;
+ static CGContextRef mytrans_context;
+ #endif
+
   /* Debugging feature: start Vim window OFFSETed */
   #undef USE_OFFSETED_WINDOW

***************
*** 321,326 ****
--- 328,336 ----
   #ifdef USE_AEVENT
   OSErr HandleUnusedParms (const AppleEvent *theAEvent);
   #endif
+ #ifdef USE_TRANSPARENCY
+ static void carbon_set_transparency(WindowRef w, float alpha);
+ #endif

   /*
    * ------------------------------------------------------------
***************
*** 1813,1818 ****
--- 1823,1860 ----
    * ------------------------------------------------------------
    */

+ #ifdef USE_TRANSPARENTBACKGROUND
+ /*
+  * A transparent version of EraseRect
+  */
+ static void
+ EraseRectTrans(Rect *r)
+ {
+     CGrafPtr p;
+     CGRect cgr;
+     Rect pb;
+     RGBColor rgb;
+
+     if (mytrans_alpha == 1.0f) {
+  EraseRect(r);
+  return;
+     }
+
+     p = GetWindowPort(gui.VimWindow);
+     GetPortBounds(p, &pb);
+     cgr = CGRectMake(pb.left + r->left, pb.bottom - r->bottom,
+  r->right - r->left, r->bottom - r->top);
+     CGContextClearRect(mytrans_context, cgr);
+     GetBackColor(&rgb);
+     CGContextSetRGBFillColor(mytrans_context,
+  (float)rgb.red / 65535.0f,
+  (float)rgb.green / 65535.0f,
+  (float)rgb.blue / 65535.0f,
+  mytrans_alpha);
+     CGContextFillRect(mytrans_context, cgr);
+ }
+ #endif /* defined(USE_TRANSPARENTBACKGROUND) */
+
   /*
    * Handle the Update Event
    */
***************
*** 1849,1855 ****
--- 1891,1904 ----

       /* Select the Window's Port */
   #ifdef USE_CARBONIZED
+ #ifdef USE_TRANSPARENTBACKGROUND
+     CGContextFlush(mytrans_context);
+     CGContextRelease(mytrans_context);
+ #endif
       SetPortWindowPort (whichWindow);
+ #ifdef USE_TRANSPARENTBACKGROUND
+     CreateCGContextForPort(GetWindowPort(gui.VimWindow), &mytrans_context);
+ #endif
   #else
       SetPort (whichWindow);
   #endif
***************
*** 1884,1889 ****
--- 1933,1942 ----
   #else
  	   updateRectPtr = &(*updateRgn)->rgnBBox;
   #endif
+ #ifdef USE_TRANSPARENTBACKGROUND
+  if (mytrans_alpha != 1.0f)
+ 	    ClipCGContextToRegion(mytrans_context, updateRectPtr, updateRgn);
+ #endif
  	   /* Update the content (i.e. the text) */
  	   gui_redraw(updateRectPtr->left, updateRectPtr->top,
  		       updateRectPtr->right - updateRectPtr->left,
***************
*** 1893,1916 ****
--- 1946,1985 ----
  	   if (updateRectPtr->left < FILL_X(0))
  	   {
  	     SetRect (&rc, 0, 0, FILL_X(0), FILL_Y(Rows));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->top < FILL_Y(0))
  	   {
  	     SetRect (&rc, 0, 0, FILL_X(Columns), FILL_Y(0));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->right > FILL_X(Columns))
  	   {
  	     SetRect (&rc, FILL_X(Columns), 0,
  			    FILL_X(Columns) + gui.border_offset, FILL_Y(Rows));
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	   if (updateRectPtr->bottom > FILL_Y(Rows))
  	   {
  	     SetRect (&rc, 0, FILL_Y(Rows), FILL_X(Columns) + gui.border_offset,
  					     FILL_Y(Rows) + gui.border_offset);
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
  	     EraseRect (&rc);
+ #endif
  	   }
  	 HUnlock ((Handle) updateRgn);
   #ifdef USE_CARBONIZED
***************
*** 1937,1942 ****
--- 2006,2026 ----
  	 DisposeRgn (saveRgn);
         EndUpdate (whichWindow);

+ #ifdef USE_TRANSPARENTBACKGROUND
+     /*
+      * TODO: I don't know how to reset the clipping path after
+      * ClipCGContextToRegion(), so I just create a new context for the
+      * current port.
+      * The header files state that the clipping path cannot be restored
+      * by a SaveGState/RestoreGState pair.
+      */
+     if (mytrans_alpha != 1.0f) {
+  CGContextFlush(mytrans_context);
+  CGContextRelease(mytrans_context);
+  CreateCGContextForPort(GetWindowPort(gui.VimWindow), &mytrans_context);
+     }
+ #endif
+
       /* Restore original Port */
       SetPort (savePort);
   }
***************
*** 1954,1960 ****
--- 2038,2067 ----
       whichWindow = (WindowPtr) event->message;
       if ((event->modifiers) & activeFlag)
  	 /* Activate */
+ #ifdef USE_TRANSPARENTBACKGROUND
+     {
  	 gui_focus_change(TRUE);
+  if (mytrans_alpha != 1.0f) {
+ 	    /*
+ 	     * in case the activate event is caused by showing Vim after
+ 	     * it has been hidden, the whole window has to be redrawn
+ 	     *
+ 	     * TODO: distinguish between a normal focus change and a show
+ 	     *       application
+ 	     */
+ 	    Rect r;
+ 	    GetWindowBounds(gui.VimWindow, kWindowContentRgn, &r);
+ 	    r.right -= r.left;
+ 	    r.left = 0;
+ 	    r.bottom -= r.top;
+ 	    r.top = 0;
+ 	    gui_mch_set_bg_color(gui.back_pixel);
+ 	    InvalWindowRect(gui.VimWindow, &r);
+  }
+     }
+ #else
+  gui_focus_change(TRUE);
+ #endif
       else
       {
  	 /* Deactivate */
***************
*** 2707,2712 ****
--- 2814,2858 ----
       return noErr;
   }

+ #if defined(USE_TRANSPARENTBACKGROUND)
+ /*
+  * this handler does nothing more than return an empty region if
+  * the system asks for the kWindowOpaqueRgn of the window. Everythin
+  * else is passed through to the next handler.
+  */
+ static OSStatus
+ gui_mac_window_getrgn(EventHandlerCallRef inHandlerCallRef,
+     EventRef inEvent, void *inUserData)
+ {
+     OSStatus err;
+     RgnHandle rgn, contentRgn;
+     WindowRegionCode rgnCode;
+
+     if (mytrans_alpha == 1.0f)
+  goto nextHandler;
+
+     if (kEventClassWindow != GetEventClass(inEvent) ||
+  kEventWindowGetRegion != GetEventKind(inEvent))
+  goto nextHandler;
+     if (noErr != GetEventParameter(inEvent, kEventParamWindowRegionCode,
+  typeWindowRegionCode, NULL, sizeof(WindowRegionCode), NULL,
+  &rgnCode))
+  goto nextHandler;
+     if (rgnCode != kWindowOpaqueRgn)
+  goto nextHandler;
+     err = CallNextEventHandler(inHandlerCallRef, inEvent);
+     if (noErr != GetEventParameter(inEvent, kEventParamRgnHandle,
+  typeQDRgnHandle, NULL, sizeof(RgnHandle), NULL, &rgn))
+  goto nextHandler;
+     contentRgn = NewRgn();
+     GetWindowRegion(gui.VimWindow, kWindowContentRgn, contentRgn);
+     SetEmptyRgn(rgn);
+     return err;
+   nextHandler:
+     return CallNextEventHandler(inHandlerCallRef, inEvent);
+ }
+ #endif /* defined(USE_TRANSPARENTBACKGROUND) */
+
   /*
    * Initialise the GUI.  Create all the windows, set up all the call-backs
    * etc.
***************
*** 2778,2784 ****
--- 2924,2947 ----
       InstallReceiveHandler((DragReceiveHandlerUPP)receiveHandler,
  	     gui.VimWindow, NULL);
   #ifdef USE_CARBONIZED
+ #ifdef USE_TRANSPARENTBACKGROUND
+     {
+  /* install the event handler for kEventWindowGetRegion */
+  EventTypeSpec ets[] = {
+ 	    { kEventClassWindow, kEventWindowGetRegion }
+  };
+  EventHandlerRef ehr;
+  EventHandlerUPP handlerUPP = NewEventHandlerUPP(gui_mac_window_getrgn);
+  if (noErr != InstallEventHandler(
+ 	    GetWindowEventTarget(gui.VimWindow),
+ 	    handlerUPP, 1, ets, NULL, &ehr))
+ 	    printf("couldn't install handler for kEventWindowGetRegion\n");
+     }
+ #endif
       SetPortWindowPort ( gui.VimWindow );
+ #ifdef USE_TRANSPARENCY
+     carbon_set_transparency(gui.VimWindow, 1.0f);
+ #endif
   #else
       SetPort(gui.VimWindow);
   #endif
***************
*** 2878,2883 ****
--- 3041,3049 ----
       int
   gui_mch_open()
   {
+ #ifdef USE_TRANSPARENTBACKGROUND
+     CreateCGContextForPort(GetWindowPort(gui.VimWindow), &mytrans_context);
+ #endif
       ShowWindow(gui.VimWindow);

       if (gui_win_x != -1 && gui_win_y != -1)
***************
*** 3327,3332 ****
--- 3493,3501 ----
       int  len;
       int  flags;
   {
+ #ifdef USE_TRANSPARENTBACKGROUND
+     Rect r;
+ #endif

   #if defined(FEAT_GUI) && defined(MACOS_X)
       /*
***************
*** 3370,3376 ****
--- 3539,3549 ----
               rc.top = FILL_Y(row);
               rc.right = FILL_X(col + len) + (col + len == Columns);
               rc.bottom = FILL_Y(row + 1);
+ #ifdef USE_TRANSPARENTBACKGROUND
+ 	    EraseRectTrans(&rc);
+ #else
               EraseRect(&rc);
+ #endif
           }

           MoveTo(TEXT_X(col), TEXT_Y(row));
***************
*** 3389,3394 ****
--- 3562,3577 ----
  	 {
  	     TextMode (srcOr);
  	 }
+ #ifdef USE_TRANSPARENTBACKGROUND
+  else if (mytrans_alpha != 1.1f) {
+ 	    r.left = TEXT_X(col);
+ 	    r.top = row * gui.char_height + gui.border_width;
+ 	    r.right = TEXT_X(col + len);
+ 	    r.bottom = (row + 1) * gui.char_height + gui.border_width;
+ 	    EraseRectTrans(&r);
+ 	    TextMode(srcOr /* transparent */);
+  }
+ #endif

  	 MoveTo (TEXT_X(col), TEXT_Y(row));
  	 DrawText ((char *)s, 0, len);
***************
*** 3449,3455 ****

       ui_delay((long)msec, TRUE);  /* wait for some msec */

!     InvertRect(&rc);
   }

   /*
--- 3632,3649 ----

       ui_delay((long)msec, TRUE);  /* wait for some msec */

! #ifdef USE_TRANSPARENTBACKGROUND
!     if (mytrans_alpha != 1.0f) {
!  Rect r;
!  GetWindowBounds(gui.VimWindow, kWindowContentRgn, &r);
!  r.right -= r.left;
!  r.left = 0;
!  r.bottom -= r.top;
!  r.top = 0;
!  InvalWindowRect(gui.VimWindow, &r);
!     } else
! #endif
!  InvertRect(&rc);
   }

   /*
***************
*** 3464,3469 ****
--- 3658,3667 ----
   {
       Rect rc;

+ #if defined(USE_TRANSPARENTBACKGROUND) && 1
+     printf("gui_mch_invert_rectangle called\n");
+ #endif
+
       /*
        * Note: InvertRect() excludes right and bottom of rectangle.
        */
***************
*** 3683,3688 ****
--- 3881,3891 ----
   gui_mch_flush()
   {
       /* TODO: Is anything needed here? */
+ #if defined(USE_TRANSPARENTBACKGROUND) && 1
+     if (mytrans_alpha != 1.0f) {
+  CGContextSynchronize(mytrans_context);
+     }
+ #endif
   }

   /*
***************
*** 3708,3714 ****
--- 3911,3921 ----
       rc.bottom = FILL_Y(row2 + 1);

       gui_mch_set_bg_color(gui.back_pixel);
+ #ifdef USE_TRANSPARENTBACKGROUND
+     EraseRectTrans(&rc);
+ #else
       EraseRect (&rc);
+ #endif
   }

   /*
***************
*** 3725,3731 ****
--- 3932,3942 ----
       rc.bottom = Rows * gui.char_height + 2 * gui.border_width;

       gui_mch_set_bg_color(gui.back_pixel);
+ #ifdef USE_TRANSPARENTBACKGROUND
+     EraseRectTrans(&rc);
+ #else
       EraseRect(&rc);
+ #endif
   /*  gui_mch_set_fg_color(gui.norm_pixel);
       FrameRect(&rc);
   */
***************
*** 4397,4402 ****
--- 4608,4617 ----
       int  w;
       int  h;
   {
+ #ifdef USE_TRANSPARENTBACKGROUND
+     Rect r;
+ #endif
+
       gui_mch_set_bg_color(gui.back_pixel);
   /*  if (gui.which_scrollbars[SBAR_LEFT])
       {
***************
*** 4416,4426 ****
--- 4631,4654 ----
       if (gui.which_scrollbars[SBAR_LEFT])
  	 x -= 15;

+ #ifdef USE_TRANSPARENTBACKGROUND
+     if (mytrans_alpha != 1.0f) {
+  GetControlBounds(sb->id, &r);
+     }
+ #endif
+
       MoveControl (sb->id, x, y);
       SizeControl (sb->id, w, h);
   #ifdef DEBUG_MAC_SB
       printf ("size_sb (%x) %x, %x, %x, %x\n",sb->id, x, y, w, h);
   #endif
+
+ #ifdef USE_TRANSPARENTBACKGROUND
+     if (mytrans_alpha != 1.0f) {
+  if (r.left < x)
+ 	    EraseRectTrans(&r);
+     }
+ #endif
   }

       void
***************
*** 5566,5568 ****
--- 5794,5834 ----
  	     && script == GetScriptManagerVariable(smSysScript)) ? 1 : 0;
   }
   #endif /* defined(USE_IM_CONTROL) || defined(PROTO) */
+
+ #ifdef USE_TRANSPARENCY
+     void
+ carbon_set_transparency(WindowRef w, float alpha)
+ {
+     if (!w)
+  w = gui.VimWindow;
+ #ifdef USE_TRANSPARENTBACKGROUND
+     /*
+      * if we want a transparent window background the system must be fooled
+      * that the window isn't fully opaque. I do this by setting the alpha
+      * value a bit below 1.0f
+      */
+     if (alpha == 1.0f)
+  SetWindowAlpha(w, 1.0f);
+     else
+  SetWindowAlpha(w, 0.9999999f);
+     mytrans_alpha = alpha;
+     {
+  Rect r;
+  GetWindowBounds(gui.VimWindow, kWindowContentRgn, &r);
+  r.right -= r.left;
+  r.left = 0;
+  r.bottom -= r.top;
+  r.top = 0;
+  InvalWindowRect(gui.VimWindow, &r);
+     }
+ #else
+     SetWindowAlpha(w, alpha);
+ #endif
+ }
+
+     void
+ gui_mch_set_transparency(int alpha)
+ {
+     carbon_set_transparency(NULL, (float)alpha / 255);
+ }
+ #endif
diff -cr ../vim62.215/src/option.c ./src/option.c
*** ../vim62.215/src/option.c Mon Jan 26 18:16:14 2004
--- ./src/option.c Fri Jan 30 18:27:27 2004
***************
*** 2103,2108 ****
--- 2103,2113 ----
  			     (char_u *)&p_tbis, PV_NONE,
  			     {(char_u *)"small", (char_u *)0L}},
   #endif
+ #ifdef USE_TRANSPARENCY
+     {"transparency", "tra", P_NUM|P_VI_DEF,
+ 			    (char_u *)&p_transparency, PV_NONE,
+ 			    {(char_u *)255L, (char_u *)0L}},
+ #endif
       {"ttimeout",    NULL,   P_BOOL|P_VI_DEF|P_VIM,
  			     (char_u *)&p_ttimeout, PV_NONE,
  			     {(char_u *)FALSE, (char_u *)0L}},
***************
*** 6561,6566 ****
--- 6566,6580 ----
  	     foldUpdateAll(curwin);
       }
   #endif /* FEAT_FOLDING */
+
+ #ifdef USE_TRANSPARENCY
+     else if ((long *)varp == &p_transparency)
+     {
+  if (p_transparency < 1 || p_transparency > 255)
+ 	    p_transparency = 255;
+  gui_mch_set_transparency(p_transparency);
+     }
+ #endif

       else if (pp == &curbuf->b_p_iminsert)
       {
diff -cr ../vim62.215/src/option.h ./src/option.h
*** ../vim62.215/src/option.h Mon Jan 26 18:16:14 2004
--- ./src/option.h Fri Jan 30 18:27:27 2004
***************
*** 691,696 ****
--- 691,699 ----
   #ifdef FEAT_INS_EXPAND
   EXTERN char_u *p_tsr;  /* 'thesaurus' */
   #endif
+ #ifdef USE_TRANSPARENCY
+ EXTERN long p_transparency; /* 'transparency'*/
+ #endif
   EXTERN int p_ttimeout; /* 'ttimeout' */
   EXTERN long p_ttm;  /* 'ttimeoutlen' */
   EXTERN int p_tbi;  /* 'ttybuiltin' */
diff -cr ../vim62.215/src/os_mac.h ./src/os_mac.h
*** ../vim62.215/src/os_mac.h Tue Jan 20 19:39:52 2004
--- ./src/os_mac.h Fri Jan 30 18:27:27 2004
***************
*** 118,123 ****
--- 118,124 ----
   #if defined(TARGET_API_MAC_OSX) && TARGET_API_MAC_OSX
   # undef COLON_AS_PATHSEP
   # define USE_UNIXFILENAME
+ # define USE_TRANSPARENCY
   #else
   # define COLON_AS_PATHSEP
   # define DONT_ADD_PATHSEP_TO_DIR
diff -cr ../vim62.215/src/proto/gui_mac.pro ./src/proto/gui_mac.pro
*** ../vim62.215/src/proto/gui_mac.pro Tue Jan 20 19:39:52 2004
--- ./src/proto/gui_mac.pro Fri Jan 30 18:27:27 2004
***************
*** 134,139 ****
--- 134,140 ----
   void gui_mac_doMouseDownEvent __ARGS((EventRecord *theEvent));
   void gui_mac_doMouseMovedEvent __ARGS((EventRecord *event));
   void gui_mac_doMouseUpEvent __ARGS((EventRecord *theEvent));
+ void gui_mch_set_transparency __ARGS((int alpha));

   int C2PascalString (char_u *CString, Str255 *PascalString);
   int GetFSSpecFromPath ( char_u *file, FSSpec *fileFSSpec);

--
Eckehard Berns

#1392 From: Andre Berger <andre.berger@...>
Date: Sat Jan 31, 2004 10:31 am
Subject: Fighting vim obesity
andre.berger@...
Send Email Send Email
 
Hi there,

I would like to use the Vim (6.2.214 or better)'s OS X GUI as well as
the command line interface. If I got the docs right, I have to
compile two versions, with and without a GUI, so I did. Right now,
the GUI resides in /Applications/Local/Vim.app, and the command line
version in /usr/local/share/vim/vim62. I'm sure with a clever
configuration, one could make both versions use the same runtime?

-Andre

#1393 From: Culley Harrelson <culley@...>
Date: Sat Jan 31, 2004 5:06 pm
Subject: classic vi on panther
culley@...
Send Email Send Email
 
I would like to install a copy of classic vi on panther but I can't seem to
find it anywhere.  I am having memory problems and sometimes for simple
editing using vi rather than vim is faster.  Fink doesn't have it... Anyone
know where to find an old vi binary or source?

culley

#1395 From: Eckehard Berns <ecki@...>
Date: Sat Jan 31, 2004 6:32 pm
Subject: Re: classic vi on panther
ecki@...
Send Email Send Email
 
> I would like to install a copy of classic vi on panther but I can't
> seem to
> find it anywhere.  I am having memory problems and sometimes for simple
> editing using vi rather than vim is faster.  Fink doesn't have it...
> Anyone
> know where to find an old vi binary or source?

Nvi sources can be found at http://www.bostic.com/vi/ or downloaded
directly from ftp://ftp.sleepycat.com/pub/nvi-1.79.tar.gz. Or you might
compile your own version of vim with tiny feature set to conserve
memory. Just tested this out of curiosity, and both, vim configured
with "--with-features=tiny --disable-nls --enable-gui=no" as well as
the vim installed with Panther (invoked with --noplugin), use even less
memory than nvi on my machine.

--
Eckehard Berns

#1396 From: Eckehard Berns <ecki@...>
Date: Sat Jan 31, 2004 6:42 pm
Subject: Re: Fighting vim obesity
ecki@...
Send Email Send Email
 
> I would like to use the Vim (6.2.214 or better)'s OS X GUI as well as
> the command line interface. If I got the docs right, I have to
> compile two versions, with and without a GUI, so I did. Right now,
> the GUI resides in /Applications/Local/Vim.app, and the command line
> version in /usr/local/share/vim/vim62. I'm sure with a clever
> configuration, one could make both versions use the same runtime?

You can compile the GUI version and make a symbolic link to the
executable (/path/to/Vim.app/Contents/MacOS/Vim) somewhere in your path
to start it in terminal mode (I used an alias for that). If you haven't
done so you might want to have a look at http://macvim.swdev.org/OSX/
which has excellent prepared binaries and valuable infos on Vim for Mac
OS X.

--
Eckehard Berns

Messages 1282 - 1396 of 13685   Oldest  |  < Older  |  Newer >  |  Newest
Add to My Yahoo!      XML What's This?

Copyright © 2010 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines NEW - Help