casouri / eldoc-box Goto Github PK

Sometimes eldoc is big. It would be nice to be able to scroll output. lsp-ui-doc has this feature, and also can be resized and focused with mouse.

This end paragraph was truncated:

How did you get proportional fonts in eldoc as shown in the readme?

Hello,

First, let me thank you for this package.

I'm facing a problem with eldoc-box-hover-at-point-mode, it works fine with simple frames, but if I enable menu-bar-mode, tab-bar-mode, tool-bar-mode or tab-line-mode, they get included in every eldoc-box child frame.

Here are some examples:

With tab-bar-mode enabled

With tool-bar-mode enabled

Thanks for this nice package.

I'm wondering if it is possible to set the child frame to transparent? I tried to add alpha value to the eldoc-box-frame-parameters but this doesn't work.

This will be a nice feature, as sometime the child frame blocks part of the screen.

Hi, thanks for the great package. It will be awesome if it is possible to integrate eldoc-box with company-mode, just like company-quickhelp-mode which uses pos-tip instead of childframe.

I am running Linux and are seeing some display issues with this, perhaps an idea could be to use this library for display logic:
https://github.com/tumashu/posframe

I have found that to be quite stable. Also found this https://github.com/gexplorer/eldoc-posframe, but that one has not been published to MELPA, perhaps efforts could be joined as they both seem to solve the same problem.

Thanks for the package, I've been meaning to do this myself for a while, but haven't gotten around to it.

Sometimes, documentation is truncated and I want to see the whole documentation using eldoc-doc-buffer which opens a new split window:

But eldoc-box's childframe overlaps with it:

I tried (advice-add 'eldoc-doc-buffer :after 'eldoc-box-quit-frame), (advice-add 'eldoc-doc-buffer :before 'eldoc-box-quit-frame) and

  (defun quit-eldoc-box-frame-before-doc-buffer (orig-fun &rest args)
    (eldoc-box-quit-frame)
    (apply orig-fun args))
  (advice-add 'eldoc-doc-buffer :around 'quit-eldoc-box-frame-before-doc-buffer)

(I don't understand advice yet fully, I think)
but that hides eldoc-doc-buffer's window too (so I don't see any documentation at all)

Dumb question, but is there a way to copy text from the child frame that pops up? I couldn't figure out a way to do this...

I'm trying to remove the tab bar from eldoc-box's frame, so I tried adding toggle-frame-tab-bar in eldoc-box-frame-hook. The documentation for it says: "Each function runs inside the new frame and receives the main frame as argument."

To my surprise the tab bar in my main frame is what gets toggled, while eldoc-box's frame always has a tab bar. Doing some digging I see that when the hook is called here: https://github.com/casouri/eldoc-box/blob/master/eldoc-box.el#L351 it's not being called in the context of the newly created frame.

I've worked around it in the mean time by using the following code in my hook:

(defun bjc/toggle-tab-bar-in-current-frame (&rest args)
    (with-selected-frame eldoc-box--frame
      (toggle-frame-tab-bar)))

I noticed with multiple windows, eldoc-box--window-side function was not always returning the correct side. This is especially problematic when window is split vertically and working in the bottom window.

