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: Sat, 24 Oct 2020 10:31:25 -0700 (PDT) Message-ID: <9413ddef-3ac6-4b29-bcdc-1e452911fd05@default> References: <5f7af512-7951-4e10-a8a1-4f5d07ee6cda@default> <87eelo6iio.fsf@blind.guru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30411"; mail-complaints-to="usenet@ciao.gmane.io" Cc: juri@linkov.net, monnier@iro.umontreal.ca, Gregory Heytings , acm@muc.de, Eli Zaretskii , emacs-devel@gnu.org To: Mario Lang Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 24 19:35:22 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 1kWNRq-0007oE-9v for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Oct 2020 19:35:22 +0200 Original-Received: from localhost ([::1]:38080 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kWNRp-0001Jm-CW for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Oct 2020 13:35:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWNQT-0008Q4-9o for emacs-devel@gnu.org; Sat, 24 Oct 2020 13:33:57 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:41818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kWNQQ-0000id-U0; Sat, 24 Oct 2020 13:33:56 -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 09OHT3i2040646; Sat, 24 Oct 2020 17:33:44 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=SEjrzTdGLJ6r6YogdZddPhBT6F5yHaTRTNSEemVmZ2c=; b=DiTRWrrf95BHzuT1x8KU+3ImvwdHIqJa7c+F4TB06vZMwyc4PoseUPamEYfp2B/+fyAl hjgRNbAlAogQOHTksrwbNZ9qRFXyq1EjZZ5LQwoLWbA2BKyWu2i/cVcVkS91yF1JI4fd 6oZLIf8HcFGl/s01hL81PtlFObbyVZtWYFrK8AcXXyA8fPXmYS2JA6EIwQNOGPig4ZOp zIh0TRdIxv3p4fdMDh+9aavoqCaFmk21AoeWrRGTO7LP/yYbjXlcZc8+PuU/8avFb4tr G9CjSa1MFDIpVzYdyEpKVjhwOkF8RTwFSoPSOf611ZbzRyKZfWJphBVUkNgoGSohmC4f RA== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 34c9sah32t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 24 Oct 2020 17:33:44 +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 09OHQBiJ008800; Sat, 24 Oct 2020 17:31:44 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 34cc2yjanb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 24 Oct 2020 17:31:43 +0000 Original-Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09OHVQrY031577; Sat, 24 Oct 2020 17:31:26 GMT In-Reply-To: <87eelo6iio.fsf@blind.guru> 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=9784 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 adultscore=0 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010240137 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9784 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 impostorscore=0 mlxlogscore=999 malwarescore=0 lowpriorityscore=0 bulkscore=0 priorityscore=1501 spamscore=0 phishscore=0 clxscore=1015 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010240137 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/24 12:50:09 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, 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:258428 Archived-At: > >> > 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 content= s. > >> > If so, what do you (and others) think of the following... > >> > >> I personally feel that moving echo-area messages to the mode line is > >> too drastic a change to make it by default, and certainly in a minor > >> release. But let's hear wjat others think, and what other ideas will > >> be brought up. > > > > As I mentioned, the basic problem is due to sharing > > the same area between minibuffer and echo area. > > > > Ultimately, a good solution requires being able to > > see both at the same time. Juggling their content > > wrt time, while sharing the same space, won't take > > care of the problem in general. > > > > 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. > > > > For simple interactions, there's no problem. The > > problem arises for more complex interactions, and > > for that no "solution" that always uses the same > > space can possibly be a real solution. >=20 > For me, as a blind braille display user, using the same space in the > *only* solution that works. I only have one line of text output. Which > area of the screen this line represents is mostly controlled by the > cursor location. In essence, my attention can only be focused at one > place at a time. Magically showing messages in some other location will > not work for me at all, I will just miss them. I am fully aware that I a= m > not > representative for all Emacs users, but your wording seems to indicate > that you are neglecting the fact that there might be use cases > which do not work the way you imagine. >=20 > If your suggestion gets implemented, please dont forget to put it > behind a configuration flag. It will be the first thing I need to turn > off in .emacs. Don't worry; I think there's little chance that what I suggested will be done. And to be clear, I am in favor of the behavior we had before the recent change to automatically sticking output messages at the end of the minibuffer, instead of in the echo area. Minibuffer and echo area are in the same space on the screen, so both are presumably OK for your use. But I prefer that messages unrelated to the current minibuffer interaction (i.e., messages from `message') be shown in the echo area, and that _only_ messages related to the minibuffer interaction be appended to minibuffer input (i.e., as from `minibuffer-message'). Code should be able to use either the echo area or the end of the minibuffer, to show output when the minibuffer is active. My point was only this: IF people are worried about not noticing some messages that come out of the blue from somewhere while the minibuffer is active (because the minibuffer occludes the echo area), then a proper solution would be to use a different area for output (messages) than what is used for input. The general problem of such unnoticed messages exists. I'm not particularly bothered by it, personally. My point is only that the solution chosen isn't a good one. A real solution for dealing with asynchronous messages calls for separating the two (inputs and outputs) spatially. I'm not sure why exactly that would be problematic for you, as focus does change in Emacs in other ways anyway. But I believe you. And I appreciate your input on this. And yes, unfortunately, I hadn't thought of how blind braille display users would have to deal with such things. A real solution needs to take your use cases into account properly. Thanks for your input about this.