From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#38457: 27.0.50; dabbrev-expand regression due to message change Date: Tue, 21 Jan 2020 18:15:13 +0200 Message-ID: <83a76gwzu6.fsf@gnu.org> References: <8736e3vve8.fsf@gmx.net> <87d0cubfxx.fsf@mail.linkov.net> <83a77y9k35.fsf@gnu.org> <87eex9jf14.fsf@mail.linkov.net> <83d0cs8uw8.fsf@gnu.org> <87a77uh5a5.fsf@mail.linkov.net> <83r21561qd.fsf@gnu.org> <878snd2liu.fsf@mail.linkov.net> <8336dk5k1p.fsf@gnu.org> <87a77rgajf.fsf@mail.linkov.net> <83immf3pba.fsf@gnu.org> <87y2vawly3.fsf@mail.linkov.net> <83tv5x38kq.fsf@gnu.org> <87d0clxjaq.fsf@mail.linkov.net> <83y2v81g5s.fsf@gnu.org> <87fthgdkq9.fsf@mail.linkov.net> <37de1822-26c5-b45a-e5b9-3ab492507b97@yandex.ru> <87tv5tfiao.fsf@mail.linkov.net> <393793a7-236f-dfce-edc7-100472ad9be2@yandex.ru> <874kxqpsse.fsf@mail.linkov.net> <416b122a-287e-5c47-8979-feb22b2bba81@yandex.ru> <87sgl9p9q3.fsf@mail.linkov.net> <858f4dc2-a955-9ce5-6cf7-aa2c00c2f01d@yandex.ru> <83eewsuzhn.fsf@gnu.org> <074b4fef-797b-af22-62a8-7c67f2d14c51@yandex.ru> <83pnfh18ir.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="97449"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 38457@debbugs.gnu.org, juri@linkov.net To: Dmitry Gutov , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 21 17:19:57 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1itwFx-000PCE-2d for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Jan 2020 17:19:57 +0100 Original-Received: from localhost ([::1]:57520 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itwFv-0005gW-Ez for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Jan 2020 11:19:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34931) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1itwCD-0002Pj-Qc for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 11:16:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1itwCC-000679-ET for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 11:16:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42331) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1itwCA-00066V-1I for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 11:16:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1itwC9-0005kM-U9 for bug-gnu-emacs@gnu.org; Tue, 21 Jan 2020 11:16:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Jan 2020 16:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 38457 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: fixed Original-Received: via spool by 38457-submit@debbugs.gnu.org id=B38457.157962331622033 (code B ref 38457); Tue, 21 Jan 2020 16:16:01 +0000 Original-Received: (at 38457) by debbugs.gnu.org; 21 Jan 2020 16:15:16 +0000 Original-Received: from localhost ([127.0.0.1]:48304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1itwBP-0005jJ-SI for submit@debbugs.gnu.org; Tue, 21 Jan 2020 11:15:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1itwBO-0005j3-A3 for 38457@debbugs.gnu.org; Tue, 21 Jan 2020 11:15:15 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:48311) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1itwBI-0005k9-8g; Tue, 21 Jan 2020 11:15:08 -0500 Original-Received: from [176.228.60.248] (port=4177 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1itwBC-0008TH-Qf; Tue, 21 Jan 2020 11:15:04 -0500 In-reply-to: (message from Dmitry Gutov on Mon, 20 Jan 2020 15:30:06 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:175003 Archived-At: > Cc: 38457@debbugs.gnu.org, juri@linkov.net > From: Dmitry Gutov > Date: Mon, 20 Jan 2020 15:30:06 +0300 > > On 18.01.2020 11:19, Eli Zaretskii wrote: > > >>>> No.  The cursor is always displayed after the overlay string.  If you > >>>> want it to do anything else, you need to put a 'cursor' property on > >>>> the overlay string. > >>> > >>> We do that there. > >> > >> And yet, the message appears before the cursor in the described > >> circumstances. > > > > Can I have a simple reproducer for this, so I could see what's going > > on there? > > A couple scenarios: > > 1. M-x icomplete-mode > 2. M-: (run-with-idle-timer 2 nil (lambda () (message "beep"))) > 2. C-h f > 3. Input something that will lead to either [Matched] or [No Matches], > e.g. 'asd'. > 4. See [beep] appear before the cursor. > > OR > > 1. M-: (setq resize-mini-windows nil) > 2. M-x icomplete-mode > (The same reproduces with Ido with my patch posted) > 2. M-: (run-with-idle-timer 2 nil (lambda () (message "beep"))) > 3. C-h f > 4. Input anything at all. E.g. something that will have matches, like > 'ft' or just 'f'. > 5. See [beep] appear before the cursor. Thanks. For the record, I only see the problem if I type "C-h f f"; neither "C-h f asd" nor "C-h f ft" reproduce the issue, because the list of the candidates displayed by Icomplete is too short. > Strangely, whether it appears before or after the cursor (at the very > end of the minibuffer), is affected by the value of > 'resize-mini-windows' (???). I think it is (was) just random, see below. There were 2 separate problems here. First, Icomplete displays the completion candidates as an after-string, so we end up having 2 overlays at EOB, both of them with after-strings. Question: which one of them will be displayed first? Answer: it isn't predictable, you are at the mercy of the overlay-sorting order when all the criteria for sorting compare equal. So sometimes the "beep" thing is displayed before the candidate list/"Not matched" and sometimes after. Moreover, if it happens to be after, and resize-mini-windows is nil, and the list of candidates is too long to be displayed in its entirety, then "beep" will not be shown at all. Solution: use overlay priority. You will see that I gave the overlay produced by set-minibuffer-message a very high priority. But I'm not wedded to that number, I just don't know what the likes of Ivy, Helm, and other heavily customized environments could do in their completion features. If we can make the priority lower, say, 101, I'd be much happier. CC'ing Stefan who I hope will have some useful input on this matter. The second problem is with setting the cursor when we have several overlays with after-strings one after another. When this happens, it is generally not enough to use the 'cursor' property of t on the overlay string character where you want the cursor, you need to use a number. Which I did. The reason is that overlay strings are problematic in this case, because the code which sets the cursor cannot know where the overlay start was in the buffer (unlike with strings that come from display properties), so it needs more help, and the integer value of the 'cursor' property provides that help. I only tested the fix (now on the emacs-27 branch) with Icomplete, but I think Ido will work correctly as well, if you use your patch there.