emacs-devel
[Top][All Lists]
Advanced

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

Re: Completing with anything


From: Antoine Levitt
Subject: Re: Completing with anything
Date: Thu, 26 May 2011 09:50:09 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

26/05/11 04:23, Stefan Monnier
>>> Another is to do it more selectively, flag some of
>>> completion-at-point-functions as "not-exclusive", meaning that if
>>> completion fails with those we should keep trying with subsequent
>>> functions.  E.g. the nick completion in rcirc could be flagged as
>>> non-exclusive since it applies everywhere, which in turn would let
>>> your dabbrev-expand kick in when nick-completion fails.
>
>> This seems to be the most flexible, while still keeping all the
>> completions in the same UI. I'd make the non-exclusive behaviour the
>> default though: let the functions that want to "take over" the
>> completion state it explicitely.
>
> I actually much prefer the it the other way around.
> Most completion-at-point-functions should be pretty specific, checking
> the context to decide whether they should be used at point, so they can
> be exclusive.
> Can you try the patch below to see if it gives you back the old behavior
> in ERC?
>
>
>         Stefan
>
>
> === modified file 'lisp/erc/erc-pcomplete.el'
> --- lisp/erc/erc-pcomplete.el 2011-04-29 15:23:59 +0000
> +++ lisp/erc/erc-pcomplete.el 2011-05-26 02:12:19 +0000
> @@ -73,7 +73,10 @@
>    "ERC completion data from pcomplete.
>  for use on `completion-at-point-function'."
>    (when (> (point) (erc-beg-of-input-line))
> -    (pcomplete-completions-at-point)))
> +    (or (let ((pcomplete-default-completion-function #'ignore))
> +          (pcomplete-completions-at-point))
> +        (nconc (pcomplete-completions-at-point)
> +               '(:exclusivity 'non-exclusive)))))

There's a double quoting here that messes up the test (took me a while
to figure out why 'non-exclusive was not equal to non-exclusive
...). Also, the

(let ((pcomplete-default-completion-function #'ignore))
  (pcomplete-completions-at-point))

check always return non-nil, so I removed it for testing purposes (not
sure what your intent was here).

With these two modifications, it runs fine (that is, using the old calling
convention and just using (setq-default completion-at-point-functions
'(my-dabbrev-expand)))

>  
>  (defun erc-pcomplete ()
>    "Complete the nick before point."
>
> === modified file 'lisp/minibuffer.el'
> --- lisp/minibuffer.el        2011-05-24 02:45:50 +0000
> +++ lisp/minibuffer.el        2011-05-26 02:16:05 +0000
> @@ -1436,9 +1436,13 @@
>   `:predicate'           a predicate that completion candidates need to 
> satisfy.")
>  
>  (defvar completion--capf-misbehave-funs nil
> -  "List of functions found on `completion-at-point-functions' that 
> misbehave.")
> +  "List of functions found on `completion-at-point-functions' that misbehave.
> +These are functions that neither return completion data nor a completion
> +function but instead perform completion right away.")
>  (defvar completion--capf-safe-funs nil
> -  "List of well-behaved functions found on `completion-at-point-functions'.")
> +  "List of well-behaved functions found on `completion-at-point-functions'.
> +These are functions which return proper completion data rather than
> +a completion function or god knows what else.")
>  
>  (defun completion--capf-wrapper (fun which)
>    ;; FIXME: The safe/misbehave handling assumes that a given function will
> @@ -1451,9 +1455,23 @@
>          (optimist (not (member fun completion--capf-misbehave-funs))))
>        (let ((res (funcall fun)))
>          (cond
> -         ((consp res)
> +         ((and (consp res) (not (functionp res)))
>            (unless (member fun completion--capf-safe-funs)
> -            (push fun completion--capf-safe-funs)))
> +            (push fun completion--capf-safe-funs))
> +          (and (eq 'non-exclusive (plist-get (nthcdr 3 res) :exclusivity))
> +               ;; FIXME: Here we'd need to decide whether there are
> +               ;; valid completions against the current text.  But this 
> depends
> +               ;; on the actual completion UI (e.g. with the default 
> completion
> +               ;; it depends on completion-style) ;-(
> +               ;; We approximate this result by checking whether prefix
> +               ;; completion might work, which means that non-prefix 
> completion
> +               ;; will not work (or not right) for completion functions that
> +               ;; are non-exclusive.
> +               (null (try-completion (buffer-substring-no-properties
> +                                      (car res) (point))
> +                                     (nth 2 res)
> +                                     (plist-get (nthcdr 3 res) :predicate)))
> +               (setq res nil)))
>           ((not (or (listp res) (functionp res)))
>            (unless (member fun completion--capf-misbehave-funs)
>              (message



reply via email to

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