bug#6192: 24.0.50; eldoc-mode: unexpected recentering

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

1. Let ~/.emacs consist of the following line:
(add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)

2. Start Emacs with the above init-file.

3. Visit an Emacs lisp file that's long enough to scroll a number of
screens up and down, e.g. lisp/abbrev.el from the Emacs source
directory.

4. Type `M->' (end-of-buffer).

5. Type 'M-v' (scroll-down-command)

=> This puts point at line 902 (at least here, with window-height 33),
which is at the bottom of the window as it should be -- but only for a
fraction of a second, and then point is recentered so that line 902 is
now in the middle of the window.

On subsequent reiterations of M-v this recentering sometimes happens and
sometimes doesn't.  I haven't discovered a pattern (nor does it happen
the first time with all files, though it appears to be consistent within
the same file).

This recentering only happens when eldoc-mode is enabled from the mode
hook in the user init file, i.e., starting Emacs with -Q and evalling
the sexp in step 1, then doing steps 2-5, I do not observe the
recentering. 


In GNU Emacs 24.0.50.3 (i686-pc-linux-gnu, GTK+ Version 2.18.6)
 of 2010-05-12 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.10605000
configured using `configure  '--without-toolkit-scroll-bars''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 14 May 2010 19:11:30 +0200
> Cc: 
> 
> 1. Let ~/.emacs consist of the following line:
> (add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
> 
> 2. Start Emacs with the above init-file.
> 
> 3. Visit an Emacs lisp file that's long enough to scroll a number of
> screens up and down, e.g. lisp/abbrev.el from the Emacs source
> directory.
> 
> 4. Type `M->' (end-of-buffer).
> 
> 5. Type 'M-v' (scroll-down-command)
> 
> => This puts point at line 902 (at least here, with window-height 33),
> which is at the bottom of the window as it should be -- but only for a
> fraction of a second, and then point is recentered so that line 902 is
> now in the middle of the window.

Could it be that the last line uses some characters or some faces that
cause the line to be only partially visible, when it is the last line
of the window?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Fri, 14 May 2010 20:49:44 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Fri, 14 May 2010 19:11:30 +0200
>> Cc: 
>> 
>> 1. Let ~/.emacs consist of the following line:
>> (add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
>> 
>> 2. Start Emacs with the above init-file.
>> 
>> 3. Visit an Emacs lisp file that's long enough to scroll a number of
>> screens up and down, e.g. lisp/abbrev.el from the Emacs source
>> directory.
>> 
>> 4. Type `M->' (end-of-buffer).
>> 
>> 5. Type 'M-v' (scroll-down-command)
>> 
>> => This puts point at line 902 (at least here, with window-height 33),
>> which is at the bottom of the window as it should be -- but only for a
>> fraction of a second, and then point is recentered so that line 902 is
>> now in the middle of the window.
>
> Could it be that the last line uses some characters or some faces that
> cause the line to be only partially visible, when it is the last line
> of the window?

I don't think so.  First, I think this happens with any file that's long
enough.  Second, the last line of abbrev.el is empty (EOB), and after
step 4, the last line of the file is completely visible, and two or
three lines above the bottom of the window; this is typical.  And third,
as I reported, this doesn't only happen at the bottom of the file, nor
does it always happen there: for instance, my normal Emacs window-height
is 57, and with this height and the above recipe, I see the recenter not
after the first M-v but after the second one.  Very peculiar...

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 14 May 2010 19:11:30 +0200
> 
> => This puts point at line 902 (at least here, with window-height 33),
> which is at the bottom of the window as it should be -- but only for a
> fraction of a second, and then point is recentered so that line 902 is
> now in the middle of the window.

I cannot reproduce this on MS-Windows.  In my case, M-v from the end
of the buffer puts point on line 902, but it is the second line from
the bottom of the window, not the first.  And even if I then type C-n,
point stays on the last line.  I see no recentering at all.

Anyway, from what you say it sounds like the message displayed by
eldoc-mode in the echo area, which causes redisplay, somehow makes
Emacs think the window where you have the Lisp file needs to be
recentered because point is in a line that is not visible enough.

Do you see the same problem in Emacs 23.2?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 00:05:52 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Fri, 14 May 2010 19:11:30 +0200
>> 
>> => This puts point at line 902 (at least here, with window-height 33),
>> which is at the bottom of the window as it should be -- but only for a
>> fraction of a second, and then point is recentered so that line 902 is
>> now in the middle of the window.
>
> I cannot reproduce this on MS-Windows.  In my case, M-v from the end
> of the buffer puts point on line 902, but it is the second line from
> the bottom of the window, not the first.  

Yes, my OP was inaccurate, M-v does put point on the penultimate line.
Sorry for the sloppiness.

>                                           And even if I then type C-n,
> point stays on the last line.  I see no recentering at all.

Maybe it's a GTK+ issue.  (I just checked and I don't see the
recentering when I start Emacs with -nw)

> Anyway, from what you say it sounds like the message displayed by
> eldoc-mode in the echo area, which causes redisplay, somehow makes
> Emacs think the window where you have the Lisp file needs to be
> recentered because point is in a line that is not visible enough.

Ah, your reference to the Eldoc message made me take another look, and I
think I've now found a pattern: the recentering appears to happen only
(and always) when the message is displayed, and then the minibuffer
expands to and remains at two lines, even though the message is a single
line.  When M-v puts point inside a string or on an empty line between
sexp's, then there is no recentering (and the minibuffer clears and
returns to one line).  That seems significant...

