Childframe covers company popup

[casouri]

From #11

[casouri]

@andreyorst I made a patch and it seems to work for the simplest case. Let's use it for a while and see if other problems occur.

[andreyorst]

great! will it be available on melpa or should I install it from git and use some branch to test?

[casouri]

Melpa is up to date, you can just use that. 😄

[andreyorst]

Thanks, I've tried that, I think it's nice workaround, but not as final solution, since it simply displays eldoc as it would without your package, and I've installed your package to stop that behavior, because it visually moves my buffers when shown or hidden. Another possible workaround would be to display it not at point, like when eldoc-box-hover-at-point-mode is disabled, which would be nicer, since it still uses childframes, but positions those in non distracting way.

I wonder I you can borrow some ideas from https://github.com/expez/company-quickhelp to display eldoc at point, but position it correctly accordingly to company.

[casouri]

Sounds like a good idea. You can try the patch here: https://github.com/casouri/eldoc-box/tree/cover-company-fix

However, this would cover company-quickhelp if it is enabled, what should we do in that case? Judging from the source of company-quickhelp, there's no good way to get the geometry of the pos-tip it uses.

[andreyorst]

However, this would cover company-quickhelp if it is enabled, what should we do in that case? Judging from the source of company-quickhelp, there's no good way to get the geometry of the pos-tip it uses.

I guess in this way eldoc-box should disable at-point hovering and fallback to posframe at default position.

Sounds like a good idea. You can try the patch here: https://github.com/casouri/eldoc-box/tree/cover-company-fix

I'm getting these errors:

error in process filter: eldoc-box--default-at-point-position-function-1: Symbol’s value as variable is void: pos-in-window
error in process filter: Symbol’s value as variable is void: pos-in-window

[casouri]

I guess in this way eldoc-box should disable at-point hovering and fallback to posframe at default position.

That's a good idea. Should we just let users do that? I.e., don't use at-point-hover when you also use company-quickhelp.

I'm getting these errors:

I don't get these errors. And my patch didn't touch that part of the code. Could you verify if you are at f292d28?

[andreyorst]

That's a good idea. Should we just let users do that? I.e., don't use at-point-hover when you also use company-quickhelp.

yes, I guess.

I don't get these errors. And my patch didn't touch that part of the code. Could you verify if you are at f292d28?

I've just switched branch and copied file contents, since I don't know how to install packages from git with use-package

[casouri]

That's strange, I cloned the branch fresh and loaded the file, and still don't see the error.

[andreyorst]

yes, If I clone and load it works fine.

[andreyorst]

Tried your package again with Mate (still waiting when Gnome Shell related issue will be fixed) and I think this issue is fixed and can be closed. Eldoc Box shows up correctly near the company popup and follows cursor as you type.

However I have another thoughts about eldoc-box behavior, and I'll describe those in another issue. Thanks!

[casouri]

Cool

[andreyorst]

#21 (comment)

Ah, finally figured out how to reproduce this issue:
Here I change the size of treemacs buffer. If you toggle these two images you'll notice that eldoc-box position is not changed between those [1], [2]

display-line-number-mode also doesn't affect eldoc-box position: [1], [2]

Disabling treemacs and display-line-numbers-mode fixes the issue.
Actually any left window breaks positioning in right window for some reason:

• imenu-list buffer affects position of eldoc-box:
  

• Buffer on the left affects position of eldoc-box in right buffer:
  

@casouri can you reopen this issue?

[andreyorst]

Can be reproduced without any configuration in emacs -q after evaluating

(progn (package-initialize) (require 'eldoc-box) (require 'eglot) (require 'company))

Enabling eglot, company-mode, eldoc-box-hover-at-point-mode and display-line-numbers-mode produces this result:

This is Emacs 27.

[casouri]

Thanks for your work. I’ll look into it.

[casouri]

The line-numbers-mode problem should go away now.

[casouri]

Since you use Linux, could you tell me whether the y-position is off when you turn on tool-bar-mode?

[andreyorst]

@casouri I can't check, since I'm also experiencing this issue #24

[andreyorst]

Changing code like this:

-  (let* ((pos (pos (posn-at-point point window)))
+  (let* ((pos (posn-at-point point window))
          (x-y (posn-x-y pos))
          (window (posn-window pos))
          (edges (window-body-pixel-edges window)))

makes it work, but position is not correct:

As for tool-bar-mode it affects the position in a correct way. E.g. the position on screenshots above do not change with or without tool bar

[andreyorst]

Yet it seems that this positioning problem is shared among other plugins like company-box. So this may be GNOME Shell related. Although old code doesn't seem to have that problem.

[casouri]

Ok, here's what I know. display-line-numbers-mode invoked problem because it is squeezed into the window, therefore, the x value returned by company is off the width of the line numbers. My last fix fixes that problem (for me). I'm not sure why imenu-list has a problem - it seems to use a regular window and it worked fine for me. Maybe you mean the childframe didn't automatically update position when imenu-list popup up?

[andreyorst]

It seems that the problem with the leftmost windows is fixed as well

I just mean that instead of displaying under the cursor, box is displayed over the current line

(cursor is after args|)

[casouri]

Yes, that's what I'm trying to solve. That happens when I endable tool-bar-mode. You enabled tool-bar-mode, no?

[andreyorst]

Tool bar mode doesn't affect position in my case. Both on and off the position is the same for any box

[andreyorst]

Found it. global-tab-line-mode is the root of the issue. It's the same as header-line but uses additional tab-line area added in Emacs 27

[casouri]

I see, let me try to figure out how to get the height of the tab-line.

[casouri]

I think I got it for the most part. gloabl-tab-bar-line doesn't create problem now at least. The positions in a window/frame in Emacs is such a mess...

[casouri]

BTW, could you check if the childframe is off by 1 pixel? I observed it on my machine:

Well maybe that's not exactly 1 pixel, but you know what I mean.

[andreyorst]

I think I got it for the most part. gloabl-tab-bar-line doesn't create problem now at least. The positions in a window/frame in Emacs is such a mess...

You can look at this library. It has no problems with resize in Gnome and positioning as far as I can tell.

BTW, could you check if the childframe is off by 1 pixel? I observed it on my machine:

Well maybe that's not exactly 1 pixel, but you know what I mean.

It seems there's no such problem on my machine.