Disjointed documentation interface in OS X about company-quickhelp HOT 8 CLOSED

Yeah, I'm aware of this. It works for me 99% of the time, but sometimes I see what you see too. I use this on OS X and on Linux and while it happens rarely on Linux I've seen it.

I'm not sure what to do about it. It works most of the time for me, and when I can't reliable reproduce a problem I can't fix it either.

If you want to get your hands dirty the size and position of the overlay is controlled here:

https://github.com/expez/company-quickhelp/blob/master/company-quickhelp.el#L148-L153

I suspect pos-tip is really just best effort and sometimes pos-tip fails to deliver due to collision detection or whatever.

from company-quickhelp.

Interesting. When you see that on linux, do you also see a default system tooltip ignoring Emacs' face and colour settings?

Because as far as I can tell, the first problem with the reported issue here is that on mac (x-gtk-use-system-tooltips nil) will have no effect, and so the stock Emacs will use system tooltip, totally messing around with what the tooltip looks like. I have yet to investigate what's going on with the positioning, though.

from company-quickhelp.

When you see that on linux, do you also see a default system tooltip ignoring Emacs' face and colour settings?

No, I get a sense it happens because pos-tip feels there isn't room / something is in the way at the right position.

from company-quickhelp.

That would probably deserve its own, separate investigation, I suppose. All in good time.

from company-quickhelp.

Hi guys, thanks for your prompt replies. The point that @pitkali raised is interesting. I didn't know that OS X uses a native tooltip. I would be perfectly happy with a tooltip that didn't match the theme provided it showed up in the right place.

I first started thinking about this because I wanted to recreate the functionality that I saw in this video by Baris Yuksel. I realized later that this was a previous version of elpy that used autocomplete, but I still like the behavior.

Thanks to @expez for pointing out the section of the company-quickhelp code that controls the position of the overlay. I'm new to elisp and Emacs, but if I have some down time this weekend I might fiddle with this section of code on my mac and see what happens.

Would it make sense to use a wrapper like (when (eq system-type 'darwin) ... ) in this case to keep any changes from messing with Linux and Windows?

from company-quickhelp.

In short, no.

Firstly, I didn't have time to confirm this yesterday, but the problem is unlikely to be mac as an operating system (i.e., 'darwin), but rather one of the 2 UI toolkit implementations used on it, so (when (eq window-system 'ns) ...). Mac-port (which at least used to be distinguishable with window-system being 'mac) is fundamentally different, to the best of my memory, having originated from Carbon emacs, which predates the 'ns toolkit. I specifically remember it having a different tooltip implementation (i.e., different implementation of x-show-tooltip emacs C function that you can see pos-tip using eventually to actually show the tooltip). It should not be assumed it will behave the same way here.

Secondly, I would very much prefer to hide such differences between various toolkits in pos-tip. This may not be feasible in an acceptable way, depending on the actual root cause, but that would be the ideal scenario.

Nonetheless, if the issue is not fixed by the weekend, feel free to see if you can correct coordinates. If you find a way, it is likely to be useful as diagnostic information, helping us better understand what's going on.

from company-quickhelp.

@pitkali can I close this as a problem with pos-tip?

from company-quickhelp.

It's safe to assume that the problem does not lie with company-quickhelp, as then it should happen on all the platforms.

In short, yes.

from company-quickhelp.