From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Dallas Gray Newsgroups: gmane.emacs.bugs Subject: bug#15886: 24.3.50; Incorrect window-text-height with non-zero line-spacing Date: Thu, 14 Nov 2013 19:24:42 +0000 Message-ID: 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> <83fvqyzwk7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1384457112 23568 80.91.229.3 (14 Nov 2013 19:25:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Nov 2013 19:25:12 +0000 (UTC) Cc: 15886@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 14 20:25:17 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 1Vh2XU-00052f-50 for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2013 20:25:16 +0100 Original-Received: from localhost ([::1]:57059 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh2XT-0006UH-NN for geb-bug-gnu-emacs@m.gmane.org; Thu, 14 Nov 2013 14:25:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh2XM-0006Sc-6a for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 14:25:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vh2XG-0006bk-Hv for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 14:25:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:38566) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vh2XG-0006bc-F3 for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 14:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vh2XF-0000bk-LR for bug-gnu-emacs@gnu.org; Thu, 14 Nov 2013 14:25:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Robert Dallas Gray Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Nov 2013 19:25:01 +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.13844570942321 (code B ref 15886); Thu, 14 Nov 2013 19:25:01 +0000 Original-Received: (at 15886) by debbugs.gnu.org; 14 Nov 2013 19:24:54 +0000 Original-Received: from localhost ([127.0.0.1]:52585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh2X8-0000bN-15 for submit@debbugs.gnu.org; Thu, 14 Nov 2013 14:24:54 -0500 Original-Received: from mail-we0-f180.google.com ([74.125.82.180]:52073) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vh2X5-0000b9-UW for 15886@debbugs.gnu.org; Thu, 14 Nov 2013 14:24:52 -0500 Original-Received: by mail-we0-f180.google.com with SMTP id u57so2027036wes.25 for <15886@debbugs.gnu.org>; Thu, 14 Nov 2013 11:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=robertdallasgray.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vy95ebvTJH9a8UvYMeLzNPoh9q6+RQRWT68arzMw2Pg=; b=D0/ilZB/nch4Vb3RX0Lqf5r3j0Wxg4D2ciqJyHmQsQLfCW9NSm5klX8NI3nAhoU2SP VRhGLqhB7PnXz1dKmQiiPZ/ZUVCdazMGJ7sy5gGi8eWhL1FQh6sftPHLYIDWs/3xXUWw bKyNGDOn7joZVJwbSgB7JxQgPMw7FwXqSwenw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Vy95ebvTJH9a8UvYMeLzNPoh9q6+RQRWT68arzMw2Pg=; b=eH8YqW9xLe/A0egE9RkMvtyeCeNeODWUY/GQCOXQNy8gP4/lv2N/J1W39u9xhSpZqy 1KaeEsyfFrZ9Szlro/CBIEk76NOxoqTfc05o1bmXS/XrCmympUNBiEWixdbskalr91Aa iu8GeHr6uiWDmYJQr1z+RLgDdYxhipfVNg3LwSSRYngjidFpr9Pf+M0Wn5OpQRZrNfqw nssuOn6lJgRUWfFWsszDI/u5uV3KmocYu0/uw93Adi0U8taSa53+bu32LMJYPboqMbDT 2K8Aj+4Nz+oPdE5dgNeGxoH/fwzpOFpehyEIse2yLn4M+N43FLgN6OTdUqWfp1o149LT uAvw== X-Gm-Message-State: ALoCoQkIUSU+0x6OlTIRS0wZcBUbDsp7DUF7nYX9dnEj3fF+CZGOldJkohXnEHpaxk0dVhIuLqEd X-Received: by 10.181.12.75 with SMTP id eo11mr4221262wid.37.1384457086071; Thu, 14 Nov 2013 11:24:46 -0800 (PST) Original-Received: from [192.168.1.203] ([2.28.52.80]) by mx.google.com with ESMTPSA id x19sm1624230wia.5.2013.11.14.11.24.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Nov 2013 11:24:45 -0800 (PST) In-Reply-To: <83fvqyzwk7.fsf@gnu.org> X-Mailer: Apple Mail (2.1822) 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:80451 Archived-At: On 14 Nov 2013, at 18:07, Eli Zaretskii wrote: > [You forgot to CC the bug address.] >=20 Apologies. > A side question: why does grizzl resize the minibuffer by hand, > instead of letting the display engine do that? >=20 No idea I'm afraid. I've linked to this bug in the issue I've raised on = the Github repo, so perhaps the maintainer will drop in and enlighten = us. > 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. >=20 I did try the suggestion (or something like it), yes, and it resulted in = the 'bouncing' I mentioned. I agree with your last couple of sentences, which is why my current = workaround is to set line-spacing to nil in the minibuffer. But if it = were possible to size the window in pixels, even the edge case you = describe could be avoided. > 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. >=20 For sure. > 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. >=20 > 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 ;-). >=20 Well, I'd contend (as a former book designer) that line-spacing is *by = its nature* an integral part of the height of a line of text (the clue's = in the name).=20 >=20 > 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. >=20 We can determine the height of a line of text in the relevant face, and = its line-spacing, in pixels, and create a simple algorithm to calculate = the total height of a given number of lines. > 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. >=20 Again, for sure. If it's a hard limitation of Emacs, so be it. > 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. Again, I dunno. I'm not the author, and I'm crediting him with having = done things the way he has for good reasons. Hopefully he'll show up at = some point and explain. In the meantime, I'd suggest we shelve this one. Thanks a lot for taking = the time to engage.