From: Antoine Levitt <antoine.levitt@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org
Subject: Re: Completing with anything
Date: Thu, 26 May 2011 09:50:09 +0200 [thread overview]
Message-ID: <87mxi9lx3i.fsf@gmail.com> (raw)
In-Reply-To: <jwv8vtucigm.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 25 May 2011 23:23:38 -0300")
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
next prev parent reply other threads:[~2011-05-26 7:50 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-09 9:02 Announcing org-contacts, a bbdb-like contact manager for Org Julien Danjou
2011-02-09 19:00 ` John Hendy
2011-02-09 20:04 ` Sébastien Vauban
2011-02-09 20:43 ` Julien Danjou
2011-02-09 21:10 ` Russell Adams
2011-02-09 21:25 ` Marcelo de Moraes Serpa
2011-02-09 20:42 ` Julien Danjou
2011-02-10 14:34 ` John Hendy
2011-02-10 14:42 ` Julien Danjou
2011-02-09 19:16 ` Tassilo Horn
2011-02-09 19:26 ` John Hendy
2011-02-10 13:39 ` Dan Griswold
2011-02-10 14:42 ` Julien Danjou
2011-02-10 14:45 ` Dan Davison
2011-02-10 14:56 ` Julien Danjou
2011-02-10 15:05 ` John Hendy
2011-02-10 15:08 ` Dan Davison
2011-02-10 15:26 ` Rodrigo Lazo
2011-02-10 16:30 ` Tassilo Horn
2011-02-10 16:56 ` Julien Danjou
2011-02-10 18:20 ` Stefan Monnier
2011-02-11 10:21 ` [Orgmode] " Tassilo Horn
2011-02-11 14:47 ` Stefan Monnier
2011-02-11 20:15 ` Tassilo Horn
2011-02-11 23:08 ` Stefan Monnier
2011-02-12 18:37 ` Tassilo Horn
2011-02-20 16:58 ` Julien Danjou
2011-03-18 15:00 ` Completing with anything (was: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org) Julien Danjou
2011-03-18 18:16 ` Completing with anything Stefan Monnier
2011-03-21 11:23 ` Julien Danjou
2011-03-21 12:51 ` Tassilo Horn
2011-03-21 13:36 ` Julien Danjou
2011-03-21 14:17 ` Tassilo Horn
2011-03-21 16:27 ` Stefan Monnier
2011-03-21 16:55 ` Dimitri Fontaine
2011-03-21 17:04 ` Julien Danjou
2011-03-21 22:00 ` Stefan Monnier
2011-03-22 3:01 ` Eric Abrahamsen
2011-03-22 14:13 ` Eric S Fraga
2011-03-22 15:02 ` Eric Abrahamsen
2011-03-23 9:45 ` Julien Danjou
2011-03-23 14:13 ` Eric S Fraga
2011-03-23 15:05 ` Julien Danjou
2011-03-23 16:03 ` Eric S Fraga
2011-03-24 20:15 ` Cian
2011-03-25 10:16 ` Julien Danjou
2011-03-26 22:06 ` Michael Markert
2011-03-26 23:40 ` Michael Markert
2011-04-09 12:13 ` Julien Danjou
2011-04-09 13:54 ` Michael Markert
2011-04-11 9:24 ` Julien Danjou
2011-04-11 9:37 ` Bastien
2011-04-11 13:42 ` Michael Markert
2011-04-30 13:39 ` Michael Markert
2011-05-03 8:09 ` Julien Danjou
2011-03-22 10:00 ` Aankhen
2011-03-22 11:57 ` Tassilo Horn
2011-03-22 12:03 ` Julien Danjou
2011-03-22 12:31 ` Tassilo Horn
2011-03-21 15:19 ` Stefan Monnier
2011-03-21 15:54 ` Julien Danjou
2011-04-09 15:11 ` Julien Danjou
2011-04-10 4:03 ` Stefan Monnier
2011-04-11 9:21 ` Julien Danjou
2011-04-12 3:42 ` Stefan Monnier
2011-04-12 9:48 ` Julien Danjou
2011-05-04 15:07 ` Stefan Monnier
2011-05-04 15:34 ` Julien Danjou
2011-05-24 3:14 ` Stefan Monnier
2011-05-24 7:33 ` Julien Danjou
2011-05-24 9:16 ` Antoine Levitt
2011-05-24 12:47 ` Stefan Monnier
2011-05-24 13:18 ` Antoine Levitt
2011-05-24 14:04 ` Stefan Monnier
2011-05-24 14:05 ` Stefan Monnier
2011-05-24 14:45 ` Antoine Levitt
2011-05-24 18:05 ` Stefan Monnier
2011-05-24 18:30 ` Antoine Levitt
2011-05-26 2:23 ` Stefan Monnier
2011-05-26 7:50 ` Antoine Levitt [this message]
2011-05-28 2:15 ` Stefan Monnier
2011-02-11 11:08 ` Announcing org-contacts, a bbdb-like contact manager for Org Thierry Volpiatto
2011-02-11 15:08 ` Darlan Cavalcante Moreira
2011-02-23 11:09 ` Julien Danjou
2011-02-12 12:18 ` Bastien
2011-02-12 16:35 ` John Hendy
2011-02-12 17:12 ` Bastien
2011-02-23 11:11 ` Julien Danjou
2011-02-12 19:42 ` Matt Lundin
2011-02-23 11:14 ` Julien Danjou
2011-02-14 18:24 ` Wes Hardaker
2011-02-23 11:10 ` Julien Danjou
2011-02-26 17:26 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mxi9lx3i.fsf@gmail.com \
--to=antoine.levitt@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).