[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14233: 24.3; Don't constrain frame size to character multiples

From: martin rudalics
Subject: bug#14233: 24.3; Don't constrain frame size to character multiples
Date: Tue, 23 Apr 2013 08:52:08 +0200

>> change_frame_size has no idea whether it is called for a text or a
>> graphical frame.
> That is done very easily, given the frame pointer (which
> change_frame_size accepts as its 1st argument).  E.g.:
>   if (FRAME_WINDOW_P (f))
>     /* do the GUI thing */

A couple of weeks ago I asked you whether HAVE_WINDOW_SYSTEM would be
sufficient but got no answer :-( The problem is that I'm still not sure
whether FRAME_WINDOW_P is sufficient.  At least in frame.c all
FRAME_WINDOW_P calls are guarded by HAVE_WINDOW_SYSTEM checks as

      if (FRAME_WINDOW_P (XFRAME (this)))

so some doubt remains whether this predicate is correctly installed on
every platform.  In any case I'd want either an #ifdef or a simple and
robust predicate without having to care about #ifdefs.

>> Text frames might want to call it as before using character sizes.
> On text-mode frames, each character is one pixel.  Emacs knows that
> already.

In the past weeks I started to doubt whether Emacs really knows
everything it pretends to know.

>> In any case, the callers have to strip space used for tool- or
>> menubars because change_frame_size does not know whether these are
>> part of the frame or not.
> Why can't change_frame_size know that?

The callers should know best whether a toolbar is part of their frames
or not.  But we could obviously teach change_frame_size to check that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]