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 21:06:12 +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> <83ft6j2wep.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="39491"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 12 23:07:40 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 1kS52h-000ACA-MZ for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 23:07:39 +0200 Original-Received: from localhost ([::1]:59824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kS52g-0002QC-P8 for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Oct 2020 17:07:38 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44570) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS51S-0000ts-Et for emacs-devel@gnu.org; Mon, 12 Oct 2020 17:06:23 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:56523) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kS51Q-0006Kk-8s; Mon, 12 Oct 2020 17:06:22 -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 09CL6Fkl020879 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 12 Oct 2020 21:06:15 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09CL6bd7015152; Mon, 12 Oct 2020 21:06:37 GMT In-Reply-To: <83ft6j2wep.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 17:06:18 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:257498 Archived-At: >>> 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. > I cannot make such a judgment. But I think options should at least be explored. Would doing something like what eldoc-minibuffer-message does possibly be a good solution? It seems to me that this is safer than the current situation, as it does not fiddle with the minibuffer contents. If so, what do you (and others) think of the following: (defvar minibuffer-message-mode-line-string nil) (setq minibuffer-message-clear-timeout 3) (defun clear-minibuffer-message () (when (not noninteractive) (when (timerp minibuffer-message-timer) (cancel-timer minibuffer-message-timer) (setq minibuffer-message-timer nil)) (setq minibuffer-message-mode-line-string nil))) (defface minibuffer-message-face `((t (:background ,(face-attribute 'default :background) :foreground ,(face-attribute 'default :foreground)))) "") (defun set-minibuffer-message (message) (when (and (not noninteractive) (window-live-p (active-minibuffer-window)) (eq (window-frame) (window-frame (active-minibuffer-window)))) (progn (when (numberp minibuffer-message-clear-timeout) (setq minibuffer-message-timer (run-with-timer minibuffer-message-clear-timeout nil #'clear-minibuffer-message))) (with-current-buffer (window-buffer (or (window-in-direction 'above (minibuffer-window)) (minibuffer-selected-window) (get-largest-window))) (clear-minibuffer-message) (when (and mode-line-format (not (and (listp mode-line-format) (assq 'minibuffer-message-mode-line-string mode-line-format)))) (setq mode-line-format (list "" '(minibuffer-message-mode-line-string (" " (:propertize minibuffer-message-mode-line-string face minibuffer-message-face) " ")) mode-line-format))) (setq minibuffer-message-mode-line-string message) (force-mode-line-update)) t))) > > 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. > Where do you see an insult in what I wrote? I'm simply asking for a piece of code instead of abstract arguments. Anyway, as you said to Drew, life is too short, so I will simply continue to use my code for myself, and I hope that others will find it useful too. And if the situation has not improved in a few months, I'll ring the bell again.