From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Tue, 10 Dec 2019 12:08:14 -0500 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="229745"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 38457@debbugs.gnu.org, juri@linkov.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Dec 10 18:10: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.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iej1e-000xcr-F7 for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 18:10:18 +0100 Original-Received: from localhost ([::1]:59850 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iej1d-0002ra-9t for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 12:10:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36812) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iej0R-0001gZ-QS for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:09:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iej0Q-00043i-Mz for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:09:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50536) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iej0Q-00043c-KE for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:09:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iej0Q-0001CP-FK for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 12:09:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Dec 2019 17:09:02 +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.15759977064493 (code B ref 38457); Tue, 10 Dec 2019 17:09:02 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 17:08:26 +0000 Original-Received: from localhost ([127.0.0.1]:56509 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieizp-0001AO-Oi for submit@debbugs.gnu.org; Tue, 10 Dec 2019 12:08:25 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46102) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ieizo-00019x-5M for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 12:08:24 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5F145100791; Tue, 10 Dec 2019 12:08:18 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2F16D1003B1; Tue, 10 Dec 2019 12:08:16 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1575997696; bh=fiaLDX+FXLwHcV1C5B3iNq0cLa0UxEGD0Nm2R3uEeMY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=NyzJvVSGhw1Y5s7U4T2ae4VwVkDztO/f+VZtJd8BNy4ltiPd68T8YHuuqPdGBu0Oq 4h0wlK8E1dl21OpU+CKt0dziL/+e5lz/CclBWLyIpGB1u9VrFd7ubIbbbqUy873WGC nwvxiqlApA5i17XnHglnQctoZ0inzy5EMqu8VNqAf7s06e8pV0EkYUZFWYtRWPflR5 OnsDoKqJTQW63gyK8akbG2NKboJLFbgD5d2eBX9EPWkiqTCilSpjvyCDTjoVuJ3alJ Zd0TXy6YtjejAs9DLdIx5yzRBgoO+w2yDzbEAEzJ81UkhYceyX5JDSRgOkJOyEDthX Agt0fT0WQkL/g== Original-Received: from alfajor (modemcable157.163-203-24.mc.videotron.ca [24.203.163.157]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D8D6B121355; Tue, 10 Dec 2019 12:08:15 -0500 (EST) In-Reply-To: <83h828b0lz.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Dec 2019 18:34:48 +0200") 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:173145 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. Ha! Clever! > Does anyone see problems with this? [ I presume that additionally from inserting the minibuffer's contents we'd add some delimiters to clearly separate the message from the minibuffer's contents. ] I guess there could be some visible artifacts of this subterfuge in the case where the minibuffer's content is currently affected by overlays (since we presumably wouldn't copy those to the echo-area), but I'm not sure this would be a real problem. One such case of overlays is when icomplete-mode is enabled, and it would simply temporarily hide the completion-list displayed by icomplete-mode, which seems quite harmless or maybe even beneficial. Another issue could be when the minibuffer is large, in which case we'll want to try and preserve the window-start but also we'll want to make sure the new message is visible. BTW, we should probably think about replacing `message` with something that lets the caller give more information about the intended behavior (e.g. to also solve the issue of several successive calls to message resulting in the user only seeing the last message). Of course, this would be for Emacs-28. Stefan