> Do you see the same problem in Emacs 23.2?

I don't have 23.2, but I do have GNU Emacs 23.1.91.4 (i686-pc-linux-gnu,
GTK+ Version 2.18.1) of 2010-01-28 on escher, and I observe the
recentering with this build as well.

Thanks for the feedback.

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 6192@debbugs.gnu.org
> Date: Fri, 14 May 2010 23:44:06 +0200
> 
> > Anyway, from what you say it sounds like the message displayed by
> > eldoc-mode in the echo area, which causes redisplay, somehow makes
> > Emacs think the window where you have the Lisp file needs to be
> > recentered because point is in a line that is not visible enough.
> 
> Ah, your reference to the Eldoc message made me take another look, and I
> think I've now found a pattern: the recentering appears to happen only
> (and always) when the message is displayed, and then the minibuffer
> expands to and remains at two lines, even though the message is a single
> line.

When that happens, do you see any message in *Messages* besides the
one displayed in the echo area?

In general, a single-line message should not resize the echo area.  If
the echo area is resized, then recentering you describe is a normal
reaction of the display engine.  So the question now is why the echo
area is enlarged to 2 lines.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 09:36:55 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 6192@debbugs.gnu.org
>> Date: Fri, 14 May 2010 23:44:06 +0200
>> 
>> > Anyway, from what you say it sounds like the message displayed by
>> > eldoc-mode in the echo area, which causes redisplay, somehow makes
>> > Emacs think the window where you have the Lisp file needs to be
>> > recentered because point is in a line that is not visible enough.
>> 
>> Ah, your reference to the Eldoc message made me take another look, and I
>> think I've now found a pattern: the recentering appears to happen only
>> (and always) when the message is displayed, and then the minibuffer
>> expands to and remains at two lines, even though the message is a single
>> line.
>
> When that happens, do you see any message in *Messages* besides the
> one displayed in the echo area?

Nothing in *Messages* (not even the Eldoc message -- it is deliberately
suppressed by eldoc-message).

> In general, a single-line message should not resize the echo area.  If
> the echo area is resized, then recentering you describe is a normal
> reaction of the display engine.  So the question now is why the echo
> area is enlarged to 2 lines.

I don't know, but I stepped through eldoc.el with Edebug and when it got
to the point where the message is put into the echo area, this is what
it showed:

Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))

This string made the echo area expand to two lines, but in normal
(non-edebug) execution it of course shows up just as "let: (VARLIST
BODY...)" (with fontification).  So if the propertized string is the
source of the expanded echo area, the question becomes why it does not
shrink again.  (And there's still the question of why this only happens
when eldoc-mode is enabled in my init file...)

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 6192@debbugs.gnu.org
> Date: Sat, 15 May 2010 17:40:02 +0200
> 
> > When that happens, do you see any message in *Messages* besides the
> > one displayed in the echo area?
> 
> Nothing in *Messages* (not even the Eldoc message -- it is deliberately
> suppressed by eldoc-message).

Can you hack eldoc to un-suppress that, and then see?

> > In general, a single-line message should not resize the echo area.  If
> > the echo area is resized, then recentering you describe is a normal
> > reaction of the display engine.  So the question now is why the echo
> > area is enlarged to 2 lines.
> 
> I don't know, but I stepped through eldoc.el with Edebug and when it got
> to the point where the message is put into the echo area, this is what
> it showed:
> 
> Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))
> 
> This string made the echo area expand to two lines, but in normal
> (non-edebug) execution it of course shows up just as "let: (VARLIST
> BODY...)" (with fontification).  So if the propertized string is the
> source of the expanded echo area

No, that cannot be it.  The properties should be completely evaluated
and converted to appropriate faces, by the time the message is
displayed.  What gets displayed is just "let: (VARLIST BODY...)", and
unless you have some strange fonts installed, I don't see how this can
require more than one line of the echo area.

> the question becomes why it does not shrink again.

Once expanded, Emacs shrinks the echo area lazily (see the value of
resize-mini-windows).  So this is normal.

We should concentrate on why the echo area is expanded.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 19:44:38 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 6192@debbugs.gnu.org
>> Date: Sat, 15 May 2010 17:40:02 +0200
>> 
>> > When that happens, do you see any message in *Messages* besides the
>> > one displayed in the echo area?
>> 
>> Nothing in *Messages* (not even the Eldoc message -- it is deliberately
>> suppressed by eldoc-message).
>
> Can you hack eldoc to un-suppress that, and then see?

I did, and the message after one M-v and recentering is this:

let: (VARLIST BODY...) [2 times]

[...]
>> Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))
>> 
>> This string made the echo area expand to two lines, but in normal
>> (non-edebug) execution it of course shows up just as "let: (VARLIST
>> BODY...)" (with fontification).  So if the propertized string is the
>> source of the expanded echo area
>
> No, that cannot be it.  The properties should be completely evaluated
> and converted to appropriate faces, by the time the message is
> displayed.  What gets displayed is just "let: (VARLIST BODY...)", and
> unless you have some strange fonts installed, I don't see how this can
> require more than one line of the echo area.

It's the bold face, as Martin observed; see my followup to his reply.

>> the question becomes why it does not shrink again.
>
> Once expanded, Emacs shrinks the echo area lazily (see the value of
> resize-mini-windows).  So this is normal.
>
> We should concentrate on why the echo area is expanded.

