emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI


From: Stefan Monnier
Subject: Re: Emacs completion matches selection UI
Date: Fri, 20 Dec 2013 09:32:11 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

>>> If theres another point to this debate, please forgive me, because
>>> I have missed it.
>> Personally, I'm trying to understand what it is that Ted is suggesting.
> I've explained it so many times I'm starting to wonder if my English is
> the problem.

It's never really control of language, but each word can mean many
different things, and we seem to have very different assumptions and
contexts, hence the difficulty.

The way I see it, the subject under discussion can be divided into various
mostly orthogonal elements:
- when does the completion code get invoked:
  - upon hitting TAB
  - after typing the first N chars of a completable element
  - when entering minibuffer
  - ...
- what completion operations take place:
  - insert a few chars at point
  - bring up a list of candidates
  - ...
- how to display the list of candidates:
  - in a separate buffer
  - at point, via clever overlay tricks
  - at point, via a special frame
  - at point, via a x-popup-menu
  - ...
- what operations can be performed while the list of candidates is displayed:
  - keep on editing as if the list was not displayed
  - select among candidates with the mouse
  - select with up/down
  - ...
- how/when to update the list of completions and to pop it down.
- what Lisp function to call to display the list of elements.
  We currently don't really have something clear here.  IIUC this is the
  API part you care about (the rest is mostly behavior rather than API).
- ...

Can you clarify which parts you care about?  As said, many are (or
should be) orthogonal.

> Yup, absolutely.  The autocomplete web browser widgets (e.g. the jQuery
> UI one) have that on-the-fly narrowing.  This specifically conflicts
> with the way in-buffer completion works right now,

It doesn't conflict at all.  The current UI doesn't update *Completions*
on-the-fly, but it very much could (and pretty easily too).

> and the in-minibuffer completion kind of works like this if you turn
> `icomplete-mode' on and hit TAB to see the candidates every time you
> type a character.  IMO this should be an API option.

I don't see why it should appear in the API.  It looks like a user
preference instead.  See below for a very crude approximation.


        Stefan


;; Verbose icomplete-mode

(defun verbose--icomplete-do ()
  (let ((beg (minibuffer-prompt-end))
        (end (point-max))
        (non-essential t))
    (when (and (not (eq beg end)) buffer-undo-list)
      (while-no-input
        (minibuffer-completion-help beg end)))))

(defun verbose-icomplete-setup ()
  (when minibuffer-completion-table
    (add-hook 'post-command-hook #'verbose--icomplete-do nil 'local)))

(define-minor-mode verbose-icomplete-mode
  ;; FIXME: find a better name
  ""
  :global t
  (if verbose-icomplete-mode
      (add-hook 'minibuffer-setup-hook 'verbose-icomplete-setup)
    (remove-hook 'minibuffer-setup-hook 'verbose-icomplete-setup)))




reply via email to

[Prev in Thread] Current Thread [Next in Thread]