Childframe covers company popup about eldoc-box HOT 29 OPEN

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

from eldoc-box.

@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.

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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.

from eldoc-box.

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.

from eldoc-box.

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

from eldoc-box.

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?

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

yes, If I clone and load it works fine.

from eldoc-box.

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!

from eldoc-box.

Cool

from eldoc-box.

#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?

from eldoc-box.

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.

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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.

from eldoc-box.

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?

from eldoc-box.

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|)

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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

from eldoc-box.

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...

from eldoc-box.

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.

from eldoc-box.

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.

from eldoc-box.