Eli Zaretskii writes: >> From: Eshel Yaron >> Cc: philipk@posteo.net, juri@linkov.net, dmitry@gutov.dev, >> stefankangas@gmail.com, 66948@debbugs.gnu.org, joaotavora@gmail.com >> Date: Fri, 10 Nov 2023 17:23:12 +0100 >> >> Thanks for reviewing. I'm attaching an updated patch (v4) following >> your comments. > > Thanks. > >> + Completion Preview mode is a minor mode that shows you symbol >> +completion suggestions as type. When you enable Completion Preview >> +mode in a buffer (with @kbd{M-x completion-preview-mode}), Emacs >> +examines the text around point after certain commands you invoke and >> +automatically suggests a possible completion. Emacs displays this >> +suggestion with an inline preview right after point, so you see in >> +advance exactly how the text will look if you accept the completion >> +suggestion---that's why it's called a preview. > > This is still too wordy, IMO. I suggest > > Completion Preview mode is a minor mode that shows completion > suggestions as you type. When you enable this mode (with @kbd{M-x > completion-preview-mode}), Emacs automatically displays the > suggested completion for text around point as an in-line preview > right after point; type @key{TAB} to accept the suggestion. LGTM, thanks. I'm attaching an updated patch (v5) below. > Also, one of these two index entries is redundant: > >> +@findex completion-preview-mode >> +@vindex completion-preview-mode > > Since the ELisp manual has just one Index node, it is enough to have > the @findex entry alone. Done. >> > Are completions produced for descendants of Text mode, for example? >> >> Sure. I'm running with `completion-preview-mode` in `text-mode-hook` myself. > > What is/are the backend(s) that provide(s) the completions in the > text-mode case? Is that just a word completion, or are we capable of > suggesting phrases as well? That's all up to what you put in your `completion-at-point-functions`. If you have a completion function that suggests phrases, it'll work just as well as word completion. The default value of `completion-at-point-functions` is not that useful for `text-mode` I'm afraid, but adding something like `dabbrev-capf` is easy enough and makes it much more useful. This is not a concern for Completion Preview, though. We just call the `completion-at-point-functions`. >> > Also, did you test this minor mode when Overwrite mode is in effect? >> >> Yes, no surprises there AFAICT, works well. > > What does it do in Overwrite mode if one accepts a completion? > If it overwrites the following text, I'm not sure it should. It inserts the completion suggestion without overwriting the following text, so that's fine. >> >> +(defcustom completion-preview-minimum-symbol-length 3 >> >> + "Minimum length of the symbol at point for showing completion preview." >> >> + :type 'natnum) >> > >> > Why do we need this defcustom? IOW, why not show the completion after >> > a single character? >> >> Basically, a single character often has many completion candidates, and >> most of them are not what you want. After three characters, the preview >> is much more likely to show you a useful candidate. So you can think of >> this option as an adjustable threshold for how much information we >> require the completion backend to have before we consider its >> suggestions any good. I'm open to changing the default value, but I >> think that three characters is a very sane default. > > The advantage of 1 character is that we don't need this defcustom at > all, and it is basically up to the user when to type TAB, or even look > at the preview. One character is not the same as removing this `defcustom`. Without this `defcustom`, i.e. without checking the length of the symbol at point, we would try to show the preview even after the user types a bunch of space and there is nothing useful to complete at point at all. > Alternatively, we could have a defcustom based on a different design: > show preview only when there are fewer than N completion candidates, > with N being customizable. That would make much more sense, IMO, > since it replaces a largely "mechanical" limitation with one that is > meaningful for users. That would indeed be a nice solution, but it has a fatal flaw, sadly. Computing the set of completion candidates is a costly operation, especially with backends such as LSP, so we don't want to do that after each command. We need some heuristic to decide when we're likely to obtain a valuable completion suggestion, otherwise we butt out. Checking the length of the symbol at point is cheap and it provides a good heuristic that's easy to understand and control. I'm open to changing the default to one character if you think that's preferable. I do think the `defcustom` itself should stay, though. >> >> +(defcustom completion-preview-hook >> >> + '(completion-preview-require-certain-commands >> >> + completion-preview-require-minimum-symbol-length) >> >> + "Hook for functions that determine whether to show preview completion. >> >> + >> >> +Completion Preview mode calls each of these functions in order >> >> +after each command, and only displays the completion preview when >> >> +all of the functions return non-nil." >> > >> > This feature sounds like over-engineering to me. >> >> I think this makes the mode nicely flexible, as it lets users and other >> code add different conditions for when to show the preview, e.g. only in >> or out of comments. And the added complexity is negligible, really. So >> I guess we could do without this option, but I'd prefer to keep it >> unless you feel strongly about that. > > I'd like to defer any extensibility features like this until we have > some data to support the need for such extensibility. Defining those > ahead of any real experience is a kind of premature optimization, IMO. Fine, removed. >> >> +(defface completion-preview-exact >> >> + '((t :underline t :inherit completion-preview)) >> > >> > The underline face is not universally supported, so this defface >> > should have fallbacks. >> >> The `underline` face in faces.el has `:underline t` in the fallback >> clause too, so I figured that should be alright, no? > > If you are okay with seeing no effect at all when the terminal doesn't > support the underline attribute, then yes. But I thought we want this > face to stand out no matter what, don't we? That's okay IMO, the underline just differentiates between when you have a single candidate and when you have multiple candidates. I don't think that's that crucial, but if you can suggest a universally supported fallback I'd be glad to add it, of course. >> >> +(defun completion-preview-require-minimum-symbol-length () >> >> + "Check if the length of symbol at point is at least above a certain threshold. >> >> +`completion-preview-minimum-symbol-length' determines that threshold." >> >> + (pcase (bounds-of-thing-at-point 'symbol) >> >> + (`(,beg . ,end) >> >> + (<= completion-preview-minimum-symbol-length (- end beg))))) >> > >> > Is usage of pcase really justified here, and if so, why? >> >> Since we're relying on `completion-at-point`, that already uses `pcase`, >> I'm not sure what's the cost of using `pcase` here too. > > Readability. A person who isn't familiar with pcase will not need to > go read the documentation to understand this code. Alright, I've change this function and another one to avoid `pcase`. FWIW I find `pcase` perfectly readable, but the alternative isn't too bad either in this case. >> >> + (add-text-properties 0 1 '(cursor 1) string) >> >> + (overlay-put completion-preview--overlay 'after-string string) >> > >> > Sounds like you keep calling overlay-put and adding the same property >> > to the string each time this function is called, even if the overlay >> > already shows the same string? >> >> Even if the preview exists, this function is called with a different >> `string` argument than the one already shown. That `string` is a >> substring of a completion candidate, and it doesn't already have the >> `cursor` property. So no, this is not redundant. There may be room for >> an optimization here, but I don't think it'd be significant. > > What bothers me is consing (which leads to GC). Testing a string for > equality is simple, and if that avoids extra consing, I think it's a > good optimization. Makes sense, I've added an optimization for when the string is the same as the existing `after-string`. This could happen if the user adds a command that doesn't change the buffer text to `completion-preview-commands` and uses that command. >> >> +(defun completion-preview--update () >> >> + "Update completion preview." >> >> + (pcase (let ((completion-preview-insert-on-completion nil)) >> >> + (run-hook-with-args-until-success 'completion-at-point-functions)) >> >> + (`(,beg ,end ,table . ,plist) >> > >> > Why use pcase here and not seq-let? >> >> Because `seq-let` doesn't do the right thing (for our purposes here) >> when the sequence that you pass it doesn't have the given shape. >> Namely, here `pcase` correctly handles the case where the value is nil >> for example, while `seq-let` would require another test in the body >> (e.g. `(when beg ...)`) to see if we actually got what we expected. > > Is that single extra test so important to avoid? It's not super important, but it's nice. Anyway I've now changed to `seq-let` here to avoid `pcase` as mentioned above. >> >> +(defun completion-preview--show () >> >> + "Show completion preview." >> >> + (when completion-preview-active-mode >> >> + (let* ((beg (completion-preview--get 'completion-preview-beg)) >> >> + (cands (completion-preview--get 'completion-preview-cands)) >> >> + (index (completion-preview--get 'completion-preview-index)) >> >> + (cand (nth index cands)) >> >> + (len (length cand)) >> >> + (end (+ beg len)) >> >> + (cur (point)) >> >> + (face (get-text-property 0 'face (completion-preview--get 'after-string)))) >> >> + (if (and (< beg cur end) (string-prefix-p (buffer-substring beg cur) cand)) >> >> + (overlay-put (completion-preview--make-overlay >> >> + cur (propertize (substring cand (- cur beg)) >> >> + 'face face)) >> >> + 'completion-preview-end cur) >> >> + (completion-preview-active-mode -1)))) >> >> + (while-no-input (completion-preview--update))) >> > >> > I'm puzzled by this function. What does it do, and why is it needed? >> >> I've added some comments in the updated patch. > > Thanks, but please also make the doc string more useful. It is now > too terse, IMO. Done. > Also, the last part is still quite obscure: why do you turn off > completion-preview-active-mode, I've added another comment to clarify that. > and why the while-no-input loop that calls completion-preview--update? `completion-preview--update` is where we invoke `completion-at-point-functions`, which might take some time depending on which backends you're using. So we wrap that with `while-no-input` and gracefully handle the case in which this function is interrupted, by virtue of the fact that we've already updated the preview to an acceptable state just now. > The comment which starts with "Reconsult" should be probably reworded > to be more self-explanatory; e.g., the word "backend" is barely used, > let alone explained, in the code or its comments. I've updated that comments to explicitly say `completion-at-point-functions` instead of "backends". > Btw, I noticed that your comments don't end in a period. They should, > at least when a comment is a complete sentence. Done, thanks. >> >> + (interactive) >> >> + (let ((completion-preview-insert-on-completion t)) >> >> + (completion-at-point))) >> > >> > Why not just insert the string you show in the preview? >> >> This way we let `completion-at-point` to take care of things like >> calling the `:exit-function`, instead of duplicating that code. > > Sorry, I still don't understand. What about :exit-function, and why > inserting the completion needs it? Some completion functions (that go on `completion-at-point-functions`) specify an `:exit-function` that should be called after a candidate they provide is inserted. This takes care of things like inserting parentheses after the inserted function name, and moving point to in between them. We want this to happen also when you insert the candidate from the preview. > Btw, did you consider an alternative design, where the completion is > displayed from an idle timer, not from a post-command-hook? The > latter means you make Emacs less responsive during fast typing (when > the user won't normally need the preview), whereas doing it from a > timer better suits the use case: a preview is shown when the user > might be considering what to type next. Yes, I considered that approach and tried it as well. The current implementation works well enough even when typing fast (let me know if you find otherwise), and it has the benefit of more immediate feedback. It's also nice to get the preview even you're typing fast, that's how some other editors behave too. Thanks for your comments, here's the new patch: