From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#34939: Some minibuffer behaviour is annoying Date: Mon, 8 Apr 2019 15:00:59 -0700 (PDT) Message-ID: References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="121673"; mail-complaints-to="usenet@blaine.gmane.org" Cc: pinkanon pinkanon , 34939@debbugs.gnu.org To: Juri Linkov , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 09 00:02:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDcLK-000VXz-Oy for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Apr 2019 00:02:19 +0200 Original-Received: from localhost ([127.0.0.1]:59610 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDcLJ-0006tK-RW for geb-bug-gnu-emacs@m.gmane.org; Mon, 08 Apr 2019 18:02:17 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDcL6-0006oY-6S for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 18:02:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDcL4-000436-UD for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 18:02:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36730) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hDcL4-00041p-IX for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 18:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hDcL4-0003Dq-8T for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2019 18:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2019 22:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34939 X-GNU-PR-Package: emacs Original-Received: via spool by 34939-submit@debbugs.gnu.org id=B34939.155476087512330 (code B ref 34939); Mon, 08 Apr 2019 22:02:02 +0000 Original-Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 22:01:15 +0000 Original-Received: from localhost ([127.0.0.1]:50274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDcKI-0003Cn-Vt for submit@debbugs.gnu.org; Mon, 08 Apr 2019 18:01:15 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:58020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDcKH-0003CZ-Am for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 18:01:13 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38LxPZ8112664; Mon, 8 Apr 2019 22:01:06 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-2018-07-02; bh=c+3nZiVCa2Axu8ds3Td6o0gTz5UzPGXhLCi6cMjzB1g=; b=jKC7GMUlrswkZCFbW3z2+2ZdxdEA2xpvf8T5641zux6EnICgRd6ufWh6y83EnDiIQ2+a 3QreNkxQv1/bPK60jXlS8bEH1wv2R7QrhN//oxLiVbAXIa6NW4ql/5Wzjzhf0PjiADLu 9u7Ohj4svubSh0nBmbD/7jyVZ5dXAkMpCNqgaiSGAwoUiA3PrV/lr5da3YTJDYc0n74n mr+QjXRfsrdknGAU9PWAqmmzMuJYbeUZ66zDLb2aJIp2yd3IeSvlruhMHGN0AgrTcwo8 V+xWGUxtucPgK4j3bz+HDE6FeeHJQ3wT3pOoP43O8lsebslMwco5DUiOFHxjMV7sEtMU Pg== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2rpkhssc9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 22:01:05 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38LxVjd127262; Mon, 8 Apr 2019 22:01:04 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2rpj5a7hrh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 22:01:04 +0000 Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x38M10UF031640; Mon, 8 Apr 2019 22:01:01 GMT In-Reply-To: <877ec4wa7c.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080160 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080160 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157366 Archived-At: > >> Another variant is to extend 'echo_area_display' to use > >> 'minibufer-message' in case of the active minibuffer. > > > > I think I'd like that. Guess the only downside is having to decide > > whatever's going to happen when the current minibuffer contents are > > too long for the area to accommodate both them and the message? >=20 > I see no downsides - using minibuffer-message already does the right > thing: it resizes the minibuffer area. Apologies for not following this thread. My impression is that you might be trying to make messages, when the minibuffer is active, always use `minibuffer-message' and never `message'. If so, that would be a very bad thing. Not only simplistic but misguided. The two behaviors are quite different, and both can be useful during an interaction while the minibuffer is active. `message' replaces the content of the minibuffer momentarily. `minibuffer-message' does not replace the content but adds to it (mixes with it). I'm sure you're aware of this difference, so I'm confused why youwould think it might be a good idea to make Emacs always use `minibuffer-message'. I'm hoping I've simply misunderstood what you're up to. In a way those are two different levels/dimensions of minibuffer messaging - at least they can be used to that effect. Their difference is just what I stated. Their uses follow from their difference - use each behavior for its particular effect. It's silly to think that either of them is useless or inappropriate, in some blanket way. Each of them can be useless or inappropriate in a given context, and each can be useful and helpful in a given context. I have lots of code that interacts with the minibuffer, in all kinds of way, including dialogs that involve multiple buffers and multiple levels of minibuffers. There is not only _one_ kind of minibuffer-user interaction. It's a judgment call which function (`message' or `minibuffer-message') to use in a specific context. No simple rule can replace such design/judgment. User interactions can take all kinds of forms, with and without the minibuffer. Being able to get the `message' behavior when the minibuffer is active is essential - an important tool in our tool chest. Please do not try to remove that tool. `message' interrupts minibuffer use with echo-area messaging - it's good for that purpose. `minibuffer-message' does not interrupt temporally; it interrupts minibuffer content spatially. It's not about echo-area display inappropriately "concealing" the minibuffer. It's about that display appropriately interrupting it temporarily (controlled by application, not by some silly Emacs built-in lockdown restriction). If you're toying with the idea of replacing `message' behavior with `minibuffer-message' behavior when the minibuffer is active, please ask yourselves what the _real_ problem is that you're trying to solve. I'm sure that's not its solution. (FWIW, I don't see anything in the original problem description that would invite such a "solution".) That a programmer _can_ create a lousy dialog with users, "concealing" minibuffer input inappropriately, should not cause Emacs itself to try to second-guess programmers by preventing them from defining dialogs of all sorts. That's the opposite of Emacs. This, BTW, is completely wrong: > Messages in the echo area should never conceal the minibuffer. Period. > There is a special function minibuffer-message for this purpose Neither of those statements is correct. IMO, such a doctrinaire posture belies ignorance of the spectrum/space of possible minibuffer uses. Thx.