bug#38457: 27.0.50; dabbrev-expand regression due to message change

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 38457@debbugs.gnu.org, juri@linkov.net
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.