Yes, why does bold face do it (and again, why only when eldoc-mode is
enabled in .emacs)?

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 6192@debbugs.gnu.org
> Date: Sat, 15 May 2010 19:25:52 +0200
> 
> > No, that cannot be it.  The properties should be completely evaluated
> > and converted to appropriate faces, by the time the message is
> > displayed.  What gets displayed is just "let: (VARLIST BODY...)", and
> > unless you have some strange fonts installed, I don't see how this can
> > require more than one line of the echo area.
> 
> It's the bold face, as Martin observed; see my followup to his reply.

If it's the bold face, then I see no bug here.

Do you see a change if you customize resize-mini-windows to t?

> Yes, why does bold face do it

Maybe it has some character that is too large for a single line?

> (and again, why only when eldoc-mode is enabled in .emacs)?

No clue.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 20:33:20 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 6192@debbugs.gnu.org
>> Date: Sat, 15 May 2010 19:25:52 +0200
>> 
>> > No, that cannot be it.  The properties should be completely evaluated
>> > and converted to appropriate faces, by the time the message is
>> > displayed.  What gets displayed is just "let: (VARLIST BODY...)", and
>> > unless you have some strange fonts installed, I don't see how this can
>> > require more than one line of the echo area.
>> 
>> It's the bold face, as Martin observed; see my followup to his reply.
>
> If it's the bold face, then I see no bug here.

Surely there's some bug (though maybe not in Emacs) if the behavior
differs between platforms, no?

> Do you see a change if you customize resize-mini-windows to t?

No, the echo area still expands to two lines.

>> Yes, why does bold face do it
>
> Maybe it has some character that is too large for a single line?

I don't think so: when I start Emacs with -Q (i.e. no eldoc-mode) and in
*scratch* eval this sexp:

(message (propertize "BODY" 'face 'bold))

then I see the string "BODY" in bold face in the echo area, i.e. the
same bold string as in the Eldoc message -- but now the echo area stays
at a height of one line.

>> (and again, why only when eldoc-mode is enabled in .emacs)?
>
> No clue.

Pity.

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 >> Do you see a change if you customize resize-mini-windows to t?
 >
 > No, the echo area still expands to two lines.

"A value of t means resize them to fit the text displayed in them."  Not
very different from grow-only in the case at hand ;-)

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> Date: Sun, 16 May 2010 00:52:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 6192@debbugs.gnu.org
> 
>  >> Do you see a change if you customize resize-mini-windows to t?
>  >
>  > No, the echo area still expands to two lines.
> 
> "A value of t means resize them to fit the text displayed in them."  Not
> very different from grow-only in the case at hand ;-)

It's very different in how Emacs shrinks them back.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 >>  >> Do you see a change if you customize resize-mini-windows to t?
 >>  >
 >>  > No, the echo area still expands to two lines.
 >>
 >> "A value of t means resize them to fit the text displayed in them."  Not
 >> very different from grow-only in the case at hand ;-)
 >
 > It's very different in how Emacs shrinks them back.

So far Stephen was concerned with the expanding step only.  But any
difference between `grow-only' and t should have an impact iff the
height of the minibuffer changes from some value `old' to some value
`new' where 1 < new < old.  IIUC `eldoc-mode' never shrinks the echo
area back to some value > 1.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> Date: Sun, 16 May 2010 10:18:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen.berman@gmx.net, 6192@debbugs.gnu.org
> 
>  >>  >> Do you see a change if you customize resize-mini-windows to t?
>  >>  >
>  >>  > No, the echo area still expands to two lines.
>  >>
>  >> "A value of t means resize them to fit the text displayed in them."  Not
>  >> very different from grow-only in the case at hand ;-)
>  >
>  > It's very different in how Emacs shrinks them back.
> 
> So far Stephen was concerned with the expanding step only.  But any
> difference between `grow-only' and t should have an impact iff the
> height of the minibuffer changes from some value `old' to some value
> `new' where 1 < new < old.  IIUC `eldoc-mode' never shrinks the echo
> area back to some value > 1.

At the time I asked that question, I thought that perhaps some
previous message enlarged the echo area, only to be replaced quickly
by the shorter message that Stephen was reporting.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > I don't know, but I stepped through eldoc.el with Edebug and when it got
 > to the point where the message is put into the echo area, this is what
 > it showed:
 >
 > Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))
 >
 > This string made the echo area expand to two lines, but in normal
 > (non-edebug) execution it of course shows up just as "let: (VARLIST
 > BODY...)" (with fontification).  So if the propertized string is the
 > source of the expanded echo area, the question becomes why it does not
 > shrink again.  (And there's still the question of why this only happens
 > when eldoc-mode is enabled in my init file...)

I had some problem with eldoc-mode after the latest greater bunch of
changes.  There was some bold face that caused my echo area occupy two
lines occasionally.  IIRC customizing `eldoc-highlight-function-argument'
and/or `eldoc-highlight-unsupplied-argument' to something non-bold
solved the problem for me.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 18:53:01 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I don't know, but I stepped through eldoc.el with Edebug and when it got
>> to the point where the message is put into the echo area, this is what
>> it showed:
>>
>> Result: #("let: (VARLIST BODY...)" 0 3 (face font-lock-function-name-face) 14 21 (face eldoc-highlight-function-argument))
>>
>> This string made the echo area expand to two lines, but in normal
>> (non-edebug) execution it of course shows up just as "let: (VARLIST
>> BODY...)" (with fontification).  So if the propertized string is the
>> source of the expanded echo area, the question becomes why it does not
>> shrink again.  (And there's still the question of why this only happens
>> when eldoc-mode is enabled in my init file...)
>
> I had some problem with eldoc-mode after the latest greater bunch of
> changes.  There was some bold face that caused my echo area occupy two
> lines occasionally.  IIRC customizing `eldoc-highlight-function-argument'
> and/or `eldoc-highlight-unsupplied-argument' to something non-bold
> solved the problem for me.

