Re: Re: Announcing org-contacts, a bbdb-like contact manager for Org

Re: Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Julien Danjou]

[-- Attachment #1.1: Type: text/plain, Size: 861 bytes --]

On Thu, Feb 10 2011, Tassilo Horn wrote:

> I'm also using Emacs 24, and for me it doesn't work.

Ok. Anyway I've just double checked, and it worst than that.

Typing 'a' complete to 'aA' (instead of 'Anne <mailaddress>') and then
does nothing since aA is not valid.

I'm not sure completion-at-point-functions is correctly usable in this
same dondition as message/bbdb completion was. The latter used to return
a function which is marked as decouraged in
`completion-at-point-functions' docstring. So org-contacts does not use
it. OTOH, returning a (START END COLLECTION) triplet is not very usable
since if you return a collection that start with a different character
set than (buffer-substring start end), it does not work.

(Cc'ing emacs-devel, in case someone has an advice on that.)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #1.2: Type: application/pgp-signature, Size: 835 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Stefan Monnier]

>> I'm also using Emacs 24, and for me it doesn't work.
> Ok. Anyway I've just double checked, and it worst than that.

> Typing 'a' complete to 'aA' (instead of 'Anne <mailaddress>') and then
> does nothing since aA is not valid.

> I'm not sure completion-at-point-functions is correctly usable in this
> same condition as message/bbdb completion was. The latter used to return
> a function which is marked as decouraged in
> `completion-at-point-functions' docstring. So org-contacts does not use
> it. OTOH, returning a (START END COLLECTION) triplet is not very usable
> since if you return a collection that start with a different character
> set than (buffer-substring start end), it does not work.

I don't fully understand what you're saying, probably for lack of
context, but at least it's not true that "if you return a collection
that start with a different character set than (buffer-substring start
end), it doesn't work".  That simply depends on completion-styles (and
completion-ignore-case of course).


        Stefan

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> Typing 'a' complete to 'aA' (instead of 'Anne <mailaddress>') and
>> then does nothing since aA is not valid.
>
>> I'm not sure completion-at-point-functions is correctly usable in
>> this same condition as message/bbdb completion was. The latter used
>> to return a function which is marked as decouraged in
>> `completion-at-point-functions' docstring. So org-contacts does not
>> use it. OTOH, returning a (START END COLLECTION) triplet is not very
>> usable since if you return a collection that start with a different
>> character set than (buffer-substring start end), it does not work.
>
> I don't fully understand what you're saying, probably for lack of
> context, but at least it's not true that "if you return a collection
> that start with a different character set than (buffer-substring start
> end), it doesn't work".  That simply depends on completion-styles (and
> completion-ignore-case of course).

I've just edebugged Juliens function, and if I try to complete

  To: Stefan Monnier <monnier@iro.umontreal.ca>, a<tab>

in this message buffer, his function returns

  (376 377 (#("Andreas XXX <xxx@xxx.invalid>" 0 12 (org-category "contacts" fontified nil))))

which is correct.  Case didn't get accounted, and that's the only
possible completion.  However, what gets inserted after the "a" is only
a TAB character.

The value of `completion-styles' in the current message buffer is

  (basic initials partial-completion),

which should be ok for that kind of completion.

But the global value of completion-ignore-case is nil.  So the problem
seems to be that Julien's completion at point functions respects the
value of his own `org-contacts-completion-ignore-case' variable when
*calculating* completions, but it is not considered anymore when the
completion style *applies* the completions.

When I do

  (set (make-local-variable 'completion-ignore-case) t)

in the current message buffer and try again, then "a<tab>" is correctly
completed to the Andreas Julien's function calculated.  However, I want
case insensitive completion only for contact completion in the headers,
but not in the message body.

So the question is: how can the completion-ignore-case value be
propagated from the completion gathering function in
`completion-at-point-functions' to the function that actually applies
this completion, without having to modify the global or buffer local
value of `completion-ignore-case'?

Bye,
Tassilo

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Stefan Monnier]

> So the question is: how can the completion-ignore-case value be
> propagated from the completion gathering function in
> `completion-at-point-functions' to the function that actually applies
> this completion, without having to modify the global or buffer local
> value of `completion-ignore-case'?

Assuming you have a completion table in variable `table', you should be
able to construct a new completion table that's case-insensitive with
something like the untested code below:

(defun completion-table-case-fold (table string pred action)
  (let ((completion-ignore-case t))
    (complete-with-action action table string pred)))

