From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Antoine Levitt Newsgroups: gmane.emacs.devel,gmane.emacs.orgmode Subject: Re: Completing with anything Date: Thu, 26 May 2011 09:50:09 +0200 Message-ID: <87mxi9lx3i.fsf@gmail.com> References: <87r5bhysp6.fsf@keller.adm.naquadah.org> <87y63jpii5.fsf@keller.adm.naquadah.org> <871v0ecwe4.fsf@keller.adm.naquadah.org> <87aaecihl2.fsf@gmail.com> <87lixwkzi4.fsf@gmail.com> <87d3j8vtn5.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1306396227 23366 80.91.229.12 (26 May 2011 07:50:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 26 May 2011 07:50:27 +0000 (UTC) Cc: emacs-orgmode@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 26 09:50:23 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QPVKo-0001Bx-Io for ged-emacs-devel@m.gmane.org; Thu, 26 May 2011 09:50:22 +0200 Original-Received: from localhost ([::1]:43883 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPVKo-0005ov-3R for ged-emacs-devel@m.gmane.org; Thu, 26 May 2011 03:50:22 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPVKl-0005kq-07 for emacs-devel@gnu.org; Thu, 26 May 2011 03:50:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QPVKk-0005kv-5c for emacs-devel@gnu.org; Thu, 26 May 2011 03:50:18 -0400 Original-Received: from mail-ww0-f49.google.com ([74.125.82.49]:35155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QPVKh-0005kc-Ur; Thu, 26 May 2011 03:50:16 -0400 Original-Received: by wwb39 with SMTP id 39so377891wwb.30 for ; Thu, 26 May 2011 00:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=bj/JCqZgmOKqY1ODpDAFumDH4R/QhITnsi58lCncjMY=; b=dfiAQz/Bkt4lO1VliJLwpUJNkfUcC7z/yRNA+PadWhg1X2Jl7aIe7H+OIUSxiRMzKa 5ILkqA+FYEOA29brOhOH5DctQ0jS2inxGC3pj0P5fegxTZ0tHhBWk6yrjZHRQAK1GqiN QCGkJ/0gZsj1q6lUzyL8Oqecmno/50U2ZbrzQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=oLZzFQDCCwf/NQQfcZ2LsDmPGDS5UBhy8TLnId47Z+dXaFM0wd9VD0M2vp11TXMGII gaAsq3q2+33Sc2QJatkUvPUlgEMPMAfIQZnkyA61wMHQkenSgL7Z4lJ2HqRQN6JBsXAK MtBwHYLbP8wPkdTzRD6nv6DSKum847y7uqblU= Original-Received: by 10.216.221.103 with SMTP id q81mr459226wep.83.1306396214477; Thu, 26 May 2011 00:50:14 -0700 (PDT) Original-Received: from lambda (ney92-7-78-233-218-202.fbx.proxad.net [78.233.218.202]) by mx.google.com with ESMTPS id r20sm204513wec.7.2011.05.26.00.50.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 26 May 2011 00:50:13 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Wed, 25 May 2011 23:23:38 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 74.125.82.49 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139728 gmane.emacs.orgmode:42266 Archived-At: 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