GNU bug report logs - #11052
24.0.94; Display problem under OS X Lion

Previous Next

Packages: emacs, ns;

Reported by: Richard Stanton <stanton <at> haas.berkeley.edu>

Date: Tue, 20 Mar 2012 17:28:02 UTC

Severity: normal

Found in version 24.0.94

Done: Jan Djärv <jan.h.d <at> swipnet.se>

Bug is archived. No further changes may be made.

Full log


Message #22 received at 11052-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Richard Stanton <stanton <at> haas.berkeley.edu>
Cc: 11052-done <at> debbugs.gnu.org
Subject: Re: bug#11052: 24.0.94; Display problem under OS X Lion
Date: Sat, 8 Sep 2012 14:49:01 +0200
Hello.

This is now fixed in the trunk.

	Jan D.

1 apr 2012 kl. 15:38 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

> Hello.
> 
> 1 apr 2012 kl. 01:10 skrev Richard Stanton:
> 
>> I’m running the latest version of Lion (10.7.something – I’m not in front of my Mac right now).
> 
> Ok.  I have not found any rationale for this behaviour, it has always been in the NS port.  I guess the idea was that it looks better of the fringe also covers the internal border width.  But it isn't done right, as you have discovered.
> 
> But since this is not a regression from 23.4, I guess it will have to wait for the 24.2 release.
> 
> 	Jan D.
> 
>> 
>> From: Jan Djärv [mailto:jan.h.d <at> swipnet.se] 
>> Sent: Saturday, March 31, 2012 10:57 AM
>> To: Richard Stanton
>> Cc: 11052 <at> debbugs.gnu.org
>> Subject: Re: bug#11052: 24.0.94; Display problem under OS X Lion
>> 
>> Hello.
>> 
>> 20 mar 2012 kl. 18:52 skrev Richard Stanton:
>> 
>> 
>> The truncated numbers and line of extra pixels both go away if you execute M-x fringe-mode -> no-fringes, so I suspect a counter in the left-fringe code may be off by a few pixels somewhere.
>> 
>> You are correct, there is some strange adjustment going on in ns_draw_fringe_bitmap:
>> 
>>  /* NS-specific: move internal border inside fringe */
>>  int x = p->bx < 0 ? p->x : p->bx;
>>  int wd = p->bx < 0 ? p->wd : p->nx;
>>  BOOL fringeOnVeryLeft
>>    = x - WINDOW_LEFT_SCROLL_BAR_COLS (w) * WINDOW_FRAME_COLUMN_WIDTH (w)
>>      - FRAME_INTERNAL_BORDER_WIDTH (f) < 10;
>>  BOOL fringeOnVeryRight
>>    = FRAME_PIXEL_WIDTH (f) - x - wd - FRAME_INTERNAL_BORDER_WIDTH (f)
>>      - WINDOW_RIGHT_SCROLL_BAR_COLS (w) * WINDOW_FRAME_COLUMN_WIDTH (w) < 10;
>>  int xAdjust = FRAME_INTERNAL_BORDER_WIDTH (f) *
>>    (fringeOnVeryLeft ? -1 : (fringeOnVeryRight ? 1 : 0));
>> 
>> Now, if you set xAdjust unconditionally to zero, the problem goes away.  I don't yet know the rationale for this.  It may be something that was needed at some point, or is needed on some systems.  What OSX version are you running?
>> 
>>          Jan D.
> 





This bug report was last modified 12 years and 258 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.