Width doesn't seem to adapt properly for multi-line items

[parbo]

If the first item shown is small it will display fine, but if then show a bigger item, and go back to the smaller item, then the width doesn't adjust down to the smaller size. Only the height changes.

However, if I make it show a single-line item, then the width goes back down.

[casouri]

Just to clarify, you make eldoc-box show three different doc at three different locations, first and last small, the second one large, and for the third one the child frame doesn't automatically shrink? Could you show some screenshots? That'll be extra clear.

[parbo]

No, I mean in sequence. Hovering different things in eglot. I'll add some screenshots.

…

On Mon, Apr 3, 2023, 22:10 Yuan Fu ***@***.***> wrote: Just to clarify, you make eldoc-box show three different doc at three different locations, first and last small, the second one large, and for the third one the child frame doesn't automatically shrink? Could you show some screenshots? That'll be extra clear. — Reply to this email directly, view it on GitHub <#68 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA52CQ5JZXM4YNASG7BOKZ3W7MVCLANCNFSM6AAAAAAWQ4QOFI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[parbo]

Correct size:

Something bigger:

Back to the small one (now too wide):

Showing a single line doc and then the small one again, makes the small one have correct width again.

[casouri]

Thanks. I think this is due to the markdown separator. You see, one of the prettifier replaces markdown's separator with a strike-through line with a display text property. The display property specifies that the width of the strike though is the width of the window. That might interfered with window-text-pixel-size, which return the size of the text in a window, and is used by eldoc-box to determine the frame size for the childframe.

Anyway, I added a (harmless) workaround that should fix this.

[mrsch]

This workaround breaks the childframe for me.
It causes the childframe to be 1 by 1 character in size sometimes:

[casouri]

The workaround probably just exposed this problem, rather than caused it. Could you give me a reproduce recipe?

[deifactor]

I've noticed the issue @mrsch mentioned happening when using the pure GTK version of emacs (I'm using sway; not sure about X or other compositors). it doesn't always happen, but it happens eventually if I just move point around enough. It goes away if I get rid of the workaround (but then of course I get the behavior the workaround fixes). I think something doesn't like setting the frame width rapidly and it gets 'stuck' on the first frame size.

[deifactor]

Aha, it seems to consistently happen if and only if the new documentation frame would be the same size as the old one (moving point within an identifier, is one way to trigger this, but I verified it's not the only way). I think this is an emacs bug.

[casouri]

I added a workaround for the workaround. Not sure it'll fix the problem though, let's see :-)

[casouri]

Oops, I just see your patch. Let me have a look!

[deifactor]

Just tried and (redisplay t) doesn't fix it. The weird thing is that if I add

(message (format "%s %s" (frame-height frame) (frame-width frame)))
(run-with-idle-timer 0 nil (lambda () (message (format "%s %s" (frame-height frame) (frame-width frame)))))

then the first message has the size from (set-frame-size) and the second is 1 1.

[casouri]

Ok, I pushed another fix following your idea. Could you give it a try?

[deifactor]

It works! And that's a much cleaner solution.

[casouri]

Great. Thanks for your PR, and the detailed commit message, I appreciate it 😊