From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: size hints and tiling window managers Date: Sat, 08 Dec 2012 11:01:42 +0200 Message-ID: <838v98nci1.fsf@gnu.org> References: <87zk1r104d.fsf@bernoul.li> <50C1C678.5040805@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354957335 24057 80.91.229.3 (8 Dec 2012 09:02:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 8 Dec 2012 09:02:15 +0000 (UTC) Cc: rudalics@gmx.at, jonas@bernoul.li, emacs-devel@gnu.org To: James Cloos Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 08 10:02:28 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ThGIl-0004No-CX for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2012 10:02:27 +0100 Original-Received: from localhost ([::1]:41459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThGIY-0006c1-SD for ged-emacs-devel@m.gmane.org; Sat, 08 Dec 2012 04:02:14 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThGIS-0006bs-8v for emacs-devel@gnu.org; Sat, 08 Dec 2012 04:02:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ThGIN-0002Q4-JT for emacs-devel@gnu.org; Sat, 08 Dec 2012 04:02:08 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:37443) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ThGIN-0002P4-B1 for emacs-devel@gnu.org; Sat, 08 Dec 2012 04:02:03 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MEP00H00FOM2K00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 08 Dec 2012 11:02:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MEP00G3FFR9HCD0@a-mtaout20.012.net.il>; Sat, 08 Dec 2012 11:01:58 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155360 Archived-At: > From: James Cloos > Date: Fri, 07 Dec 2012 20:42:00 -0500 > Cc: martin rudalics , Jonas Bernoulli > > >>>>> "mr" == martin rudalics writes: > > mr> Eli said that he can provide arbitrary frame pixel sizes at any time. > > Doesn't it just require not setting the .width_inc and .height_inc > members of the size_hints struct in src/xterm.c and src/gtkutil.c, > and editing the .min_width and .min_height code to account for that? If you are asking me, I don't think I understand the problem well enough to answer. For starters, I don't understand how the "extra space" you were talking about in your original report came into being. Specifically, what did Emacs ask for and what did the window manager do instead? > Something like the (as yet untested, and X-only) code below? Maybe I'm missing something, but all your changes do is refrain from setting the width_inc and height_inc members of the XSizeHints structure. Can you explain how does this solve the problem? Emacs _does_ want its frame size be a multiple of FRAME_COLUMN_WIDTH; if we don't ask the wm to do that, won't that produce bad display on _all_ window managers, instead of just some that ignore the hints? And when a wm is involved that doesn't honor the increment hints, what will happen if we don't set those members of the XSizeHints structure? > If so, I presume that it should be configurable, yes? I'd prefer we fix this particular problem: > Emacs does the same thing: it paints the extra space using the > background color of the default face. The problem is that Emacs frames > may also have fringes which usually don't have the same background > color. As a result Emacs draws a "line" with the same color as *the* > background color to the right of the right fringe (and below the echo > area). Can you show a screenshot of this? Also, what would be a good solution to this problem? make the right fringe wider? something else? > 2. However I think it would be better if Emacs would just use any window > size without having to paint some extra space to the right and below > of the "actual" content. One way of doing that could be to > dynamically adjust the width of the fringes (and the height of the > minibuffer/echo area). Changing the width of the fringes dynamically is easy, actually, because we already do so, albeit triggered by user commands. Echo are is harder, because it's just a window, so its size must currently be a multiple of the default font's size. Perhaps we could modify the mode-line width instead, by changing the line-with attribute of the mode-line face. Can you try that? > Since buffers can contain text that have a different width than that > of the default face relying on size hints does not guarantee that > text is never cut of in the middle of a character. That is true (and Emacs already supports these situations, as you probably know), but that's not the reason for the issue at hand. The reason is that Emacs redisplay works in 2 distinct stages. In the first stage, a device-independent part of the display engine generates a structure, called "glyph matrix", which holds, for each character that is visible in an Emacs window, a structure called "glyph" with sufficient information to draw that character. Each window has its own glyph matrix. In the second stage, the glyph matrix is handed to the device-dependent part of the display engine, which actually draws the glyphs. It should be clear that the device-independent stage _must_ produce a glyph for every character, even if that character is only partially visible. And since the number of glyphs is always integer, you get the limitation of the integral multiple of frame font's size. IOW, the issue here is _not_ that we cannot draw partially visible character -- we can -- but that the glyph matrix _dimensions_ must be integers. The current limitation exists because asking the wm to observe the same restrictions was the easiest way of reconciling an internal requirement of integer dimensions of the glyph matrices with the fact that GUI frames are drawn and sized in pixels.