GNU bug report logs - #5848
23.1.95; bands of background after font change if --with-x-toolkit=no

Previous Next

Package: emacs;

Reported by: Ted Phelps <phelps <at> pobox.com>

Date: Tue, 6 Apr 2010 14:28:02 UTC

Severity: normal

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Ted Phelps <phelps <at> pobox.com>
Cc: 5848 <at> debbugs.gnu.org
Subject: bug#5848: 23.1.95; bands of background after font change if --with-x-toolkit=no
Date: Tue, 06 Apr 2010 20:54:24 +0200
Ted Phelps skrev 2010-04-06 16.25:
> After changing the default font via the options menu, my Emacs frame
> exhibits bands of the background colour along the bottom and right
> edges.  In my case these are 5 pixels wide.  Resizing the window removes
> these bands, but changing the default font re-introduces them.
> Emacs-23.1 does not exhibit this behavior.
>
> I have bisected the revision history and determined that the change
> occurred with v1.1048 of emacs/src/xterm.c:
>
>      http://osdir.com/ml/emacs-diffs-gnu/2009-10/msg00381.html
>
> To be precise, reverting the changes to pixelheight and pixelwidth at
> the beginning of the "@@ -8833,16 +8884,24 @@" blob in
> x_set_widnow_size_1 cause these bands to disappear.
>
> The definitions of FRAME_TEXT_LINES_TO_PIXEL_HEIGHT and
> FRAME_TEXT_COLS_TO_PIXEL_WIDTH already account for the frame's internal
> border, so adding them in again seems superfluous.
>

Cool, reverting those two lines makes metacity crash, over and over again. 
Oboy...

Anyhow, the external border width should not be part of pixelwidth/height, but 
there is ore to it.  Look:

/* Return the pixel width/height of frame F if it has
   COLS columns/LINES rows.  */

#define FRAME_TEXT_COLS_TO_PIXEL_WIDTH(f, cols) \
  (FRAME_COL_TO_PIXEL_X (f, cols) \
   + (f)->scroll_bar_actual_width \
   + FRAME_TOTAL_FRINGE_WIDTH (f)      \
   + FRAME_INTERNAL_BORDER_WIDTH (f))

#define FRAME_TEXT_LINES_TO_PIXEL_HEIGHT(f, lines) \
  (FRAME_LINE_TO_PIXEL_Y (f, lines) \
   + FRAME_INTERNAL_BORDER_WIDTH (f))


and

#define FRAME_INTERNAL_BORDER_WIDTH(F) ((F)->internal_border_width)

But the internal border is on two sides, so it should be 
2*FRAME_INTERNAL_BORDER_WIDTH (f).

I see that w32 also uses these macros.  Can there be trouble there if I change 
them?

I can't see the original problem though, the window manager is supposed to 
apply wm size hints so those 5 pixels disappears.

	Jan D.




This bug report was last modified 15 years and 75 days ago.

Previous Next


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