[...]
   (let ((newtable
          (apply-partially #'completion-table-case-fold table)))
     [...])

where completion-table-case-fold is an auxiliary function which
(c|sh)ould be added to minibuffer.el.

The case-sensitivity of the completion code is indeed problematic.
Here's for example an excerpt from minibuffer.el:

;; - case-sensitivity currently confuses two issues:
;;   - whether or not a particular completion table should be case-sensitive
;;     (i.e. whether strings that differ only by case are semantically
;;     equivalent)
;;   - whether the user wants completion to pay attention to case.
;;   e.g. we may want to make it possible for the user to say "first try
;;   completion case-sensitively, and if that fails, try to ignore case".


        Stefan

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan,

>> So the question is: how can the completion-ignore-case value be
>> propagated from the completion gathering function in
>> `completion-at-point-functions' to the function that actually applies
>> this completion, without having to modify the global or buffer local
>> value of `completion-ignore-case'?
>
> Assuming you have a completion table in variable `table', you should
> be able to construct a new completion table that's case-insensitive
> with something like the untested code below:
>
> (defun completion-table-case-fold (table string pred action)
>   (let ((completion-ignore-case t))
>     (complete-with-action action table string pred)))
>
> [...]
>    (let ((newtable
>           (apply-partially #'completion-table-case-fold table)))
>      [...])
>
> where completion-table-case-fold is an auxiliary function which
> (c|sh)ould be added to minibuffer.el.

Hm, why not simply add a property :ignore-case to the PROPS a function
in `completion-at-point-functions' may return in addition to the
existing :predicate and :annotation-function?  Then
`completion-at-point' could simply bind `completion-ignore-case'
according to that property when calling `completion-in-region'.

Bye,
Tassilo

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Stefan Monnier]

>>> So the question is: how can the completion-ignore-case value be
>>> propagated from the completion gathering function in
>>> `completion-at-point-functions' to the function that actually applies
>>> this completion, without having to modify the global or buffer local
>>> value of `completion-ignore-case'?
>> 
>> Assuming you have a completion table in variable `table', you should
>> be able to construct a new completion table that's case-insensitive
>> with something like the untested code below:
>> 
>> (defun completion-table-case-fold (table string pred action)
>> (let ((completion-ignore-case t))
>> (complete-with-action action table string pred)))
>> 
>> [...]
>> (let ((newtable
>> (apply-partially #'completion-table-case-fold table)))
>> [...])
>> 
>> where completion-table-case-fold is an auxiliary function which
>> (c|sh)ould be added to minibuffer.el.

> Hm, why not simply add a property :ignore-case to the PROPS a function
> in `completion-at-point-functions' may return in addition to the
> existing :predicate and :annotation-function?  Then
> `completion-at-point' could simply bind `completion-ignore-case'
> according to that property when calling `completion-in-region'.

That could work as well, but it's more complexity in
completion-at-point, compared to completion-table-case-fold which can be
added without touching any existing code.

Another reason why doing it inside the completion table is right is
because of the comment I quoted: in your case, it is really a property
of the completion table you return, rather than some user preference
that's locally overridden.

For more complex cases, there is also the issue of what to do when some
parts of the completion are case-sensitive and other parts aren't
(e.g. completion of case-sensitive envvars in case-insensitive file
names), although this is less important for  completion-at-point than
for minibuffer completion since you don't have to return a table that
covers the completion of the whole field (composed of file names and
env-vars, for example), and instead you can just limit the completion to
the particular subfield.


        Stefan

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi Stefan & Julien,

>> Hm, why not simply add a property :ignore-case to the PROPS a
>> function in `completion-at-point-functions' may return in addition to
>> the existing :predicate and :annotation-function?
>
> That could work as well, but it's more complexity in
> completion-at-point, compared to completion-table-case-fold which can
> be added without touching any existing code.

You are right.  I've implemented and tested your approach, and it works
just fine.  Thanks a ton!

@Julien: Here's a patch for org-contacts.el which uses Stefan's
suggestion to fix the completion in the case-insensitive case.

Bye,
Tassilo

--8<---------------cut here---------------start------------->8---
From 4195d4cd3a63df06e52465e4519863ef2a7933e7 Mon Sep 17 00:00:00 2001
From: Tassilo Horn <tassilo@member.fsf.org>
Date: Sat, 12 Feb 2011 19:36:51 +0100
Subject: [PATCH] Fix case-insensitive completion

---
 org-contacts.el |   10 +++++++++-
 1 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/org-contacts.el b/org-contacts.el
index 8513117..4c99ca9 100644
--- a/org-contacts.el
+++ b/org-contacts.el
@@ -114,6 +114,12 @@ If both match values are nil, return all contacts."
         (add-to-list 'result
                      (list (org-get-heading t) marker (org-entry-properties marker 'all)))))))
 
+(when (not (fboundp 'completion-table-case-fold))
+  ;; That function is new in Emacs 24...
+  (defun completion-table-case-fold (table string pred action)
+    (let ((completion-ignore-case t))
+      (complete-with-action action table string pred))))
+
 (defun org-contacts-complete-name (&optional start)
   "Complete text at START with a user name and email."
   (let* ((end (point))
@@ -167,7 +173,9 @@ If both match values are nil, return all contacts."
                                            ;; If the user has an email address, append USER <EMAIL>.
                                            if email collect (concat contact-name " <" email ">"))
                                      ", ")))))
-    (list start end completion-list)))
+    (list start end (if org-contacts-completion-ignore-case
+			(apply-partially #'completion-table-case-fold completion-list)
+		      completion-list))))
 
 (defun org-contacts-message-complete-function ()
   "Function used in `completion-at-point-functions' in `message-mode'."
-- 
1.7.4
--8<---------------cut here---------------end--------------->8---

Re: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

On Sat, Feb 12 2011, Tassilo Horn wrote:

> @Julien: Here's a patch for org-contacts.el which uses Stefan's
> suggestion to fix the completion in the case-insensitive case.

Patch merged, and soon to be pushed.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Completing with anything (was: [Orgmode] Re: Announcing org-contacts, a bbdb-like contact manager for Org)

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On Sat, Feb 12 2011, Stefan Monnier wrote:

> For more complex cases, there is also the issue of what to do when some
> parts of the completion are case-sensitive and other parts aren't
> (e.g. completion of case-sensitive envvars in case-insensitive file
> names), although this is less important for  completion-at-point than
> for minibuffer completion since you don't have to return a table that
> covers the completion of the whole field (composed of file names and
> env-vars, for example), and instead you can just limit the completion to
> the particular subfield.

There's still something wrong to me in the solution provided by Tassilo.
It works fine, but it is returning a function to bypass the usual
completion code completion code. Ignoring case, like doing smarter
completion (e.g. where the typed prefix does not match the returned
choices at all) is something that is very useful.

Therefore I wonder if we should either:
- Edit `completion-at-point-functions' docstring to remove the word
  "discouraged" in that sentence:
  "or a function of no argument to perform completion (discouraged),";
- Make completing code allows to replace the region being completed with
  somethig that does not match at all.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Stefan Monnier]

>> For more complex cases, there is also the issue of what to do when some
>> parts of the completion are case-sensitive and other parts aren't
>> (e.g. completion of case-sensitive envvars in case-insensitive file
>> names), although this is less important for  completion-at-point than
>> for minibuffer completion since you don't have to return a table that
>> covers the completion of the whole field (composed of file names and
>> env-vars, for example), and instead you can just limit the completion to
>> the particular subfield.
> There's still something wrong to me in the solution provided by Tassilo.
> It works fine, but it is returning a function to bypass the usual
> completion code completion code. Ignoring case, like doing smarter
> completion (e.g. where the typed prefix does not match the returned
> choices at all) is something that is very useful.

> Therefore I wonder if we should either:
> - Edit `completion-at-point-functions' docstring to remove the word
>   "discouraged" in that sentence:
>   "or a function of no argument to perform completion (discouraged),";

There's a misunderstanding: AFAIK the patch sent by Tassilo does not
make the completion-at-point-function return a "function that performs
completion" but does properly return completion data (i.e. region start,
region end, and completion table), part of which happens to be
represented by a function.
I.e. this is not one of the discouraged cases.

> - Make completing code allows to replace the region being completed with
>   somethig that does not match at all.

AFAIK that's already the case, tho it depends on lots of factors, such
as what you mean by "completing code".


        Stefan

Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Fri, Mar 18 2011, Stefan Monnier wrote:

> There's a misunderstanding: AFAIK the patch sent by Tassilo does not
> make the completion-at-point-function return a "function that performs
> completion" but does properly return completion data (i.e. region start,
> region end, and completion table), part of which happens to be
> represented by a function.
> I.e. this is not one of the discouraged cases.

You're right, indeed!

But I do not see anywhere the fact that the completion collection can be
a function.

I only found the sentence:

    "It would be consistent and clean for completion functions to allow
lambda expressions (lists that are functions) as well as function
symbols as COLLECTION, but this is impossible."

in (elisp) Programmed Completion.

Not sure it's really related to completion-at-point-functions, but well,
it's not making things clearer for me anyhow.

>> - Make completing code allows to replace the region being completed with
>>   somethig that does not match at all.
>
> AFAIK that's already the case, tho it depends on lots of factors, such
> as what you mean by "completing code".

I meant the code in minibuffer.el

To be clear, the things that disturbs me is that this simple test case
does not work as I would like it to:

#+begin_src emacs-lisp
(defun jd:completion-at-point-test ()
    (list (point-at-bol) (point) '("Steve" "John")))
(add-to-list 'completion-at-point-functions 'jd:completion-at-point-test)
#+end_src

If you run that code into a buffer, and then type in this same buffer:

L

And try to complete that "L" with M-x completion-at-point, it will say
"No match."

But if you do:
#+begin_src emacs-lisp
(defun jd:completion-at-point-test ()
    (list (point-at-bol) (point) '("Lionel" "Steve" "John")))
(add-to-list 'completion-at-point-functions 'jd:completion-at-point-test)
#+end_src

And try to complete a "L", it will complete to Lionel. Just because
completion-at-point is trying to be smarter than my function,
re-guessing which items from the collection are good candidates.
Something my function already does (well, not in this example, but in
real life).

This is why I'm (kindly) finger pointing the "completing code in
minibuffer.el", but I might be wrong (and hope to be! :-)).

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

Hi Julien,

> To be clear, the things that disturbs me is that this simple test case
> does not work as I would like it to:
>
> #+begin_src emacs-lisp
> (defun jd:completion-at-point-test ()
>     (list (point-at-bol) (point) '("Steve" "John")))
> (add-to-list 'completion-at-point-functions 'jd:completion-at-point-test)
> #+end_src
>
> If you run that code into a buffer, and then type in this same buffer:
>
> L
>
> And try to complete that "L" with M-x completion-at-point, it will say
> "No match."
>
> But if you do:
> #+begin_src emacs-lisp
> (defun jd:completion-at-point-test ()
>     (list (point-at-bol) (point) '("Lionel" "Steve" "John")))
> (add-to-list 'completion-at-point-functions 'jd:completion-at-point-test)
> #+end_src
>
> And try to complete a "L", it will complete to Lionel.  Just because
> completion-at-point is trying to be smarter than my function,
> re-guessing which items from the collection are good candidates.
> Something my function already does (well, not in this example, but in
> real life).

Sorry, but I totally missed the point of the example. :-)

Isn't completion of "L" to "Lionel" at the beginning of a line exactly
what your completion function should enable?  With the bzr version of
yesterday, I get these results:

--8<---------------cut here---------------start------------->8---
L<TAB>
Lionel

 L<TAB>
 ;; message: no match

Lionel<TAB>
;; message: sole completion
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Mon, Mar 21 2011, Tassilo Horn wrote:

> Sorry, but I totally missed the point of the example. :-)

Damn it! I tried hard. :-)

> Isn't completion of "L" to "Lionel" at the beginning of a line exactly
> what your completion function should enable?

No. To give a even more concrete application of my example: I'd like
org-contacts to give completion for email addresses or nicknames. If you
have a contact entry like:
- Name: Emmett Brown
- Nickname: doc
- Email address: gigawatt@delorean.com

What I'd like to do is that if the user enters:

     doc<TAB>

is that it can be completed to
   "Emmett Brown <gigawatt@delorean.com>"

But if I return such an item in COLLECTION, it just gets ignored because
"Emmett Brown <gigawatt@delorean.com>" does not match "doc".

This was the point of my example in the my previous email. To just prove
that completion-at-point is being too much picky about which collection
item are valid candidate for completion. I'd like it to just trust what
my function returns. :-)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

Hi Julien,

>> Isn't completion of "L" to "Lionel" at the beginning of a line
>> exactly what your completion function should enable?
>
> No. To give a even more concrete application of my example: I'd like
> org-contacts to give completion for email addresses or nicknames. If
> you have a contact entry like:
>
> - Name: Emmett Brown
> - Nickname: doc
> - Email address: gigawatt@delorean.com
>
> What I'd like to do is that if the user enters:
>
>      doc<TAB>
>
> is that it can be completed to
>    "Emmett Brown <gigawatt@delorean.com>"
>
> But if I return such an item in COLLECTION, it just gets ignored
> because "Emmett Brown <gigawatt@delorean.com>" does not match "doc".

Now that is a completely understandable example! :-)

On the one hand, I'm a bit tempted to say that this is no COMPLETION,
but a kind of ABBREV EXPANSION (just like abbrev.el, skeleton.el,
temo.el, yasnippet.el, ...).  On the other hand, I clearly see the
usefulness of such a dynamic "expansion-at-point".

What might be a solution is to allow COLLECTION to contain not only
strings, but also pairs (MATCH . EXPANSION), like ("doc" . "Emmett Brown
<gigawatt@delorean.com>").

But I'm really no expert with the completion code, so I cannot speak on
how much effort that is, and if it would break things.  For example,
with normal completions you can usually cycle thru all completion
possibilities.  Not sure if that would work after an expansion has taken
place.

Bye,
Tassilo

Re: Completing with anything

[Stefan Monnier]

> What I'd like to do is that if the user enters:

>      doc<TAB>

> is that it can be completed to
>    "Emmett Brown <gigawatt@delorean.com>"

In a BBDB discussion, I suggested to complete the above to "Emmett Brown
\"doc\" <gigawatt@delorean.com>", but it's true that you may prefer to
keep the nickname private.

In that case it's really not a completion (tho the completion code may
help you complete "do" to "doc" as a first step).

As Tassilo mentions, maybe we could have a post-completion step that can
perform some kind of expansion/replacement/cleanup once a valid
completion is selected.  I'm not sure what that would look like in terms
of code and API, but if someone wants to try it out a propose a patch to
start a discussion, maybe we could add such a thing.


        Stefan

Re: Completing with anything

[Dimitri Fontaine]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> As Tassilo mentions, maybe we could have a post-completion step that can
> perform some kind of expansion/replacement/cleanup once a valid
> completion is selected.  I'm not sure what that would look like in terms
> of code and API, but if someone wants to try it out a propose a patch to
> start a discussion, maybe we could add such a thing.

That looks a lot like  (info "(emacs) Mail Aliases").

In particular see mailabbrev.el and the functions
mail-abbrev-insert-alias and mail-abbrev-complete-alias.

Also (add-hook 'message-mode-hook 'mail-abbrevs-setup).

Regards,
-- 
dim

Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Mon, Mar 21 2011, Stefan Monnier wrote:

> As Tassilo mentions, maybe we could have a post-completion step that can
> perform some kind of expansion/replacement/cleanup once a valid
> completion is selected.  I'm not sure what that would look like in terms
> of code and API, but if someone wants to try it out a propose a patch to
> start a discussion, maybe we could add such a thing.

Or maybe an upper layer mixing abbrev and completion? Trying one at
first, the other one after. This could be useful for message-mode for
example, since you probably wants to use both.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Stefan Monnier]

>> As Tassilo mentions, maybe we could have a post-completion step that can
>> perform some kind of expansion/replacement/cleanup once a valid
>> completion is selected.  I'm not sure what that would look like in terms
>> of code and API, but if someone wants to try it out a propose a patch to
>> start a discussion, maybe we could add such a thing.

> Or maybe an upper layer mixing abbrev and completion? Trying one at
> first, the other one after. This could be useful for message-mode for
> example, since you probably wants to use both.

That might work even better, yes.


        Stefan

Re: Re: Completing with anything

[Aankhen]

On Mon, Mar 21, 2011 at 22:34, Julien Danjou <julien@danjou.info> wrote:
> On Mon, Mar 21 2011, Stefan Monnier wrote:
>
>> As Tassilo mentions, maybe we could have a post-completion step that can
>> perform some kind of expansion/replacement/cleanup once a valid
>> completion is selected.  I'm not sure what that would look like in terms
>> of code and API, but if someone wants to try it out a propose a patch to
>> start a discussion, maybe we could add such a thing.
>
> Or maybe an upper layer mixing abbrev and completion? Trying one at
> first, the other one after. This could be useful for message-mode for
> example, since you probably wants to use both.

Isn’t this what hippie-expand does?

Re: [O] Re: Completing with anything

[Tassilo Horn]

Aankhen <aankhen@gmail.com> writes:

Hi Aankhen,

>> Or maybe an upper layer mixing abbrev and completion? Trying one at
>> first, the other one after. This could be useful for message-mode for
>> example, since you probably wants to use both.
>
> Isn’t this what hippie-expand does?

Oh, yes, it seems so.  For example, there is the possible expansion (not
completion) function:

,----[ C-h f try-expand-all-abbrevs RET ]
| try-expand-all-abbrevs is a compiled Lisp function in `hippie-exp.el'.
| 
| (try-expand-all-abbrevs OLD)
| 
| Try to expand word before point according to all abbrev tables.
| The argument OLD has to be nil the first call of this function, and t
| for subsequent calls (for further possible expansions of the same
| string).  It returns t if a new expansion is found, nil otherwise.
`----

The OLD arg in hippie-expansion functions also handles the case of
cycling thru possible expansions, where an expansion erases the text
that was expanded.

So Julien, maybe you want a `try-expand-org-contact' function, and add
that to `hippie-expand-try-functions-list', and bind `hippie-expand' to
some key.

Bye,
Tassilo

Re: [O] Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

On Tue, Mar 22 2011, Tassilo Horn wrote:

> So Julien, maybe you want a `try-expand-org-contact' function, and add
> that to `hippie-expand-try-functions-list', and bind `hippie-expand' to
> some key.

I want to integrate into message-mode. So I don't want to bind any key,
nor rebind <TAB>. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [O] Re: Completing with anything

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

>> So Julien, maybe you want a `try-expand-org-contact' function, and
>> add that to `hippie-expand-try-functions-list', and bind
>> `hippie-expand' to some key.
>
> I want to integrate into message-mode. So I don't want to bind any
> key, nor rebind <TAB>. :)

Ok, I see.  But at least the functionality is already there.  The task
of embedding that into a good, non-obtrusive, always-working user
interface is left as a task to the developer. :-P

IMHO, hippie-expand is a pretty nice feature with a good interface, both
from a user as well as developer view.  I would not object to rebinding
M-/ from `dabbrev-expand' to `hippie-expand', and make the default value
of `hippie-expand-try-functions-list' '(dabbrev-expand).  But that's
just me...

Bye,
Tassilo

Re: Completing with anything

[Stefan Monnier]

>> There's a misunderstanding: AFAIK the patch sent by Tassilo does not
>> make the completion-at-point-function return a "function that performs
>> completion" but does properly return completion data (i.e. region start,
>> region end, and completion table), part of which happens to be
>> represented by a function.
>> I.e. this is not one of the discouraged cases.

> You're right, indeed!

> But I do not see anywhere the fact that the completion collection can be
> a function.

> I only found the sentence:

>     "It would be consistent and clean for completion functions to allow
> lambda expressions (lists that are functions) as well as function
> symbols as COLLECTION, but this is impossible."

> in (elisp) Programmed Completion.

That sentence is obsolete.  Sorry 'bout that.  A collection can be
any function, including a lambda expression.

> And try to complete that "L" with M-x completion-at-point, it will say
> "No match."

> But if you do:
> #+begin_src emacs-lisp
> (defun jd:completion-at-point-test ()
>     (list (point-at-bol) (point) '("Lionel" "Steve" "John")))
> (add-to-list 'completion-at-point-functions 'jd:completion-at-point-test)
> #+end_src

completion-at-point-function is meant to provide just the possible
completion candidates for the kind of object being completed.
Which ones of these will be actually considered will then depend on the
actual text in the buffer and the completion-styles in use.

A missing feature in minibuffer.el is the ability to specify different
completion styles for different circumstances.

> And try to complete a "L", it will complete to Lionel.

That depends on completion-styles.  Tho I must admit that I can't think
of any completion-style where it would make sense to complete "L" to
"Steve" when "Lionel" is a valid candidate (I have an experimental
"forgiving" completion-style which could be convinced to treat the "L"
as a typo and complete to "Steve" or "John", but in the presence of
"Lionel" it would prefer not to).

> Just because completion-at-point is trying to be smarter than my
> function, re-guessing which items from the collection are
> good candidates.

Your function's job is not to guess which items are good candidates, but
rather to return all the candidates in the category being completed.

> Something my function already does (well, not in this example, but in
> real life).

A completion-at-point-function is allowed to look at the buffer text and
weed out elements that don't match, but it does not have to (and I'd
recommend that it does not except when there's a significant performance
benefit, since it may weed out elements that the completion-style in use
may actually consider as valid candidates).  It is the job of
completion-in-region-functions.


        Stefan

Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]

On Mon, Mar 21 2011, Stefan Monnier wrote:

> That sentence is obsolete.  Sorry 'bout that.  A collection can be
> any function, including a lambda expression.

Should I open a bug about that to keep track of it?
(asking in case you're already working on a fix or not)

> completion-at-point-function is meant to provide just the possible
> completion candidates for the kind of object being completed.
> Which ones of these will be actually considered will then depend on the
> actual text in the buffer and the completion-styles in use.

I see, that makes sense. I think that completion is not what I want to
use as Tassilo suggested. I've been that way just because this is what
is used in `message.el'. Maybe it requires a change too to turn towards
an `abbrev' use. :)

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [O] Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1332 bytes --]

On Mon, Mar 21 2011, Julien Danjou wrote:

> I see, that makes sense. I think that completion is not what I want to
> use as Tassilo suggested. I've been that way just because this is what
> is used in `message.el'. Maybe it requires a change too to turn towards
> an `abbrev' use. :)

Actually, it does not require any change, but there is an issue I'm not
sure how to resolve.

On <tab>, message-mode calls `completion-at-point-function', which calls
first my `org-contacts-message-complete-function' and then
`message-completion-function'.

If you type someone's nickname, `org-contacts-message-complete-function'
will not return any match. So I hacked it to return only the nickname,
like 'j<tab>' would return 'jd'.

Then, using the abbrev table, I manage to make jd expand to my
name+email but I have to press space. If I press <tab>, the completion
kicks in, and re-complete 'jd' to 'jd', and `expand-abbrev' is never
called. I need to press 'space', which is not very handy.

It seems that completion and abbrev are (too much) orthogonal: you
cannot easily complete an item from the abbrev table using completion.

So now, I wonder: wouldn't it be a good idea to add a call to
`expand-abbrev' just after `completion-at-point' is being called?

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [O] Re: Completing with anything

[Stefan Monnier]

> So now, I wonder: wouldn't it be a good idea to add a call to
> `expand-abbrev' just after `completion-at-point' is being called?

After completing an abbrev name, yes, but otherwise I don't think so.
I.e. why don't you add such a call to
org-contacts-message-complete-function?


        Stefan

Re: [O] Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Sun, Apr 10 2011, Stefan Monnier wrote:

>> So now, I wonder: wouldn't it be a good idea to add a call to
>> `expand-abbrev' just after `completion-at-point' is being called?
>
> After completing an abbrev name, yes, but otherwise I don't think so.
> I.e. why don't you add such a call to
> org-contacts-message-complete-function?

Because this one return (list start end completion-choies), and does not
do anything else. I can't do it myself using the current completion
mechanism, IIUC.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [O] Re: Completing with anything

[Stefan Monnier]

> Because this one return (list start end completion-choies), and does not
> do anything else. I can't do it myself using the current completion
> mechanism, IIUC.

Hmm... good point, doing it in completion-choices is not reliable, tho
using as completion table something like:

(lambda (string pred action)
  (let ((res (complete-with-action action completion-choices string pred)))
    (if (and (eq action nil)
             (assq (if (eq res t) string res) <expansion-alist>))
        (cdr (assq (if (eq res t) string res) <expansion-alist>))
      res)))

should work OK for prefix completion, but that means using the expansion
"by hand" rather than via expand-abbrev, which may not be an option.
      

        Stefan

Re: [O] Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Tue, Apr 12 2011, Stefan Monnier wrote:

> Hmm... good point, doing it in completion-choices is not reliable, tho
> using as completion table something like:
>
> (lambda (string pred action)
>   (let ((res (complete-with-action action completion-choices string pred)))
>     (if (and (eq action nil)
>              (assq (if (eq res t) string res) <expansion-alist>))
>         (cdr (assq (if (eq res t) string res) <expansion-alist>))
>       res)))
>
> should work OK for prefix completion, but that means using the expansion
> "by hand" rather than via expand-abbrev, which may not be an option.

Yeah. That does not looks like a simple/good option.
As it stands, I guess the bbdb solution to return a function doing the
replacement rather than trying to return a list and conform with the
(current) way of doing completion is really simpler, unfortunately. :(

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: [O] Re: Completing with anything

[Stefan Monnier]

>> Hmm... good point, doing it in completion-choices is not reliable, tho
>> using as completion table something like:
>> 
>> (lambda (string pred action)
>> (let ((res (complete-with-action action completion-choices string pred)))
>> (if (and (eq action nil)
>> (assq (if (eq res t) string res) <expansion-alist>))
>> (cdr (assq (if (eq res t) string res) <expansion-alist>))
>> res)))
>> 
>> should work OK for prefix completion, but that means using the expansion
>> "by hand" rather than via expand-abbrev, which may not be an option.

> Yeah. That does not looks like a simple/good option.
> As it stands, I guess the bbdb solution to return a function doing the
> replacement rather than trying to return a list and conform with the
> (current) way of doing completion is really simpler, unfortunately. :(

While taking a look at adding the necessary functionality to
minibuffer.el, I bumped into a problem:

If you complete "ni" to "nic" which is a valid alias and you also have
a "nicolas" alias, running expand-abbrev after the completion may not be
right since it will prevent you from getting to "nicolas".

Now, this is a minor problem.  But the more general case is when the
user has set completion-cycle-threshold so that completion happened via
cycling: the string after completion is a valid abbrev (presumably) but
calling expand-abbrev on it will interfere with the cycling in a big way
(the details of what will happen depend on the way cycling is
implemented and what kind of abbrevs we're talking about).

So at least cycling-completion seems fundamentally incompatible with
this idea of abbrev-expansion-after-completion, at least if you want to
allow arbitrarily complex abbrevs like skeletons.

Could you give me an idea of what kind of abbrevs the code should try
to accommodate?


        Stefan

Re: [O] Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 936 bytes --]

On Wed, May 04 2011, Stefan Monnier wrote:

> So at least cycling-completion seems fundamentally incompatible with
> this idea of abbrev-expansion-after-completion, at least if you want to
> allow arbitrarily complex abbrevs like skeletons.

Indeed, this is a real problem.

> Could you give me an idea of what kind of abbrevs the code should try
> to accommodate?

IIUC, your nic/nicolas example perfectly fits in. This is what I tried
to achieve in message-mode (using org-contacts as the database).

Maybe what's needed is a different completion type, which would be a
built on top of both completion and abbrev. It would try to complete
based on an abbrev list until there's no possible doubt about the alias
the users wants, and finally would do the expand-abbrev operation.

At least, that sounds like a completion mode we would need in
message-mode case.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Stefan Monnier]

> > So at least cycling-completion seems fundamentally incompatible with
> > this idea of abbrev-expansion-after-completion, at least if you want to
> > allow arbitrarily complex abbrevs like skeletons.
> Indeed, this is a real problem.

I've now added a :exit-function property that
completion-at-point-functions can return which is a function that gets
called when completion is finished.  It operates outside of the
completion-table, so has access to the buffer text and can do things
like abbrev-expand.

It gets a status argument which tells it whether the completion is
`exact' (basically, it's valid according to the completion-table, but
there may be further completions available), `sole' (it's the only
completion), and `finished' (not only it's the sole completion, but the
user is not expected to want to change it).  `sole' is used by cycling,
so the :exit-function can call abbrev-expand when the status is
`finished' and it won't interfere with cycling (which simply won't
benefit from abbrev-expansion).


        Stefan

Re: Completing with anything

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]

On Tue, May 24 2011, Stefan Monnier wrote:

> I've now added a :exit-function property that
> completion-at-point-functions can return which is a function that gets
> called when completion is finished.  It operates outside of the
> completion-table, so has access to the buffer text and can do things
> like abbrev-expand.
>
> It gets a status argument which tells it whether the completion is
> `exact' (basically, it's valid according to the completion-table, but
> there may be further completions available), `sole' (it's the only
> completion), and `finished' (not only it's the sole completion, but the
> user is not expected to want to change it).  `sole' is used by cycling,
> so the :exit-function can call abbrev-expand when the status is
> `finished' and it won't interfere with cycling (which simply won't
> benefit from abbrev-expansion).

That sounds really tremendous Stefan! Just what was needed.

Thanks a lot.

-- 
Julien Danjou
❱ http://julien.danjou.info

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Completing with anything

[Antoine Levitt]

24/05/11 05:14, Stefan Monnier
>> > So at least cycling-completion seems fundamentally incompatible with
>> > this idea of abbrev-expansion-after-completion, at least if you want to
>> > allow arbitrarily complex abbrevs like skeletons.
>> Indeed, this is a real problem.
>
> I've now added a :exit-function property that
> completion-at-point-functions can return which is a function that gets
> called when completion is finished.  It operates outside of the
> completion-table, so has access to the buffer text and can do things
> like abbrev-expand.
>
> It gets a status argument which tells it whether the completion is
> `exact' (basically, it's valid according to the completion-table, but
> there may be further completions available), `sole' (it's the only
> completion), and `finished' (not only it's the sole completion, but the
> user is not expected to want to change it).  `sole' is used by cycling,
> so the :exit-function can call abbrev-expand when the status is
> `finished' and it won't interfere with cycling (which simply won't
> benefit from abbrev-expansion).

So, could you add 'failed, which means that no function was able to
complete? That way I could do something like

(setq completion-extra-properties '(:exit-function my-exit-function))

(defun my-exit-function (string finished)
  (when (eq finished 'failed)
    (dabbrev-expand)))

and always get a dabbrev-expand as fallback to completion-at-point?

Re: Completing with anything

[Stefan Monnier]

> So, could you add 'failed, which means that no function was able to
> complete? That way I could do something like

> (setq completion-extra-properties '(:exit-function my-exit-function))

> (defun my-exit-function (string finished)
>   (when (eq finished 'failed)
>     (dabbrev-expand)))

> and always get a dabbrev-expand as fallback to completion-at-point?

Hmm... interesting way to attack that problem.  I don't think that will
work quite like this: if the completion provides its own :exit-function
(e.g. to add a terminator string), then yours won't be run.


        Stefan

Re: Completing with anything

[Antoine Levitt]

24/05/11 14:47, Stefan Monnier
>> So, could you add 'failed, which means that no function was able to
>> complete? That way I could do something like
>
>> (setq completion-extra-properties '(:exit-function my-exit-function))
>
>> (defun my-exit-function (string finished)
>>   (when (eq finished 'failed)
>>     (dabbrev-expand)))
>
>> and always get a dabbrev-expand as fallback to completion-at-point?
>
> Hmm... interesting way to attack that problem.  I don't think that will
> work quite like this: if the completion provides its own :exit-function
> (e.g. to add a terminator string), then yours won't be run.

Mmh, true. 

Oh well, I guess that I'm the only one who wants this kind of behaviour,
so I just ended up with an advice which seems to do the trick. Sorry for
hijacking this thread. In case anyone is interested:

(defadvice completion-at-point
  (after completion-at-point-complete-if-failed activate)
  "Fallback on dabbrev if completion didn't do anything useful."
    (unless ad-return-value
      (dabbrev-expand nil)))

Re: Completing with anything

[Stefan Monnier]

> Oh well, I guess that I'm the only one who wants this kind of behaviour,

No, I'm interested as well, but haven't found a good solution yet.


        Stefan

Re: Completing with anything

[Stefan Monnier]

> (defadvice completion-at-point
>   (after completion-at-point-complete-if-failed activate)
>   "Fallback on dabbrev if completion didn't do anything useful."
>     (unless ad-return-value
>       (dabbrev-expand nil)))

BTW, you can avoid the advice by using your own

  (defun al-completion-at-point ()
    (interactive)
    (or (completion-at-point)
        (dabbrev-expand nil)))


-- Stefan

Re: Completing with anything

[Antoine Levitt]

24/05/11 16:05, Stefan Monnier
>> (defadvice completion-at-point
>>   (after completion-at-point-complete-if-failed activate)
>>   "Fallback on dabbrev if completion didn't do anything useful."
>>     (unless ad-return-value
>>       (dabbrev-expand nil)))
>
> BTW, you can avoid the advice by using your own
>
>   (defun al-completion-at-point ()
>     (interactive)
>     (or (completion-at-point)
>         (dabbrev-expand nil)))

I'd do that, but completion-at-point is used in places I don't fully
understand when I set (setq tab-always-indent 'complete).

Also there's some weirdness with dabbrev that makes it bug out when it's
called indirectly. For instance, seemingly simple code like (artificial
example here, but similar things happen when for instance you indent and
then complete with the same key)

(setq counter 0)
(defun my-my-dabbrev-expand ()
  (interactive)
  (setq counter (mod (+ 1 counter) 2))
  (when (equal counter 0)
    (dabbrev-expand nil)))
(local-set-key (kbd "C-c C-c") 'my-my-dabbrev-expand)

behaves in a very unexpected way : it actually jumps (!) to the location
where the completion was found. I wasn't able to understand this, but
it's definitely a bug in dabbrev. It looks like it's related to the way
dabbrev checks it's continuing a completion:

(eq last-command this-command)

but I wouldn't know how to fix this.

Re: Completing with anything

[Stefan Monnier]

> Oh well, I guess that I'm the only one who wants this kind of behaviour,
> so I just ended up with an advice which seems to do the trick.  Sorry for
> hijacking this thread.  In case anyone is interested:

To get back to this discussion.  Before worrying about how to implement
it, I'm wondering what should the behavior be.

The way I look at it, the issue is whether the completion data returned
by completion-at-point-functions is "exclusive": currently it is
exclusive, which means that if that data leads to a completion failure,
then the whole completion-at-point fails, even though there might be
further functions on completion-at-point-functions which could return
data that does lead to a successful completion.

This "exclusive"ness is a bit similar to the must-match argument of
completion-read: it presumes that the function knows that anything
outside of the completion table is simply undesirable at point.

This "exclusive" behavior is what causes you pain.  Now one possible
strategy is to make the behavior non-exclusive and keep trying the next
functions until one of them returns data that leads to a successful
completion, which is largely what used to happen with
comint-dynamic-complete-function.

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.

Yet another is to do what your defadvice does: let all completion
functions from completion-at-point-functions be exclusive with respect
to each other, but make them non-exclusive with respect to some
"fallback completion".


        Stefan

Re: Completing with anything

[Antoine Levitt]

24/05/11 20:05, Stefan Monnier
>> Oh well, I guess that I'm the only one who wants this kind of behaviour,
>> so I just ended up with an advice which seems to do the trick.  Sorry for
>> hijacking this thread.  In case anyone is interested:
>
> To get back to this discussion.  Before worrying about how to implement
> it, I'm wondering what should the behavior be.
>
> The way I look at it, the issue is whether the completion data returned
> by completion-at-point-functions is "exclusive": currently it is
> exclusive, which means that if that data leads to a completion failure,
> then the whole completion-at-point fails, even though there might be
> further functions on completion-at-point-functions which could return
> data that does lead to a successful completion.
>
> This "exclusive"ness is a bit similar to the must-match argument of
> completion-read: it presumes that the function knows that anything
> outside of the completion table is simply undesirable at point.
>
> This "exclusive" behavior is what causes you pain.  Now one possible
> strategy is to make the behavior non-exclusive and keep trying the next
> functions until one of them returns data that leads to a successful
> completion, which is largely what used to happen with
> comint-dynamic-complete-function.
>
> 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.

Re: Completing with anything

[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)))))
 
 (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

Re: Completing with anything

[Antoine Levitt]

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

Re: Completing with anything

[Stefan Monnier]

> 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)))

Thanks, installed,


        Stefan

Re: Announcing org-contacts, a bbdb-like contact manager for Org

[Thierry Volpiatto]

Julien Danjou <julien@danjou.info> writes:

> On Thu, Feb 10 2011, Tassilo Horn wrote:
>
>> I'm also using Emacs 24, and for me it doesn't work.
>
> Ok. Anyway I've just double checked, and it worst than that.
>
> Typing 'a' complete to 'aA' (instead of 'Anne <mailaddress>') and then
> does nothing since aA is not valid.
>
> I'm not sure completion-at-point-functions is correctly usable in this
> same dondition as message/bbdb completion was. The latter used to return
> a function which is marked as decouraged in
> `completion-at-point-functions' docstring. So org-contacts does not use
> it. OTOH, returning a (START END COLLECTION) triplet is not very usable
> since if you return a collection that start with a different character
> set than (buffer-substring start end), it does not work.
>
> (Cc'ing emacs-devel, in case someone has an advice on that.)
I am not using anymore bbdb, using only my own addressbook based on
bookmarks.It have completion in message with TAB.
You can get it here:
http://mercurial.intuxication.org/hg/emacs-bookmark-extension/

Maybe it can help for your org-contacts.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 


_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode