From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: New multi-command facility displays in the wrong echo area. Date: Mon, 12 Oct 2020 16:31:27 +0000 Message-ID: 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> <83mu0r3030.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9274"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: juri@linkov.net, acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 18:32:36 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 1kS0kW-0002IJ-Mn for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 18:32:36 +0200 Original-Received: from localhost ([::1]:49172 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS0kV-0008DX-Ox for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 12:32:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42692) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS0jc-0007by-U2 for emacs-devel@gnu.org; Mon, 12 Oct 2020 12:31:40 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:62266) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS0ja-0006U9-AE; Mon, 12 Oct 2020 12:31:40 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 09CGVVPG012446 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 12 Oct 2020 16:31:32 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09CGVsZ8008678; Mon, 12 Oct 2020 16:31:54 GMT In-Reply-To: <83mu0r3030.fsf@gnu.org> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/12 11:41:42 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:257476 Archived-At: >>> 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. > Indeed, this would also work: (< (mod (car (window-text-pixel-size (active-minibuffer-window))) (window-text-width (active-minibuffer-window) t)) (/ (car (window-text-pixel-size (active-minibuffer-window))) 2)) But going in that direction means that one should also take the current window height into account: if the miniwindow is tall enough, the above condition could be nil even though there would be enough room to display the message. >> 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. > Ouch. So this last-minute change will last for several years? >> 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. > I do not suggest anything like that. But I'm a doubting Thomas, and I can't give you this credit until I see a recipe that would convincingly demonstrate a potential problem that my proposed solution would create. Especially given I explained that this solution is only _at the moment_ the best solution, for earlier versions and the current version of Emacs, until a better solution is implemented.