From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Antoine Levitt <antoine.levitt@gmail.com>
Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org
Subject: Re: Completing with anything
Date: Wed, 25 May 2011 23:23:38 -0300 [thread overview]
Message-ID: <jwv8vtucigm.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87d3j8vtn5.fsf@gmail.com> (Antoine Levitt's message of "Tue, 24 May 2011 20:30:06 +0200")
>> 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)))))
(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 2:23 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 [this message]
2011-05-26 7:50 ` Antoine Levitt
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=jwv8vtucigm.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=antoine.levitt@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=emacs-orgmode@gnu.org \
/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).