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: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area] Date: Tue, 13 Oct 2020 20:59:17 +0000 Message-ID: References: <5f7af512-7951-4e10-a8a1-4f5d07ee6cda@default> <95909e9d-07d8-41de-96a5-fe13cbec3131@default> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6733"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: Eli Zaretskii , acm@muc.de, juri@linkov.net, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 13 23:00: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 1kSRPQ-0001fb-Rg for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 23:00:36 +0200 Original-Received: from localhost ([::1]:47108 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSRPP-0005li-Rs for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 17:00:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35370) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSROQ-0005HN-2S for emacs-devel@gnu.org; Tue, 13 Oct 2020 16:59:34 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:55233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSRON-0004Ga-Ox; Tue, 13 Oct 2020 16:59:33 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 09DKxK9Y008189 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 13 Oct 2020 20:59:20 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 09DKxKg7023435; Tue, 13 Oct 2020 20:59:20 GMT In-Reply-To: <95909e9d-07d8-41de-96a5-fe13cbec3131@default> 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/13 15:22:16 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:257589 Archived-At: >>> The same problem will exist if you move output (`message' echoes) to >>> the mode-line: you won't be able to see the mode-line info and the >>> message at the same time. >> >> That's obviously a problem that will exist in any possible solution to >> that problem: the message will hide something. > > Not if the area used for echoes (output) is separate from the area used > for the minibuffer (prompt and input). > I meant: it will hide something on screen. For example with a conventional pop-up it would hide a part of a buffer. > > But we need not overwrite - or displace at all, if we show the output in > its own area - at least when there would otherwise be a conflict with > the minibuffer/echo area. I mentioned "popping up" such an output area > as needed. > Yes, that's the idea of temporariy adding a "zeroth" / "minusoneth" line to the miniwindow in which the message would be shown. But it will still hide something, namely another line in that frame. > > Shifting existing stuff around could be distracting or annoying for some > users. > It's what eldoc already does for a similar situation, and I haven't seen complaints about this. IMO it's elegant to solve that problem in that way. BTW, if you don't shift the contents of the mode-line, you shift the contents of the buffer(s) above the mode-line. Which could also be distracting or annoying, because such a shift could imply a temporary recentering of these buffers in their windows, when point is on their last line.