Recent regressions? in `live-completion-do`

[protesilaos]

Hello @oantolin! I believe there has been one or possibly two regressions in live-completion-do.

M-x throwing an error (basically completing-read)

Using emacs -Q and the following code:

(add-to-list 'load-path "~/.emacs.d/prot-dev/live-completions")

(require 'live-completions)

(live-completions-mode -1)

(live-completions-do (:height (/ (frame-height) 3))
  (call-interactively 'describe-function))

With the above live-completions-do I can search for a docstring, which works properly, but a subsequent M-x will return the message completing-read: Symbol’s function definition is void: nil.

live-completions-mode echoes help buffers

Using emacs -Q and the following code:

(add-to-list 'load-path "~/.emacs.d/prot-dev/live-completions")

(require 'live-completions)

(live-completions-mode 1)

(live-completions-do (:height (/ (frame-height) 3))
  (call-interactively 'describe-function))

The initial call for a docstring will produce a "Help" buffer as expected, but another call of the above live-completion-do will display the help inside the area that would normally be occupied by the "Completions" buffer.

Note though that the lower window is actually an expanded echo area, as suggested by C-h e:

Possible cause

I expect the first case to be related to commit 25db29f and may have to do with how live-completions-read is parsed. Sorry for not having some concrete idea…

As for the second, I discovered it while troubleshooting the first. I do not know whether this is a recent issue or not, as I normally use display-buffer-alist for the Help buffers (never noticed anything out of the ordinary).

[oantolin]

Hi @protesilaos! Thanks for the report and the simple instructions to reproduce.

M-x throwing an error

This is definitely a bug! I've fixed it in commit 82096c3.

Here's what was going on, in case you are curious. In your instructions to reproduce you turn off the mode before ever turning it on! My code made the silly mistake of assuming the mode was only ever turned off after being turned on, so it blindly "restored" the previous value of completing-read-function from live-completions--old-crf, which starts out as nil. The fix is simple: check there actually is an old value prior to restoring.

You probably noticed this with bug with your config first, not from emacs -q. And you only noticed it because you have an unnecessary (live-completions-mode -1) in there. :)

live-completions echoes help buffers

This one I don't believe is actually a bug. I think that what is going on is that the help in the echo area is a return value!

• The live-completions-do macro returns whatever its body returns (this is definitely intentional on my part).
• (call-interactively 'describe-function) returns whatever describe-function returns.
• describe-function returns the docstring!
• When you evaluate the code in the scratch buffer, via either C-x C-e or C-M-x, the return value of the code is echoed.

Normally when you call commands, say from a keybinding or from M-x, their return values are not echoed, which is why I never noticed that describe-function returned anything! The prot/live-completions-describe-* functions have been returning the docstring all along, you just never saw the return value.

Here are two ways to confirm my diagnosis:

1. Use C-j to evaluate the call to live-completions-do: eval-print-last-sexp inserts the result in the minibuffer rather than echoing it.

2. Change the form you evaluate so it doesn't return the docstring:

(live-completions-do (:height (/ (frame-height) 3))
  (call-interactively 'describe-function)
  "Function described!")

Does this make sense?

[oantolin]

(This issue also made me realize the :height parameter was affecting all temp buffers, not just the completions buffer, which was noticeable in the help buffers in your example. I've fixed that too, 0c7bdac.)

[protesilaos]

Thank you @oantolin for fixing this and for the detailed explanations. Just pulled the changes and can confirm things work.

I did notice the part about hiding the help text, but here is a bug I found. Consider this scenario with C-h f:

Notice that the point is on the first character of the match at the top. Any command there that checks for thing at point will fail. Whereas it works when on the second character. This only concerns the match at the very top: others work as expected.

To find what the first character's "thing" is I used the following:

(defun prot/completions-kill-save-symbol ()
    "Add symbol-at-point to the kill ring.

Intended for use in the \\*Completions\\* buffer.  Bind this to a
key in `completion-list-mode-map'."
    (interactive)
    (kill-new (thing-at-point 'symbol)))

It gives me "Possible", which I think is the first word of the help text being hidden. With point at the second character the same command returns the symbol correctly, "live-completions-do" in this screenshot.

[oantolin]

Thanks for testing! I'll think about this bug with the first match. I've known about it for a while, but it's a little tricky to decide what the best thing to do is. I used to delete that text rather than make it invisible, but found that some functions assume the very first character in the buffer is not in a completion...

[protesilaos]

I see. It might be tricky. No worries though.

[oantolin]

Since both choose-completion and switch-to-completions expect the message to be there (and possibly other commands as well), I decided to keep it invisible. But I now forcibly move point to the first completion if you try to run a command before the invisible message (b77a3f0). This should take care of the problem for the most part.

Please test.

[protesilaos]

I can confirm that it works. Nice trick!

EDIT: I think this issue can be closed now. Thanks again!

[oantolin]

Excellent, closing. And thanks again for the detailed bug reports.