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 20:20:46 +0300 Message-ID: <83ft6j2wep.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> <83mu0r3030.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28936"; 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 19:21:31 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 1kS1Vq-0007P3-4p for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 19:21:30 +0200 Original-Received: from localhost ([::1]:33844 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS1Vp-0006Km-7I for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 13:21:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53292) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS1V4-0005tr-H1 for emacs-devel@gnu.org; Mon, 12 Oct 2020 13:20:43 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47101) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS1V3-00049K-6H; Mon, 12 Oct 2020 13:20:41 -0400 Original-Received: from [176.228.60.248] (port=3524 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kS1V2-000775-Ie; Mon, 12 Oct 2020 13:20:41 -0400 In-Reply-To: (message from Gregory Heytings on Mon, 12 Oct 2020 16:31:27 +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:257486 Archived-At: > Date: Mon, 12 Oct 2020 16:31:27 +0000 > From: Gregory Heytings > cc: juri@linkov.net, acm@muc.de, monnier@iro.umontreal.ca, emacs-devel@gnu.org > > 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. You mean, if the message to be displayed in the minibuffer uses large fonts or includes tall images? In that case, we will simply display the single line with partially-visible text/image (assuming max-mini-window-height doesn't allow to resize to see all of it), and I don't see what can be done about that. It is highly unusual for messages to use such faces or images, and if some features do that, users of those features should be told to not limit the mini-window height to a size that's too small. > > 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? Unless we can come up with a change that is either simple or safe. Or if we decide that the current situation is so unacceptable that we are willing to take higher risks of releasing a less stable Emacs 27.2. > > 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. I cannot help you with your doubts more than I already did. If you still have those doubts, I'd appreciate if you keep them to yourself, because having them written here is an insult I don't think I deserve.