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: Thu, 12 Dec 2019 01:24:30 +0200 Organization: LINKOV.NET Message-ID: <87eexabg41.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="210656"; 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 Thu Dec 12 00:38:18 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 1ifBYd-000sdC-N4 for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Dec 2019 00:38:16 +0100 Original-Received: from localhost ([::1]:51716 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifBYc-0002YP-6b for geb-bug-gnu-emacs@m.gmane.org; Wed, 11 Dec 2019 18:38:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57810) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ifBYS-0002W3-GF for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 18:38:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ifBYR-0007Sc-C9 for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 18:38:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52820) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ifBYR-0007SR-8T for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 18:38:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ifBYR-0004av-5q for bug-gnu-emacs@gnu.org; Wed, 11 Dec 2019 18:38: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: Wed, 11 Dec 2019 23:38: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.157610748117637 (code B ref 38457); Wed, 11 Dec 2019 23:38:03 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 11 Dec 2019 23:38:01 +0000 Original-Received: from localhost ([127.0.0.1]:58791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifBYO-0004aN-NP for submit@debbugs.gnu.org; Wed, 11 Dec 2019 18:38:01 -0500 Original-Received: from cheetah.birch.relay.mailchannels.net ([23.83.209.34]:55656) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ifBYN-0004aD-Ek for 38457@debbugs.gnu.org; Wed, 11 Dec 2019 18:37:59 -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 699B62C1527; Wed, 11 Dec 2019 23:37:58 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a85.g.dreamhost.com (100-96-88-132.trex.outbound.svc.cluster.local [100.96.88.132]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E8BA82C1FEE; Wed, 11 Dec 2019 23:37:57 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a85.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); Wed, 11 Dec 2019 23:37:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Plucky-Shelf: 4bd9276323a6a8da_1576107478235_3776748451 X-MC-Loop-Signature: 1576107478234:361988401 X-MC-Ingress-Time: 1576107478234 Original-Received: from pdx1-sub0-mail-a85.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a85.g.dreamhost.com (Postfix) with ESMTP id B4F53ACBAE; Wed, 11 Dec 2019 15:37:52 -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:content-transfer-encoding; s=linkov.net; bh=+sQRNz unIxrFrYKyFxknKiYam+k=; b=Z8O0XRbp8SZNz4YBidNNHucDZxPfbIHxhEVNEe rPHxZHycm0qznoGFQeUIAycHUt9BUjkKV44xjezDb0fwvq2/JLAmUdQdT8Yc5ogY aA6eawCBFqfpVQDtvIWu4TUj6TiiUKqHpawD0vXGxVLqNCBTxfQb94AYmxIjYc+p TGvrw= 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-a85.g.dreamhost.com (Postfix) with ESMTPSA id 61C5FACE1F; Wed, 11 Dec 2019 15:37:49 -0800 (PST) X-DH-BACKEND: pdx1-sub0-mail-a85 In-Reply-To: <83r21aak51.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 11 Dec 2019 18:42:50 +0200") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrudeliedguddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirdegvdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrgedvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepvghlihiisehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd 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:173196 Archived-At: >> The original problem was, AFAIU, that various minibuffer prompts >> become obscured by echo-area display of messages. So one possible >> solution is to modify the subroutines of 'message', e.g., >> set_message_1, to detect the conditions of the minibuffer being >> active, and insert the contents of the minibuffer into the echo-area >> buffer before the message text. Does anyone see problems with this? > > Juri, could you please share your opinion about this proposal? you > worked on changes related to this issues a lot lately, so you probably > know about this more than anyone else. Do you see any problem with > the above? If workable, I think its advantage is that it minimizes > behavior changes, while preserving the main traits of the solution: to > avoid obscuring minibuffer prompts by asynchronous messages. The problem is not in implementation. Of course, it's possible to display the minibuffer's contents with an appended message in the echo-area like Isearch does. 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. If someone wants the message to hang out indefinitely in the minibuffer, this is possible, minibuffer-message-timeout is configurable: minibuffer-message-timeout is a variable defined in =E2=80=98C source c= ode=E2=80=99. Its value is 2 Documentation: How long to display an echo-area message when the minibuffer is active. If the value is a number, it should be specified in seconds. If the value is not a number, such messages never time out. But this means that your proposed implementation still should use timers to remove the echo-area with the appended message after the amount of tim= e specified by minibuffer-message-timeout is passed (when its value is a nu= mber).