From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Fri, 13 Dec 2019 01:07:39 +0200 Organization: LINKOV.NET Message-ID: <87zhfxjf9w.fsf@mail.linkov.net> References: <8736e3vve8.fsf@gmx.net> <8736e2coyv.fsf@mail.linkov.net> <83y2vujd0y.fsf@gnu.org> <87blspm0sm.fsf@mail.linkov.net> <837e3ckbem.fsf@gnu.org> <871rtjn0kt.fsf@mail.linkov.net> <83lfrrigj8.fsf@gnu.org> <87eexiqps5.fsf@mail.linkov.net> <83lfrphp94.fsf@gnu.org> <87wob7g2jk.fsf@mail.linkov.net> <83k177ebs0.fsf@gnu.org> <87muc27prn.fsf@mail.linkov.net> <83tv6acgq5.fsf@gnu.org> <87eexdoygh.fsf@mail.linkov.net> <83tv68c0nb.fsf@gnu.org> <83h828b0lz.fsf@gnu.org> <83r21aak51.fsf@gnu.org> <87eexabg41.fsf@mail.linkov.net> <83blse9kbj.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="88569"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 38457@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 13 00:46:35 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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ifYAE-000Mq1-GU for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Dec 2019 00:46:35 +0100 Original-Received: from localhost ([::1]:38540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifYAC-0003M2-PA for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Dec 2019 18:46:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42102) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifY9t-0003LJ-AH for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2019 18:46:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifY9r-0001KA-M8 for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2019 18:46:13 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55080) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ifY9j-0001HD-TE for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2019 18:46:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ifY9j-0004xp-SC for bug-gnu-emacs@gnu.org; Thu, 12 Dec 2019 18:46:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Dec 2019 23:46:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38457 X-GNU-PR-Package: emacs Original-Received: via spool by 38457-submit@debbugs.gnu.org id=B38457.157619434118952 (code B ref 38457); Thu, 12 Dec 2019 23:46:03 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 12 Dec 2019 23:45:41 +0000 Original-Received: from localhost ([127.0.0.1]:32811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifY9N-0004vc-D2 for submit@debbugs.gnu.org; Thu, 12 Dec 2019 18:45:41 -0500 Original-Received: from bisque.elm.relay.mailchannels.net ([23.83.212.18]:38091) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifY9L-0004vR-HK for 38457@debbugs.gnu.org; Thu, 12 Dec 2019 18:45:40 -0500 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6E0DF580ED4; Thu, 12 Dec 2019 23:45:38 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a65.g.dreamhost.com (100-96-45-231.trex.outbound.svc.cluster.local [100.96.45.231]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id DD9795811C7; Thu, 12 Dec 2019 23:45:37 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a65.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 12 Dec 2019 23:45:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Army-Army: 37164bb00d5904fe_1576194338153_1282477831 X-MC-Loop-Signature: 1576194338153:762460567 X-MC-Ingress-Time: 1576194338153 Original-Received: from pdx1-sub0-mail-a65.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTP id 8A1447F223; Thu, 12 Dec 2019 15:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=ka3wfoOSRrpoCqUv+WoZvbMqXng=; b= RnUl7NRr9vFnTi3WMWS6NJpWE01qikCIuhmC8fHKgcB/MLhsXy+o/wbo3cjsKTJK Z4UHx/ORMkps/lRkpAbNdAi5BxqPFdVb4tGeGHal6DWP995KNavf5F/dTj3zNqfS VT9IrtfTHS/AzX9yULJY0whEBEhb+PXaiXej9coqpCU= Original-Received: from mail.jurta.org (m91-129-96-42.cust.tele2.ee [91.129.96.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a65.g.dreamhost.com (Postfix) with ESMTPSA id D117B7F219; Thu, 12 Dec 2019 15:45:31 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a65 In-Reply-To: <83blse9kbj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 12 Dec 2019 07:36:32 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudelkedgudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdeliedrgedvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirdegvddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegvlhhiiiesghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedv 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:173230 Archived-At: >> The problem is in usability: it would be very annoying if the message >> displayed at the end of the minibuffer's contents would not vanish >> after some time. minibuffer-message removes the message >> after 2 sec by default. > > But 'message' always behaved this way, so using a timeout is change in > behavior, whereas my proposal leaves the behavior unchanged, and just > makes the prompt still visible, so it avoids confusing the user. User > confusion was the main issue that triggered the series of changes we > are discussing, and it will be resolved by my proposal. But 'minibuffer-message' never behaved this way because it's very annoying when messages remain indefinitely in the minibuffer, and a key is needed to be pressed to flush mostly useless messages away. Messages in the echo-area and messages in the minibuffer are different things for user interaction. Most messages are useless, but they don't get into the way of editing in a buffer when the minibuffer is not active and useless messages are displayed in the echo-area far away from the editing area in the buffer. OTOH, such messages as "Compilation finished" would significantly impact editing of the minibuffer's content in a negative way when displayed permanently. >> If someone wants the message to hang out indefinitely in the minibuffer, >> this is possible, minibuffer-message-timeout is configurable: > > That is a user option, so we cannot change it globally. We could bind > it temporarily, but how can we know which value to use in each and > every use case, on the level where you call minibuffer-message from > inside 'message'? I meant that it should be possible to customize the user option. >> But this means that your proposed implementation still should use timers >> to remove the echo-area with the appended message after the amount of time >> specified by minibuffer-message-timeout is passed (when its value is a number). > > No, my suggestion is not to remove the message automatically at all, > i.e. leave this aspect of 'message's behavior unchanged. The message > text will be removed when either the user types something, or when > some Lisp calls 'message' again to clear the message text. It should take into account a user option that specifies the timeout after which the message should be removed using a timer. If you want to leave the message indefinitely by default that's fine, but the users should have an option not to suffer from the default behavior that you propose.