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 14:45:35 -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> <83eexcax6b.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="91942"; 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 20:46:21 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 1ielSe-000Nlt-Ja for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 20:46:21 +0100 Original-Received: from localhost ([::1]:35300 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ielSc-0001LQ-DJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 10 Dec 2019 14:46:18 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33861) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ielSM-0001LE-VN for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 14:46:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ielSL-0004AS-PM for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 14:46:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50671) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ielSL-0004AM-LW for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 14:46:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ielSL-0005cx-Ki for bug-gnu-emacs@gnu.org; Tue, 10 Dec 2019 14:46:01 -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 19:46:01 +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.157600715121613 (code B ref 38457); Tue, 10 Dec 2019 19:46:01 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 10 Dec 2019 19:45:51 +0000 Original-Received: from localhost ([127.0.0.1]:56644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ielSA-0005cX-UH for submit@debbugs.gnu.org; Tue, 10 Dec 2019 14:45:51 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34396) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ielS9-0005cD-8S for 38457@debbugs.gnu.org; Tue, 10 Dec 2019 14:45:49 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B1A6481E25; Tue, 10 Dec 2019 14:45:43 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 92853812DF; Tue, 10 Dec 2019 14:45:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1576007141; bh=uI62YEpmITGWxglTBZ54PMXlhRzNN0l/RVITAHNE3ZU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=iV5NiFOwqFwlIcUGUp/6tXp3zrAmEK+WTsVyHlIZYVrskdps7euS5N5L8xWJ0+rfE Hyfgnh7wtPSG2+RWFBAcmrYFbZjLqlLcB0XHcGF34u/pAjAhZlZgWy4EOY0tpaEYS1 6X9r5Dy2jQSn8YGNFDPogQtB9x2SE48FjeO/5Nk0Nbuia6wCAC8kBH5TuAB9NjzGmQ tdKLU4L0gcnGIqWhpux2WEc0gGPrXgL4U3j/jUyeqckUWgdE0rnfCPgI0ZGZx1Txhn CUBOCSP7nsBOGpScx661AeTRbnJbKupMMSd9C9zm3X1COd+sGDVW3ku6J4yHvtpedH R/VFSdSQ6JUcA== Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5D9A3121180; Tue, 10 Dec 2019 14:45:41 -0500 (EST) In-Reply-To: <83eexcax6b.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Dec 2019 19:49:00 +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:173154 Archived-At: >> 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. > We could copy the overlays, if that's important. My gut feeling is that it's not important. >> 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. > You mean, if resize-mini-windows is nil? In any case where the window-start isn't point-min. That can be due to resize-mini-windows being nil or any other reason. > Otherwise, I see no problem. I'm not terribly worried about it either. I just mentioned it as a problem I could imagine coming up. > If resize-mini-windows is nil, the result will be the same as with the > current code, which calls minibuffer-message: the message is partially > or completely invisible. With the current code (i.e. with minibuffer-message), if resize-mini-windows is nil and the minibuffer is large enough to matter, the message is still (partially) visible as long as the currently displayed part of the minibuffer includes EOB, which is the usual case. If we simply copy the minibuffer's content to the echo area without preserving window-start, it will be more disruptive and will make it more likely that the message isn't visible. Stefan