From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 19:01:23 +0300 Message-ID: <83mu0r3030.fsf@gnu.org> References: <20201009163445.GB4027@ACM> <20201009203810.GC4027@ACM> <83imbi609a.fsf@gnu.org> <20201010103233.GB5662@ACM> <834kn25o6b.fsf@gnu.org> <20201010124446.GC5662@ACM> <831ri65jpc.fsf@gnu.org> <83zh4u44mx.fsf@gnu.org> <83imbg4yl3.fsf@gnu.org> <837drv4ij6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18440"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 18:17:20 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kS0Vj-0004fP-D6 for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 18:17:19 +0200 Original-Received: from localhost ([::1]:55102 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS0Vi-0006OJ-Eb for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 12:17:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34842) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS0GH-0000sv-A0 for emacs-devel@gnu.org; Mon, 12 Oct 2020 12:01:21 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45438) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS0GF-0002DZ-Ge; Mon, 12 Oct 2020 12:01:19 -0400 Original-Received: from [176.228.60.248] (port=2230 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kS0GE-00033x-Es; Mon, 12 Oct 2020 12:01:18 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 12 Oct 2020 15:41:35 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:257473 Archived-At: > Date: Mon, 12 Oct 2020 15:41:35 +0000 > From: Gregory Heytings > cc: Juri Linkov , acm@muc.de, monnier@iro.umontreal.ca, > emacs-devel@gnu.org > > > In any case, I think the condition could be relaxed: we only care about > > how much space is left from the minibuffer text's end till the end of > > the screen line, so "if minibuffer text size modulo window-width is less > > than something" would be better, I think. E.g., if you use 70 instead > > of 67 in your recipe, the problem is mostly gone. > > The condition could be refined indeed, but the modulo operation you > propose would not work with variable pitch faces. It will, if the calculation is done in pixels. The APIs you mentioned can return pixels instead of columns, or there are alternatives which do. > I intentionally proposed something simple, which should work in > (almost) all cases. I'm an adept of the KISS principle. Me too; "the solution should as simple as possible, but not simpler." > > Also, it would be safer to use string-width instead of the number of > > characters, or even window-text-pixel-size: some people do customize the > > faces used in the minibuffer. > > I won't comment on this. As I already said elsewhere, it's IMO awful to > expect any code to do something like this. That function was written because it's really needed and useful. We use it under the hood, and I see no reason not to use it in this case, which is exactly one of the cases for which the function was implemented. > See above. I've now read that bug thread, and I'm not at all convinced > that the chosen solution was TRT, quite the contrary. We can discuss other solutions, of course. However, significant changes will have to wait for Emacs 28. > It seems to me that being wiser would mean taking the time to evaluate a > proposed solution, instead of rejecting it outright based on a gut > feeling. Please give me the credit of having done so. I've given you no reason to believe otherwise; disagreement doesn't imply incompetence or sloppiness on my part. It is simply unfair and even rude to suggest that.