Below seems to work better regardless of splits:

  (defun eldoc-box--window-side ()
    "Return the side of the selected window.
     Symbol ‘left’ if the selected window is on the left, ‘right’ if
     on the right. Return ‘left’ if there is only one window."
    (let* ((y (cdr (posn-x-y (posn-at-point))))
           (top (nth 1 (window-absolute-pixel-edges (selected-window))))
           (left-window (window-at-x-y 0 (+ y top))))
      (if (eq left-window (selected-window))
          'left
        'right)))

Also, different than but maybe related to above fix/change, someone else may find below useful. It is my offset positioning function to show eldoc-box to right (like sideline) unless horizontally split and then moves to more of a hover mode.

  (defun my/eldoc-box-set-offset(child-width child-height)
    "This adjusts the eldoc-box so that it's down and to far right of cursor,
     unless window is split horizontally, then looks more like `hover-at-point'."
    (let* ((win-width (- (nth 2 (window-absolute-pixel-edges)) ;right
                         (nth 0 (window-absolute-pixel-edges)))) ;left
           (small-window (> (frame-pixel-width) win-width))
           (x (if small-window
                  (+ 41 (car (window-inside-pixel-edges))
                     (car (posn-x-y (posn-at-point))))
                (- (caddr (window-inside-pixel-edges)) 8 child-width)))
           (y (+ 41 (cadr (window-inside-pixel-edges))
                 (cdr (posn-x-y (posn-at-point))))))
      (cons x y)))

  (setq eldoc-box-position-function #'my/eldoc-box-set-offset)

Here's a mash-up of positioning based on window splitting:

See gif:

I noticed that adding the line

(add-function :after after-focus-change-function (lambda () (redraw-frame)))

to my init.el helps.

I use Void Linux, dwm, emacs 28.1.

I think it may be because eglot uses the original frame width when sending information. Is there a way to solve this problem?

I'm seeing empty child frames in buffers where eglot is running (specifically with Python):

The screen shot is wit eldoc-box-hover-at-point-mode, but the same thing happens with eldoc-box-hover-mode.

The empty child frame occurs as soon as point is located somewhere where no doc is triggered.

The same thing doesn't happen in Elisp buffers, which is why I suspect eglot may be a factor.

Any idea what may be going on here? I read in issue #11 that there are issues on Linux, but the issues discussed there appear different from what I am seeing.

Arch Linux, Emacs 28.2.

It's chicken egg problem where to solve this, but recently I've started using lsp-mode with lsp-ui package, and found out that it's quite nice to see both information from eldoc and documentation on hover:

However there's a problem. When there's not enough space, or when lsp-ui just feels like it, it will show documentation below the cursor:

Eldoc box seem to always prefer below the point position which causes those two to overlap:

Also, documentation popup aligns to the word we currently at, not point, so I think it may be possible to figure out correct position for eldoc box to prevent overlapping

should be (face-attribute 'eldoc-box-border :background nil t) to get the inherited background color.

Hi,

Thank you for writing eldoc-box -- it's a very slick alternative to eldoc-doc-buffer.

Is it possible to specify (by pixel or line number) where the eldoc-box appears on the screen?

Here's the context:

I'm working on a replacement for org-mode's LaTeX preview system, which is planned to be included in Org 9.7. The new system generates previews asynchronously and very fast, fast enough that you can preview LaTeX fragments as you type. To display this, I implemented a child-frame version of the previews:

However from discussions with the Org maintainers I was told to show the live previews with Eldoc instead, and then folks can customize how it's displayed (echo area/dedicated buffer/child frame) with eldoc-display-functions, using eldoc-box if they want "pop-up" behavior like in the above video.

However, eldoc-box-hover-at-point-mode obscures the LaTeX fragment being edited with the box:

Fragment being edited:

Fragment previewed with eldoc box (Can't preview live because it covers the fragment):

Is it possible to specify where the box should appear dynamically? In my from-scratch child-frame implementation I place it immediately below the LaTeX environment being edited, whose pixel-position I know.

Display child-frame under the edited LaTeX env:

• GNU Emacs 26.1
• macOS Mojave
• Centuar Emacs https://github.com/seagle0128/.emacs.d

I see this faceeldoc-box-borderin eldoc-box, but it seems not working in my env.
I am not sure if it's a bug or configuration issue. Please help to take a look. Thanks in advance!

From #11

If I don't turn on eldoc-box-hover-mode or turn off mannally, the company will turn on eldoc-box-hover-mode again anyway, unless the eldoc-box is not loaded.

I think it is due to the patch:
5dbd370

Let's say I have frame-1 displaying code.py. Eldoc-box works as expected, document is shown in a childframe in the corner. If I switch to a different buffer on frame-1 and work on the code.py buffer in frame-2 instead. The eldoc-box childframe is still shown in the corner of frame-1. It should be in the corner of frame-2 instead.

For what it worth, I'm using frames-only-mode so each window gets its own frame.

Like the menu bar and tool bar, the tab bar should also be hidden when showing the child frame.

If you add

(tab-bar-lines . 0)

to the eldoc-box-frame-parameters here: https://github.com/casouri/eldoc-box/blob/master/eldoc-box.el#L89 it prevents the tab bar from showing.

When I edit an Elisp file, eldoc-mode displays the documentation of the symbol at point with the symbol name:

When I activate eldoc-box-hover-mode, the symbol is suddenly gone, however:

I just noticed this today, but I can't be sure how long it has been the case already. I'm just fairly certain it wasn't the case at some point in the past.

I'm on Emacs 28.2, latest version of eldoc-box, Arch Linux.

I have a simple headerline for Treemacs buffer that displays Treemacs title at window center. I've enabled eldoc-box-hover-at-point-mode for all eldoc managed buffers, and noticed that the position is wrong:

Disabling headerline for Treemacs buffer fixes the bug:

Also noticed this in org src caprured buffer a while ago:

Since the headerline in org capture buffer is precisely 1 line, eldoc box is displayed 1 line lower. In Treemacs headerline has box attribute, which makes eldoc box appear lower more than 1 line.

Documentation is shown in minibuffer and quickly disappears when it should appear in childframe and stays there until any command is invoked.

Here is the link to the function:

I noticed a lot of slowdown when moving the text cursor; after some investigation, I found out that having eldoc-box-hover-at-point-mode enabled causes this. eldoc-box-hover-mode doesn't have this issue.

I'm seeing an inactive cursor in the eldoc-box window (note the cursor over the f):

I tried (add-hook 'eldoc-box-buffer-hook (lambda() (setq cursor-in-non-selected-windows nil)) nil t), and even setting cursor-in-non-selected-window nil globally, but it was still there.

Support lsp just as as eglot.el is supported now: translate the textDocument/hover calls using lsp API

I've tried lsp-ui and I don't get the same experience. For example, lsp-ui may cover the current text the cursor is at, whereas eldoc-box positions itself as far away as possible.

I'm noticing two issues with the display of doc strings. This screen shot shows both:

• There are random sequences of   that appear occasionally. (Some indentations are correct, others show as a series of  ).
• my_script is displayed as my\_script.

The actual doc strings in the source code don't contain non-breaking spaces, nor backslashes to escape underscores.

I'm using that command to open emacsclient.
emacsclient -a "" -n -c "$@"

But when I close and re-open Emacs, eldoc-box shows the error.

Error in pre-command-hook (eldoc-pre-command-refresh-echo-area): (wrong-type-argument frame-live-p #<dead frame  *eldoc-box* 0x65d5170>)
eldoc error: (wrong-type-argument frame-live-p #<dead frame  *eldoc-box* 0x65d5170>)
error in process filter: eldoc-box--get-frame: Wrong type argument: frame-live-p, #<dead frame  *eldoc-box* 0x65d5170>
error in process filter: Wrong type argument: frame-live-p, #<dead frame  *eldoc-box* 0x65d5170>

The issue is pretty much the same as #22 but now tab-line affects position.

When I try to call eldoc-box-eglot-help-at-point manually I get this error message:

 Symbol’s value as variable is void: contents

Hi

After f0b1bd2 CPU usage frequently hits 100%. This is probably because you used a repeating idle timer, where you probably meant a normal timer.

But, in general, that commit looks quite complicated. What is the problem that you were trying to fix?

Hi, thanks for the work on this library!

I'd like to bind eldoc-box-eglot-help-at-point to K to show the documentation for the symbol at point. This works for eglot managed buffers, but is it possible for non-eglot managed buffers to just put the standard eldoc contents into that same popup?

I'm not sure why the eldoc-box-eglot-help-at-point function has an eglot dependency while the eldoc-box-hover-at-point-mode does not? Basically I want the behavior of eldoc-box-hover-at-point-mode but I want to trigger it only when I call a function (which I will map to K).

Is this possible?

Simplest way to reproduce:
Open a source file, open treemacs, hover over a function.

When hovering over a function in the left window, the box appears on the top-right. (Which is expected)
When hovering over a function in the right window, the box appears on the top-left.
This is - as far as I can tell from the source code - intentional.

Firstly, the objective problem with this:
While using e.g. treemacs or neotree, they put a small frame on the left side of the window.
Because these frames are so narrow, the displayed eldoc-box 'spills over' into the main window and hides significant amounts of code.
This means one is pretty much unable to edit the first ~15 lines of any source file.

Since I always have treemacs open, this led me to assume this package was completely broken when I first used it.
Only after reading and trying to understand the source-code, I could understand what was going on. (Since this behavior isn't really documented).

Secondly, a more subjective point:
While the current behavior is well-intentioned, I think there is also some value to be found in placing the box always in the same position. This way the user knows where to expect it, and doesn't have to 'hunt it down' with their eyes every time.

For my personal purposesI have made an adaption to the existing eldoc-box--default-upper-corner-position-function, making it always display in the top right corner:

(defun eldoc-box--default-upper-right-corner-position-function (width _)
  (pcase-let ((`(,offset-l ,offset-r ,offset-t) eldoc-box-offset))
    (cons (- (frame-outer-width (selected-frame)) width offset-r)
               offset-t)))

