From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams 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 13:38:10 -0700 (PDT) Message-ID: <95909e9d-07d8-41de-96a5-fe13cbec3131@default> References: <5f7af512-7951-4e10-a8a1-4f5d07ee6cda@default> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32036"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 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 Tue Oct 13 22:39: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 1kSR51-0008Cd-Ie for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 22:39:31 +0200 Original-Received: from localhost ([::1]:41528 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSR50-0007Sb-Iv for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 16:39:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57856) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSR3r-0006EI-Aq for emacs-devel@gnu.org; Tue, 13 Oct 2020 16:38:19 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:35688) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSR3p-0001E3-HM; Tue, 13 Oct 2020 16:38:19 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09DKYTm4140622; Tue, 13 Oct 2020 20:38:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=fdcWBGvRN1Z5K8NwISsf9pi8COQYAfDa83NnIhlv6BE=; b=ELB5f5zIn7GpdC28mWwAwwmEVuUh5hhqtNBGr5Kwtdh7NiHhMNxiLT55glP++pdUoFxP IA/voguDc6HfJuTFH4TSaxxbKbwnHWH8Kxor9FM9WtMrzuFyzMFONYPC51+jMTJGiuu/ 1CZeZdeubR0muP46ZfM5RLne9JSXzm/e5O5mTkcr6cf+H0NNZODiKq3yiUrU+B/9hhQZ QKQmjhQNrGbLVP8iewL8USeGeDMNjgW0k8wRysOsJl4UpZP7/08kmmNSG1Rdvj7ev7E6 rlxI3z993isaFIJ0nP5PlR7uDE82+Ik2yUFnsGqqq2lv7gXBtd05aKEUk3R4gN0RaIut Vg== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 343pajtynn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Oct 2020 20:38:15 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09DKZHSw060200; Tue, 13 Oct 2020 20:38:15 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 343puyffuc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 20:38:14 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09DKcBiZ013280; Tue, 13 Oct 2020 20:38:11 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9773 signatures=668681 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 mlxscore=0 spamscore=0 adultscore=0 suspectscore=0 phishscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010130146 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9773 signatures=668681 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=0 impostorscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 adultscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010130146 Received-SPF: pass client-ip=141.146.126.79; envelope-from=drew.adams@oracle.com; helo=aserp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/13 16:36:34 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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:257582 Archived-At: > > The same problem will exist if you move output (`message' echoes) to th= e > > mode-line: you won't be able to see the mode-line info and the message > > at the same time. >=20 > That's obviously a problem that will exist in any possible solution to > that problem: the message will hide something. =20 Not if the area used for echoes (output) is separate from the area used for the minibuffer (prompt and input). Well yes, a previous message in the output area is overwritten. But it's logged in *Messages*. The point here is to separate input and output areas, so output doesn't hide prompt or input. > The question is then: what > is the "something" that can be hidden with the least possible risk? IMO > the mode-line is, in this context, the least important element, and it ca= n > be temporarily right-shifted. Eldoc does this, too. I said the same thing regarding importance, if the candidates are only the mode-line and the minibuffer. But there are other possibilities. (I mentioned using the last line(s) of some window as one.) 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. Shifting existing stuff around could be distracting or annoying for some users. A dedicated area for output wouldn't have that problem, but it would sacrifice real estate when nothing is being output. Whatever we do, it would be good to let users get different behavior as an option.=20 > > Or we could choose to echo in a separate area only when needed. E.g., > > we might use the same area for echo and minibuffer whenever there's no > > conflict (no overlap in time), and show echoes in some other place (e.g= . > > pop-up) in the rarer cases when needed. >=20 > That's exactly what my proposed solution does. The same area is used whe= n > there's no conflict, and the "pop-up" uses the space on the left of the > mode-line, which is temporarily right-shifted. Yes, I know. And I mentioned that I prefer that to appending output to the minibuffer input. But that's one of the half measures. It still occludes or displaces something. If the right end of the mode-line gets truncated because the content is right-shifted, then the truncated part is "lost" (hidden). There are half measures and full measures for the general problem. The use-the mode-line half-measure is better than the one that's been put in place for Emacs 27, IMO. > > "Pop up" here could mean temporarily overwriting > > the mode-line, as Gregory suggested. >=20 > No, the mode-line is not temporarily overwritten, it is temporarily > right-shifted. Usually (when the message is not too long) the leftmost > part of the mode-line remains visible. Got it. (I meant that, but spoke imprecisely.) IMO we can do still better. But your suggestion beats what we have now. And it beats what we had before Emacs 27 - at least in terms of not losing or obscuring user input. [IMO what we had before Emacs 27 is better than what we have now, but on n'arrete pas le progres.]