You're right: I changed eldoc-highlight-function-argument to italic and
the recentering stopped.

Did you also have eldoc-mode enabled in your .emacs file (I only get the
two line echo area in that case)?

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > Did you also have eldoc-mode enabled in your .emacs file (I only get the
 > two line echo area in that case)?

I always had - how else can you do it?  But the problems only started
after the series of changes following the release of Emacs 22.  I was
mainly annoyed by the continuous resizing of the echo area, especially
when eldoc tries to analyze doc-strings or comments.  So I first wrote
some workaround until I found out that customizing the faces suffices.

Meanwhile I show eldoc-strings either in the header-line, a separate
window, or in a tooltip - but none of them work satisfactorily :-(

Anyway: The recentering is a misbehavior which should not occur.  Does
Emacs restore the old situation when the echo area sizes back?

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> Date: Sat, 15 May 2010 21:02:14 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 6192@debbugs.gnu.org
> 
> Anyway: The recentering is a misbehavior which should not occur.

Why not?  What would you expect it to do instead?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 >> Anyway: The recentering is a misbehavior which should not occur.
 >
 > Why not?  What would you expect it to do instead?

If there's another window, resize that first.  Else move the window
start position down by one line.  Recentering is too drastic.  Well,
`point' should never be that near to the bottom line either.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Juanma Barranquero]

On Sat, May 15, 2010 at 22:47, martin rudalics <rudalics@gmx.at> wrote:

> Well, `point' should never be that near to the bottom line either.

???

    Juanma

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 >> Well, `point' should never be that near to the bottom line either.
 >
 > ???

I know, I know ;-) What I meant was that users should be able to
set `scroll-margin' to 2 or 3 without suffering any retaliations.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> Date: Sat, 15 May 2010 22:47:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: stephen.berman@gmx.net, 6192@debbugs.gnu.org
> 
>  >> Anyway: The recentering is a misbehavior which should not occur.
>  >
>  > Why not?  What would you expect it to do instead?
> 
> If there's another window, resize that first.

There wasn't, in the case in point.

> Else move the window start position down by one line.  Recentering
> is too drastic.

Recenter is what Emacs does by default when point goes out of screen.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > Recenter is what Emacs does by default when point goes out of screen.

Fortunately this can be customized.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sat, 15 May 2010 21:02:14 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Did you also have eldoc-mode enabled in your .emacs file (I only get the
>> two line echo area in that case)?
>
> I always had - how else can you do it?  

Of course; so can you confirm that you do not see the resizing with -Q
and then enabling eldoc mode?

>                                         But the problems only started
> after the series of changes following the release of Emacs 22.  I was
> mainly annoyed by the continuous resizing of the echo area, especially
> when eldoc tries to analyze doc-strings or comments.  So I first wrote
> some workaround until I found out that customizing the faces suffices.
>
> Meanwhile I show eldoc-strings either in the header-line, a separate
> window, or in a tooltip - but none of them work satisfactorily :-(
>
> Anyway: The recentering is a misbehavior which should not occur.  Does
> Emacs restore the old situation when the echo area sizes back?

I'm not sure what you mean by "old situation"; if you mean does the
recentered line revert to the penultimate line, then no, there is no
change when the echo area returns to one line.

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > Of course; so can you confirm that you do not see the resizing with -Q
 > and then enabling eldoc mode?

I have to look a bit harder.  My Emacsen are a complete mess these days.

 > I'm not sure what you mean by "old situation"; if you mean does the
 > recentered line revert to the penultimate line, then no, there is no
 > change when the echo area returns to one line.

Looks like a real pain.  ISTR that Gerd has put some sort of window
excursion around minibuffer resizing.  I've not been using his code for
quite some time so I can't really tell at the moment ...

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > Of course; so can you confirm that you do not see the resizing with -Q
 > and then enabling eldoc mode?

I have tried the trunk with -Q now and can't trigger the resizing any
more, neither with a hook nor when setting it manually.  So AFAIAC this
is a Heisenbug.

 > I'm not sure what you mean by "old situation"; if you mean does the
 > recentered line revert to the penultimate line, then no, there is no
 > change when the echo area returns to one line.

Unfortunately, that is to be expected.  Gerd's minibuffer code only
restores window heights and top lines but neither start positions nor
points.  I here rewrote the code in the meantime but don't restore start
positions and points either.  Maybe shrink_mini_window should be done by
simply restoring the window configuration that existed before resizing
the minibuffer started, but I'm not sure.

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sun, 16 May 2010 10:17:36 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> Of course; so can you confirm that you do not see the resizing with -Q
>> and then enabling eldoc mode?
>
> I have tried the trunk with -Q now and can't trigger the resizing any
                                                                    ^^^
> more, neither with a hook nor when setting it manually.
  ^^^^

It's not that the bug is no longer reliably reproducible; rather, you do
confirm my observation that the resizing happens iff eldoc-mode is
enabled in the user init file.  So what difference between running a
hook there and running it later could lead to the bug?

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > It's not that the bug is no longer reliably reproducible; rather, you do
 > confirm my observation that the resizing happens iff eldoc-mode is
 > enabled in the user init file.

No, I can't confirm that: At the time I observed the problem for the
first time, I always only tried it by enabling eldoc-mode in a hook.
Currently, I simply can't reproduce it neither by running eldoc-mode in
a hook nor by enabling it manually.

 > So what difference between running a
 > hook there and running it later could lead to the bug?

Good question.  Especially because the hook should be the last thing you
run when activating emacs-lisp-mode.  Does anything change when you
disable font-locking?

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sun, 16 May 2010 14:35:48 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> It's not that the bug is no longer reliably reproducible; rather, you do
>> confirm my observation that the resizing happens iff eldoc-mode is
>> enabled in the user init file.
>
> No, I can't confirm that: At the time I observed the problem for the
> first time, I always only tried it by enabling eldoc-mode in a hook.
> Currently, I simply can't reproduce it neither by running eldoc-mode in
> a hook nor by enabling it manually.

I still not sure I understand.  When you wrote:

   > I have tried the trunk with -Q now and can't trigger the resizing any
   > more, neither with a hook nor when setting it manually.

I took you to mean you started with -Q, evalled (add-hook
'emacs-lisp-mode-hook 'turn-on-eldoc-mode), visited an elisp file and
then did not observe the echo area resizing (and consequent
recentering).  When I do that I not see resizing; I only (and always)
observe the resizing when (add-hook 'emacs-lisp-mode-hook
'turn-on-eldoc-mode) is in .emacs and Emacs starts with this.  Are you
now saying you don't (now) see resizing in the latter case?

>> So what difference between running a
>> hook there and running it later could lead to the bug?
>
> Good question.  Especially because the hook should be the last thing you
> run when activating emacs-lisp-mode.  Does anything change when you
> disable font-locking?

No, the Eldoc message is shown with faces and the echo area is resized
(because the argument face is bold).  Eldoc mode sets the faces via
propertize, which evidently is not affected by font-locking.

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > I still not sure I understand.  When you wrote:
 >
 >    > I have tried the trunk with -Q now and can't trigger the resizing any
 >    > more, neither with a hook nor when setting it manually.
 >
 > I took you to mean you started with -Q, evalled (add-hook
 > 'emacs-lisp-mode-hook 'turn-on-eldoc-mode), visited an elisp file and
 > then did not observe the echo area resizing (and consequent
 > recentering).  When I do that I not see resizing; I only (and always)
 > observe the resizing when (add-hook 'emacs-lisp-mode-hook
 > 'turn-on-eldoc-mode) is in .emacs and Emacs starts with this.  Are you
 > now saying you don't (now) see resizing in the latter case?

That's what I'm saying, yes.  I've been nagged by the bug some two years
ago.  At that time I had the add-hook in my .emacs and never tried with
Emacs -Q or anything else.  I apparently considered the possibility that
the bug had something to do with my other customizations.  I then also
literally replaced the line

	      argument-face 'font-lock-warning-face

with

  	      argument-face 'font-lock-string-face

(I know that because I still have this commented out in my .emacs.  The
fact that it's commented out means that eventually something must have
changed so that I didn't need it any more but I wasn't very sure about
that change.  Sadly, I have forgotten all about this.  I also found a
face `eldoc-highlight-unsupplied-argument' customized in my .emacs and
now cannot tell what it has been used for.)

Anyway.  With a trunk built on April 19th of this year I cannot
reproduce any echo area resizing neither (a) with (add-hook ...) in my
.emacs, (b) with (add-hook ...) evaluated in Emacs -Q before opening an
.el file, and (c) with (turn-on-eldoc-mode) evaluated after opening an
.el file.  As with Eli here the echo area doesn't resize any more.

 > No, the Eldoc message is shown with faces and the echo area is resized
 > (because the argument face is bold).  Eldoc mode sets the faces via
 > propertize, which evidently is not affected by font-locking.

There's an `add-text-properties' in `eldoc-highlight-function-argument'.

BTW did you check how customizing `eldoc-echo-area-use-multiline-p' fits
into this?

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Sun, 16 May 2010 20:50:58 +0200 martin rudalics <rudalics@gmx.at> wrote:

> Anyway.  With a trunk built on April 19th of this year I cannot
> reproduce any echo area resizing neither (a) with (add-hook ...) in my
> .emacs, (b) with (add-hook ...) evaluated in Emacs -Q before opening an
> .el file, and (c) with (turn-on-eldoc-mode) evaluated after opening an
> .el file.  As with Eli here the echo area doesn't resize any more.

This is on Windows, right?  Since I recollected that you run Emacs on
Windows, it surprised me when you reported seeing the resizing, although
Eli had reported not seeing it on Windows.  So I guess it's good that
there is no discrepancy between you after all.  As I suggested to Eli,
maybe it's a GTK+ issue (but see below).

>> No, the Eldoc message is shown with faces and the echo area is resized
>> (because the argument face is bold).  Eldoc mode sets the faces via
>> propertize, which evidently is not affected by font-locking.
>
> There's an `add-text-properties' in `eldoc-highlight-function-argument'.
>
> BTW did you check how customizing `eldoc-echo-area-use-multiline-p' fits
> into this?

That makes no difference: with each of the three possible values, I get
the resizing.

However, it occurred to me that the font could make a difference -- and
lo and behold, it does: I tried most if not all monospaced fonts on my
system (via the set default font menu), and saw the echo area resize
only with these (the first being my default font):

DejaVu Sans Mono
Luxi Mono
Nimbus Mono L

With all other fonts I tried, there was no resizing even though the
argument face was bold.

I still have no idea why there's the .emacs/-Q asymmetry.

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[martin rudalics]

 > This is on Windows, right?

Right.

 > I still have no idea why there's the .emacs/-Q asymmetry.

Maybe the effect of loading .emacs vs running Emacs with -Q?  Did you
ever try with a .emacs containing something unrelated and/or putting
the (add-hook ...) in the command invoking Emacs?

martin

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Mon, 17 May 2010 11:06:02 +0200 martin rudalics <rudalics@gmx.at> wrote:

>> I still have no idea why there's the .emacs/-Q asymmetry.
>
> Maybe the effect of loading .emacs vs running Emacs with -Q?  Did you
> ever try with a .emacs containing something unrelated and/or putting
> the (add-hook ...) in the command invoking Emacs?

It turns out that there is no .emacs/-Q asymmetry.  As I reported in my
previous post, I found out that the resizing only happens with (at
least) three monospaced fonts on my system, including "my default font"
DejaVu Sans Mono.  What I meant is that this is the font I standardly
use when running Emacs, which I set in my init file.  But when I start
with -Q, Emacs uses the font Andale Mono, which is similar enough to
DejaVu Sans Mono that I (not having the sharpest eyesight) neglected to
take that difference into account.  I did so now, starting Emacs with
-Q, changing the font (via the Options menu item Set Default Font) to
DejaVu Sans Mono, visiting abbrev.el, enabling Eldoc mode (via M-x
eldoc-mode), scrolled to the bottom, typed M-v, and observed the echo
area resize when it displayed the Eldoc message (and point was
recentered).

Moreover, as I also mentioned previously, this is independent of Eldoc
mode, since evalling (message (propertize "test" 'face 'bold)) in
*scratch* (with eldoc-mode not enabled) also induces echo area resizing
(with the problematic font).

In short, this bug now boils down to this: the echo area resizes with
certain fonts (including DejaVu Sans Mono) when it displays a message
that includes bold face.  Whether this is a bug in Emacs or the
problematic fonts, I don't know.

Do you (or Eli or some other Windows user) have DejaVu Sans Mono, and if
so, do you see the resizing when you use it?

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Juanma Barranquero]

On Mon, May 17, 2010 at 11:47, Stephen Berman <stephen.berman@gmx.net> wrote:

> In short, this bug now boils down to this: the echo area resizes with
> certain fonts (including DejaVu Sans Mono) when it displays a message
> that includes bold face.  Whether this is a bug in Emacs or the
> problematic fonts, I don't know.
>
> Do you (or Eli or some other Windows user) have DejaVu Sans Mono, and if
> so, do you see the resizing when you use it?

With

  emacs -Q -fn "DejaVu Sans Mono-10"
  C-y    ; to paste   (message (propertize "test" 'face 'bold))
  C-j

I see the message "test", but no resizing.

    Juanma

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stephen Berman]

On Mon, 17 May 2010 12:21:50 +0200 Juanma Barranquero <lekktu@gmail.com> wrote:

> On Mon, May 17, 2010 at 11:47, Stephen Berman <stephen.berman@gmx.net> wrote:
>
>> In short, this bug now boils down to this: the echo area resizes with
>> certain fonts (including DejaVu Sans Mono) when it displays a message
>> that includes bold face.  Whether this is a bug in Emacs or the
>> problematic fonts, I don't know.
>>
>> Do you (or Eli or some other Windows user) have DejaVu Sans Mono, and if
>> so, do you see the resizing when you use it?
>
> With
>
>   emacs -Q -fn "DejaVu Sans Mono-10"
>   C-y    ; to paste   (message (propertize "test" 'face 'bold))
>   C-j
>
> I see the message "test", but no resizing.

Ok, then Windows seems to be immune to this bug.  Is it only a GTK+
problem, or can anyone confirm it on a non-Windows platform with a
non-GTK+ toolkit?  (When I have time, I'll try building without GTK+,
but maybe someone can chime in before then.)

Steve Berman

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stefan Monnier]

> In short, this bug now boils down to this: the echo area resizes with
> certain fonts (including DejaVu Sans Mono) when it displays a message
> that includes bold face.  Whether this is a bug in Emacs or the
> problematic fonts, I don't know.

To summarize this long thread, IIUC we have three separate problems:
- in some cases, a minibuffer message with bold text causes
  unexpected/unneeded minibuffer resizing.  Most likely those fonts
  somehow end up with a height just a tiny pixel taller.  Maybe we
  should change the minibuffer resizing such that it only resizes if the
  extra height needed is more than some threshold number of pixels (1
  or 2).
- eldoc can cause undesired minibuffer resizing.  That can probably still
  happen even when we fix the previous problem, depending on face
  settings and/or length of eldoc data.  So maybe eldoc should come with
  a config var for how many max lines of echo-area we're willing to
  devote to it.  If set to 1 it will prevent any resizing and fix the
  OP's problem regardless of whether the previous problem is fixed.
- minibuffer auto-resize can trigger an undesirable recentering.
  I'm not sure we can do much about that, tho, since it seems to only
  occur in cases where the resizing ends up "eating" the area used by
  point, so some scrolling is necessary.


        Stefan

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Lennart Borgman]

On Mon, May 17, 2010 at 4:08 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> - minibuffer auto-resize can trigger an undesirable recentering.
>  I'm not sure we can do much about that, tho, since it seems to only
>  occur in cases where the resizing ends up "eating" the area used by
>  point, so some scrolling is necessary.

I don't think recentering is the right thing to do in this case. It is
too surprising. Just scroll one line if needed.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Juanma Barranquero]

On Mon, May 17, 2010 at 16:43, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> I don't think recentering is the right thing to do in this case.

(IMHO recentering is never the right thing to do, but I digress...)

> It is too surprising. Just scroll one line if needed.

Why "one"?

    Juanma

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Lennart Borgman]

On Mon, May 17, 2010 at 6:23 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Mon, May 17, 2010 at 16:43, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> I don't think recentering is the right thing to do in this case.
>
> (IMHO recentering is never the right thing to do, but I digress...)
>
>> It is too surprising. Just scroll one line if needed.
>
> Why "one"?


Because I thought minibuffer could only be two lines .. ;-)

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Juanma Barranquero]

On Mon, May 17, 2010 at 18:33, Lennart Borgman
<lennart.borgman@gmail.com> wrote:

> Because I thought minibuffer could only be two lines .. ;-)

Ah.

No.

    Juanma

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 17 May 2010 16:43:09 +0200
> Cc: Stephen Berman <stephen.berman@gmx.net>, 6192@debbugs.gnu.org
> 
> I don't think recentering is the right thing to do in this case. It is
> too surprising. Just scroll one line if needed.

When Emacs recenters, that means it exhausted all the other available
redisplay optimizations, and fell back on its default method of
completely redrawing a window.

What you want is an optimization that does not yet exist, AFAIK.  It
needs to be designed and coded.  The tricky part is to detect the
situation where the amount of scrolling can be easily computed in
advance, and do that computation without too many complications.  You
seem to think that this computation is easy, but that is only true
when the display shows characters of the same size everywhere.  In the
more general case, what do we do? still recenter?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Lennart Borgman]

On Mon, May 17, 2010 at 7:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> When Emacs recenters, that means it exhausted all the other available
> redisplay optimizations, and fell back on its default method of
> completely redrawing a window.
>
> What you want is an optimization that does not yet exist, AFAIK.  It
> needs to be designed and coded.  The tricky part is to detect the
> situation where the amount of scrolling can be easily computed in
> advance, and do that computation without too many complications.  You
> seem to think that this computation is easy, but that is only true
> when the display shows characters of the same size everywhere.  In the
> more general case, what do we do? still recenter?


Would it be possible to try 1 line scrolling first, then 2 etc? Or is
there something in the code that prevents that?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 17 May 2010 20:02:22 +0200
> Cc: monnier@iro.umontreal.ca, stephen.berman@gmx.net, 6192@debbugs.gnu.org
> 
> On Mon, May 17, 2010 at 7:53 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > When Emacs recenters, that means it exhausted all the other available
> > redisplay optimizations, and fell back on its default method of
> > completely redrawing a window.
> >
> > What you want is an optimization that does not yet exist, AFAIK.  It
> > needs to be designed and coded.  The tricky part is to detect the
> > situation where the amount of scrolling can be easily computed in
> > advance, and do that computation without too many complications.  You
> > seem to think that this computation is easy, but that is only true
> > when the display shows characters of the same size everywhere.  In the
> > more general case, what do we do? still recenter?
> 
> 
> Would it be possible to try 1 line scrolling first, then 2 etc?

Maybe we could, but that would be slow, I think.  Don't forget that
there could be more than one window affected by resizing.  And since
redisplay in general works on each window independently, tieing
together redispay of the echo area and the windows above the mode line
would be a complication.  Is it really worth that?

Also, note that scrolling only by the minimum amount will cause
annoying jumpy display if some command repeatedly displays messages of
different length in the echo area.  Recentering once avoids that to a
large degree, because it more often than not will scroll just once.

In general, my advice to people who are annoyed by recentering to set
resize-mini-windows to nil (among other things).

But if someone wants to work on a redisplay optimization that would
favor such scrolling, feel free.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Lennart Borgman]

On Mon, May 17, 2010 at 8:30 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> Would it be possible to try 1 line scrolling first, then 2 etc?
>
> Maybe we could, but that would be slow, I think.  Don't forget that
> there could be more than one window affected by resizing.  And since
> redisplay in general works on each window independently, tieing
> together redispay of the echo area and the windows above the mode line
> would be a complication.  Is it really worth that?


Maybe not. Here is another suggestion:

- We could by default show messages truncated. Then we could have a an
idle timer that after maybe 2 second showed the message wrapped.

That would stop the annoying jumping caused by messages we still do
not have a chance to see in the echo area because they are overwritten
by later message (often leaving the lower line blank in the echo
area).


> Also, note that scrolling only by the minimum amount will cause
> annoying jumpy display if some command repeatedly displays messages of
> different length in the echo area.


The above suggestion would take care of that too.


> Recentering once avoids that to a
> large degree, because it more often than not will scroll just once.


Recentering go away! ;-)


> In general, my advice to people who are annoyed by recentering to set
> resize-mini-windows to nil (among other things).


Maybe that is enough, but it could be combined with my suggestion above.


> But if someone wants to work on a redisplay optimization that would
> favor such scrolling, feel free.

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Lennart Borgman]

>> In general, my advice to people who are annoyed by recentering to set
>> resize-mini-windows to nil (among other things).

Why is not that a custom option?

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Stefan Monnier]

> - We could by default show messages truncated. Then we could have a an
> idle timer that after maybe 2 second showed the message wrapped.

> That would stop the annoying jumping caused by messages we still do
> not have a chance to see in the echo area because they are overwritten
> by later message (often leaving the lower line blank in the echo
> area).

That is a largely orthogonal issue (e.g. for eldoc it probably wouldn't
be a good approach).

But yes, I'd like to introduce a new kind of message that doesn't just
"display it now" but rather "display this for N seconds, but return
right away".  I.e. a form of "message" that would queue the message for
display and then a separate "thread" that would display the
messages queued.  This would avoid/solve many of the "my message was
overwritten by yours" problems.


        Stefan

bug#6192: 24.0.50; eldoc-mode: unexpected recentering

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Fri, 14 May 2010 19:11:30 +0200
> 
> => This puts point at line 902 (at least here, with window-height 33),
> which is at the bottom of the window as it should be -- but only for a
> fraction of a second, and then point is recentered so that line 902 is
> now in the middle of the window.

I cannot reproduce this on MS-Windows.  In my case, M-v from the end
of the buffer puts point on line 902, but it is the second line from
the bottom of the window, not the first.  And even if I then type C-n,
point stays on the last line.  I see no recentering at all.

Anyway, from what you say it sounds like the message displayed by
eldoc-mode in the echo area, which causes redisplay, somehow makes
Emacs think the window where you have the Lisp file needs to be
recentered because point is in a line that is not visible enough.

Do you see the same problem in Emacs 23.2?

bug#14520: 24.3; minibuffer resizes when message contains bold or italic text

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

> 1. Let ~/.emacs consist of the following line:
> (add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
>
> 2. Start Emacs with the above init-file.
>
> 3. Visit an Emacs lisp file that's long enough to scroll a number of
> screens up and down, e.g. lisp/abbrev.el from the Emacs source
> directory.
>
> 4. Type `M->' (end-of-buffer).
>
> 5. Type 'M-v' (scroll-down-command)
>
> => This puts point at line 902 (at least here, with window-height 33),
> which is at the bottom of the window as it should be -- but only for a
> fraction of a second, and then point is recentered so that line 902 is
> now in the middle of the window.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I'm unable to reproduce this problem in Emacs 29 -- are you still seeing
this issue in recent Emacs versions?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14520: 24.3; minibuffer resizes when message contains bold or italic text

[Stephen Berman]

On Thu, 05 May 2022 14:20:26 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> 1. Let ~/.emacs consist of the following line:
>> (add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
>>
>> 2. Start Emacs with the above init-file.
>>
>> 3. Visit an Emacs lisp file that's long enough to scroll a number of
>> screens up and down, e.g. lisp/abbrev.el from the Emacs source
>> directory.
>>
>> 4. Type `M->' (end-of-buffer).
>>
>> 5. Type 'M-v' (scroll-down-command)
>>
>> => This puts point at line 902 (at least here, with window-height 33),
>> which is at the bottom of the window as it should be -- but only for a
>> fraction of a second, and then point is recentered so that line 902 is
>> now in the middle of the window.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I'm unable to reproduce this problem in Emacs 29 -- are you still seeing
> this issue in recent Emacs versions?

No, I can't reproduce it now either.

Steve Berman

bug#14520: 24.3; minibuffer resizes when message contains bold or italic text

[Lars Ingebrigtsen]

Stephen Berman <stephen.berman@gmx.net> writes:

>> I'm unable to reproduce this problem in Emacs 29 -- are you still seeing
>> this issue in recent Emacs versions?
>
> No, I can't reproduce it now either.

Thanks for checking; I'm closing this bug report, then.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#14520: bug#6192: bug#14520: 24.3; minibuffer resizes when message contains bold or italic text

[Eli Zaretskii]

> Cc: 14520@debbugs.gnu.org, 6192@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 05 May 2022 14:20:26 +0200
> 
> Stephen Berman <stephen.berman@gmx.net> writes:
> 
> > 1. Let ~/.emacs consist of the following line:
> > (add-hook 'emacs-lisp-mode-hook 'turn-on-eldoc-mode)
> >
> > 2. Start Emacs with the above init-file.
> >
> > 3. Visit an Emacs lisp file that's long enough to scroll a number of
> > screens up and down, e.g. lisp/abbrev.el from the Emacs source
> > directory.
> >
> > 4. Type `M->' (end-of-buffer).
> >
> > 5. Type 'M-v' (scroll-down-command)
> >
> > => This puts point at line 902 (at least here, with window-height 33),
> > which is at the bottom of the window as it should be -- but only for a
> > fraction of a second, and then point is recentered so that line 902 is
> > now in the middle of the window.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> I'm unable to reproduce this problem in Emacs 29 -- are you still seeing
> this issue in recent Emacs versions?

It can legitimately happen if the bold font is either slightly higher
that the default font, or the line displayed by eldoc is longer than a
single screen line.

This is not a bug, even if it still can be reproduced.

However, the OP didn't say what was on line 902 of abbrev.el in that
version of Emacs, so it is impossible to find out what actually
happened.