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: Where to show message output while inputting [was: New multi-command facility displays in the wrong echo area] Date: Tue, 13 Oct 2020 10:31:39 -0700 (PDT) Message-ID: <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="4025"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, juri@linkov.net To: Eli Zaretskii , Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Oct 13 19:32:54 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 1kSOAP-0000sR-EZ for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 19:32:53 +0200 Original-Received: from localhost ([::1]:59674 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSOAO-0004XU-H2 for ged-emacs-devel@m.gmane-mx.org; Tue, 13 Oct 2020 13:32:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40382) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSO9O-0003ED-Sr for emacs-devel@gnu.org; Tue, 13 Oct 2020 13:31:50 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:58710) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSO9M-0002W6-H2; Tue, 13 Oct 2020 13:31:50 -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 09DHIXZu183955; Tue, 13 Oct 2020 17:31: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 : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=zDr9RHHWt0srwfo9cxftDs5CEIwJEtUio0e5JK6EYaQ=; b=UA47tqG9LHmPxtUl0vxw1DgfXuLmwDnwcJ8dSSSkbcOiXWG9wUA5omEBEwqAHNx6d2gC QzdBCxuXxEiHr/PakYKKhd7pn7H1hQWlohz/zkYJuDstFUx8g5qkXpOJvfy3WlAiFoTE tuSu7wrDtIOPu2WOsJC2nss2VA5mglNR1COTfXS9rc2mvlEAnTQCv1ZsczKwt+Q7/XE1 IBcaL3lzIs0bRsD45ZTADGtx1Bwes9gHaGlmojjy6hhT+zVxRnQUjRHmN80+i1id97wP xvcwVHQ2qAhTo5dakI6mm1CnSVFyf45epolYjVv8gmif6c6iy8iXWinqCVyOPwmUt0Lj bA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2130.oracle.com with ESMTP id 343pajt3rd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 13 Oct 2020 17:31:44 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09DHJdu5077136; Tue, 13 Oct 2020 17:31:44 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 343phngqhr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 17:31:44 +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 09DHVebo008144; Tue, 13 Oct 2020 17:31:42 GMT 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 phishscore=0 spamscore=0 adultscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010130127 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-2010130127 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 13:31:45 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:257547 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 th= e > > current situation, as it does not fiddle with the minibuffer contents. > > If so, what do you (and others) think of the following... >=20 > 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. Do I think that using the mode-line makes more sense than forcing `message' output to, in effect, use `minibuffer-message', i.e., putting it at the end of your minibuffer input? Yes, probably the mode-line is usually better than that, at least. When you're responding to a prompt, anything that's not directly related to the prompt-&-response interaction doesn't belong in the input area. But we do need a real solution, assuming that we think that bug #38457 is serious enough. The fix accepted for that bug isn't healthy, as I've said. A real solution provides separate areas for echo (output) and minibuffer input. We could reserve some new area for echoing. 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. "Pop up" here could mean temporarily overwriting the mode-line, as Gregory suggested. Or it could temporarily overwrite the last line(s) of the window content. Or it could mean popping up a window or frame. Or... The point is this: 1. For simple interactions, there's no problem. Most of the time there's no overlap in time between output and input. 2. For complex interactions, i.e., when output and input overlap in time, NO solution that shares the same space really takes care of the problem. At best, we end up showing the output for some brief period of time, and then return to showing the input. And that doesn't really satisfy bug #38457. 3. To deal with #2, we need to use some separate space for output (echoes). We could either (a) always have two separate spaces (e.g. a new area for `message' etc. echoes) or (b) show echoes in some other area only when needed ("pop up"). 4. If we do choose to overwrite (hide) something in order to show output in a temporary way, then IMO it's better to overwrite/hide some buffer text, or the mode-line, than it is to do that to minibuffer input. The last thing we should hide or interfere with is the immediate user interaction (responding to a prompt by providing text input). #4 is a personal opinion. The rest should hopefully be considered less controversial. ___ https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D38457#104 (Completely ignored there.)