From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing Date: Thu, 14 Nov 2013 20:07:36 +0200 Message-ID: <83fvqyzwk7.fsf@gnu.org> References: <8D614196-65E4-4F20-AAFE-CCFDC32D9898@robertdallasgray.com> <83a9h811r7.fsf@gnu.org> <4D2C9983-9E63-44F6-83A6-3D306B9EC79C@robertdallasgray.com> <837gcc116m.fsf@gnu.org> <834n7g0zq1.fsf@gnu.org> <2D715343-65B4-4759-95C1-D3DA8A3F7598@robertdallasgray.com> <831u2j1wbl.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1384452554 30641 80.91.229.3 (14 Nov 2013 18:09:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Nov 2013 18:09:14 +0000 (UTC) Cc: 15886@debbugs.gnu.org To: Robert Dallas Gray Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 14 19:09:19 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Vh1Ly-00064C-1t for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2013 19:09:18 +0100 Original-Received: from localhost ([::1]:56739 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh1Lx-0001S0-It for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2013 13:09:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh1Lo-0001I9-E3 for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 13:09:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vh1Lj-000228-5E for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 13:09:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38441) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh1Lj-000223-2T for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 13:09:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vh1Li-0004sL-GG for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 13:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2013 18:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15886 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15886-submit@debbugs.gnu.org id=B15886.138445248318671 (code B ref 15886); Thu, 14 Nov 2013 18:09:02 +0000 Original-Received: (at 15886) by debbugs.gnu.org; 14 Nov 2013 18:08:03 +0000 Original-Received: from localhost ([127.0.0.1]:52458 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh1Kk-0004r4-Eq for submit@debbugs.gnu.org; Thu, 14 Nov 2013 13:08:02 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:55506) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh1Kh-0004qU-9B for 15886@debbugs.gnu.org; Thu, 14 Nov 2013 13:08:00 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MW900000M6SU300@a-mtaout20.012.net.il> for 15886@debbugs.gnu.org; Thu, 14 Nov 2013 20:07:52 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MW9000F8MD4U810@a-mtaout20.012.net.il>; Thu, 14 Nov 2013 20:07:52 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80442 Archived-At: [You forgot to CC the bug address.] > Date: Thu, 14 Nov 2013 09:22:14 +0000 > From: Robert Dallas Gray > > See the screenshot here: > > https://github.com/d11wtq/grizzl > > >From the bottom, you can see: a text entry area; an information line; and > then a list of candidate files (this is Grizzl used for completing read > over project files). > > All three of these elements, if I'm reading the code correctly, are > contained in the mini buffer window, which resizes dynamically as the list > of candidate files grows or shrinks. > > For this to look right, it must be possible to set the size of the window > to a given number of lines as the number of candidates changes. The > library's maintainer uses 'set-window-text-height' to do this (see > https://github.com/d11wtq/grizzl/blob/master/grizzl-read.el#L141). A side question: why does grizzl resize the minibuffer by hand, instead of letting the display engine do that? > In the case where line-spacing is non-zero, 'set-window-text-height' > doesn't size the window correctly, as we've discussed. If we use a 'rough' > number of lines based on the ratio described by Eli, then much of the time > the window will also not be sized correctly, and as the list of candidates > changes size, the baseline of the window (the text entry line) will > 'bounce'. This problem cannot be avoided entirely, and if it exists (did you actually try my suggestion?), then the package has it already. Those 2 lines, the "information line" and the line showing the best candidate, they both use special faces, don't they? If so, the same problem will happen if one or both of these faces will use a different font. IOW, you cannot resize a window "exactly" like you would like to, in a GUI session, simply because the Emacs display features are too many to take everything into account, certainly if one works only on the Lisp level. You could say that users should not shoot themselves in the foot by customizing these faces so as to disrupt the display of grizzl, but then I could tell you the same about using line spacing. > I can see that it's not possible to give an accurate window-text-height in > the case of a display where fonts of multiple sizes might be used in the > same buffer, but should it not at least take into account the global > setting of line-spacing, and the height of the default font? I don't see how line-spacing is different from any other feature that affects the height of a line (except that you use the former, but not the latter ;-). > And, if it's impractical to fix this, is there a way to set the > height of the window in pixels rather than lines so that the same > effect can be achieved? What makes you think that setting window height in pixels would solve this issue? Granted, the "jitter" would probably be smaller, but a human eye can easily spot even a 1-pixel jitter, and be no less annoyed. What I'm trying to tell is that it is simply impossible to control the Emacs display in Lisp to such a degree of precision, not with the way the display engine is currently designed and implemented. Whoever designs packages which try to do that should be acutely aware of these limitations in the first place, and if they don't avert her, at least mention them in some prominent place. Btw, I don't really see why there was a need for using the minibuffer here. Why not code a customized *Completions* buffer instead? That would at least make sure the "text entry area" could simply use the minibuffer, which would then remain of a constant height, ever.