My suggestion would be to make this behavior the default, as it is much less likely to frustrate or confuse new users.
The currently-default behavior could be made an opt-in to those users, who still like it.

Emacs 27 features new global-tab-line-mode and new tab-line area at the top of the window to display tabs. Turning it on shows tab in eldoc-box:

I think something like this should be used when creating child frame:

(when (bound-and-true-p global-tab-line-mode)
  (setq tab-line-format nil))

Would it be possible to pass t for NOERROR to (require 'eglot)? Right now, an error pops up every time I start Emacs complaining about eglot not being found.

Since I don't use eglot, I don't really mind if the eglot macro calls aren't compiled.

I use eldoc-box with elpy. After last update (20191102.410) i have message in minibuffer"error: (void-function pos)" every time when elpy tries to show some doc.
There is debugger output:

Debugger entered--Lisp error: (void-function pos)
  signal(void-function (pos))
  elpy-rpc--default-error-callback((void-function pos))
  elpy-promise-reject([*elpy-promise* (lambda (doc) (cond (doc (let ((name ...) (doc ...)) (let (...) (eldoc-message ...)))))) elpy-rpc--default-error-callback #<buffer something.py> nil] (void-function pos))
  elpy-promise-resolve([*elpy-promise* (lambda (doc) (cond (doc (let ((name ...) (doc ...)) (let (...) (eldoc-message ...)))))) elpy-rpc--default-error-callback #<buffer something.py> nil] ((name . "int()") (doc . "Convert a number or string to an integer, or return 0 if no arguments are given.")))
  elpy-rpc--handle-json(((result (name . "int()") (doc . "Convert a number or string to an integer, or return 0 if no arguments are given.")) (id . 22)))
  elpy-rpc--filter(#<process  *elpy-rpc [project:x:/someproject/ python:c:/Windows/py.exe]*> "{\"result\": {\"name\": \"int()\", \"doc\": \"Convert a number or string to an integer, or return 0 if no arguments are given.\"}, \"id\": 22}\n")

This is not a bug of eldoc-box, but rather a minor but annoying formatting issue caused by markdown-mode used by elgot. I've raised jrblevin/markdown-mode#754 to markdown-mode, but while waiting I'd like to ask some advice from you to find a temporary workaround since you are more familiar with eldoc and eglot.

To give you a background about what I was trying to do:

I set eldoc-documentation-strategy to eldoc-documentation-compose to show multiple source of eldoc. For example below buffer has 4 source (elisp-eldoc-var-docstring elisp-eldoc-funcall flymake-eldoc-function embark-eldoc-first-target):

By default there is no blank line to separate each source in eldoc buffer, so I override function eldoc--format-doc-buffer to add one (just add one more \n in the line of when rest do...). This looks nice:

Until I open a buffer with eglot sources (eglot-signature-eldoc-function eglot-hover-eldoc-function python-eldoc-function flymake-eldoc-function emabark-eldoc-first-target):

As you may see, there is one extra blank line from eglot-hover-eldoc-function, which is inconsistent with other sources. This is because of the issue that I've raised to markdown-mode. eglot-hover-eldoc-function use the view mode from markdown-mode to format the code in the lsp documentation with markdown format. And when markdown-mode hides the markup when enabling the view mode, it leaves an extra blank line if the "```" close mark is at the end of the buffer.

I was trying for several days to figure out a work-around to remove the extra blank line for eglot-hover-eldoc-function, but still not find out the correct. Hence I'd like to ask for some advice on how to modify this. Ideally it should be a more general solution to modify the eldoc-buffer or eglot-hover-eldoc-function but a eldoc-box specific method would also be great enough.

Sorry for bothering you with such a wall of text only for a minor format issue. I hope you may have some insight that can save me from this rabbit hole :)

Hi!

Awesome package! I've just added it to my Emacs configuration and it seem to be very promising.
Is it possible to upload the package to Melpa as well so it can be easily added to the configuration by e.g. using use-package?

More like a question, but can wrapping be enabled for eldoc-box?

I want to restrict maximum width to around 600px, an right now words are being wrapped at the middle:

 ___________________
|long line of arbitr|
|ary text           |

I think it would be better to wrap on words, rahter than on chars:

 ___________________
|long line of       |
|arbitrary text     |

I think this could be acheived by using visual line mode, but I don't quite get how to enable it for eldoc

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.

The following objects don't need to reference eglot any more in their respective docstrings:

eldoc-box-body
eldoc-box-quit-frame
eldoc-box--buffer

Similarly, the "About" section of this repo.

Sometimes I got errors like apply: Wrong type argument: frame-live-p, #<dead frame *eldoc-box* 0x79bcd98> after pressing C-g. I guess the problem is here:

(defun eldoc-box-quit-frame ()
  "Hide childframe used by eglot doc."
  (interactive)
  (when eldoc-box--frame
    (make-frame-invisible eldoc-box--frame t)))

Is it OK to replace when eldoc-box--frame with something like (frame-visible-p eldoc-box--frame)?

This plugin is now the definitive way of using eldoc for me. But I think it can be improved further a bit.

First of, now popup moves as long as we type text, or move with directional shortcuts. This is nice when typing and really annoying when moving around the code, because box closes most of the code below the cursor, even when you've moved to a different location, where the popup no longer makes sense.

I think it is logical to make eldoc box follow the cursor only on typing events, eg when modifying text in any way, and quickly disappear if we leaving the line on which it was displayed. Also hiding eldoc-box by using C-g would be nice addition.

Another thing that's bothers me is that you have to enable two modes in order to make eldoc hover near the cursor:

(eldoc-box-hover-mode)
(eldoc-box-hover-at-point-mode)

Why can't we simply call one of those? One for hover mode, the other for hover at point mode.

In Python buffers, where eglot is running, the child frame often doesn't show properly. Usually, I only see a small top-left corner:

In Elisp buffers, where eglot is not used, this usually happens the first time eldoc-box creates a child frame, but from the second time onward, the child frame is created correctly. In Python buffers, however, this keeps happening. Sometimes the child frame is displayed, sometimes it's not, and there doesn't seem to be any pattern behind it.

Note that the size of the child frame is not the issue, because I get large child frames in Elisp as well. (I put an advice on elisp-get-fnsym-args-string to show the entire doc string of functions.)

Any idea on what I could do to debug this further?

I'm on Arch Linux, X11, Emacs 28.2.

Hey,

I have been wishing for a package that do just what eldoc-box do to eldoc, a box that do that to echo-area.

Would not that be cool?!

I would love turning off echo-area and using a echo-box instead.

One day I will submit it to emacs core! hehe

Hi @casouri, after talking with @joaotavora on joaotavora/eglot#198, he suggested me to open this issue, and here I am.

I have a solution based on the Help at point hack suggestion from the README.
Pasted the code here.

First time the moon-help-at-point function is called when emacs is full screen on mac OS (latest from brew cask), it does some weird stuff:

• It's like it moves to another space
• A ghost space is created
• Space top controls cannot be accessed anymore
• It fails weirdly, showing part of the box, but far away from the cursor.

Then all following calls to it work normally, except for the effects described above.

Error recording video

Thanks!

EDIT: Realized it also fails when it's not in full screen, it just doesn't have the space implications but everything else remains: Video

After enabling eldoc-box-hover-mode, it does not show anything in the TTY emacs.

Just for the record, I noticed that every time the box pops up my background color was changed, sometimes back and forth. After disabling dimmer, this issue is gone.

I was experimenting with disabling eldoc echo display using (setq-local eldoc-display-functions '(eldoc-display-in-buffer)) in a hook, but I notice that after calling eldoc-box-help-at-point, echo display is re-enabled.

Putting a debug-watch on eldoc-display-functions points to eldoc-box--help-at-point-cleanup, which reverts eldoc-display-functions by killing the local value. I also see that eldoc-box--disable is unconditionally adding eldoc-display-in-echo-area to eldoc-display-functions.

Ideally these would restore the previous value of eldoc-display-functions rather than assuming it was set to the default, to preserve any customizations.

Lovely package, thank you for making it!