Hello.

1 apr 2012 kl. 01:10 skrev Richard Stanton:


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@swipnet.se] 
Sent: Saturday, March 31, 2012 10:57 AM
To: Richard Stanton
Cc: 11052@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.