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

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

[Julien Danjou]

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

Hi,

Following my short presentation at the Paris OrgCamp, I've now written a
page and officially released org-contacts. It is a contact manager based
on Org, that can possibly replace BBDB for certain usage.

   http://julien.danjou.info/org-contacts.html

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[John Hendy]

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

On Wed, Feb 9, 2011 at 3:02 AM, Julien Danjou <julien@danjou.info> wrote:

> Hi,
>
> Following my short presentation at the Paris OrgCamp, I've now written a
> page and officially released org-contacts. It is a contact manager based
> on Org, that can possibly replace BBDB for certain usage.
>
>   http://julien.danjou.info/org-contacts.html
>
>
This is awesome. I was using bbdb but got tired of it. I switched to the
contacts method mentioned on the mailing list a time ago about just doing
something like this (which is also the approx format you've used):

,-----
| * Category
| ** Name
|   :PROPERTIES:
|   :Phone: xxxxxxx
|   :Email: blah@blah.com
|   ...etc.
|   :END:
`-----

From skimming the website and org-contacts.el, is the main advantage that it
can search multiple files as well as integrate with gnus? I don't use gnus
(can't access personal email via pop/imap from behind work firewall) and so
that feature isn't wholly attractive. It looks like I could use the remember
template as well for my current method. Is there something else that you
would put forth as the primary benefits of this system? I'm quite interested
in it.

A few other questions:
-- can you add additional fields? It looks like I could keep repeating the
pattern in your .el like so:
,-----
|(defcustom org-contacts-SOME-NAME-property "SOME-NAME"
|  "Name of the property for contact email address."
|  :type 'string
|  :group 'org-contacts)
`-----

-- I will often need to look up a contact at work and reproduce it in an
email. It would be nice to standardize the order of the properties and then
have a way to "export" the whole contact into the kill-ring for pasting into
email format. Do you think something like that could be integrated? For
example 'M-x export-selected-contact' would take the highlighted area and
create:

,-----
| Name
| Title
| Company
| Email
| Phone
`-----

And perhaps one could define the fields for export (I wouldn't, for example,
hardly ever need to export the address and my notes about the contact).

Just my thoughts! I was very excited to see this in my inbox and look
around. I'm assuming with the right fields, my current system would already
be in the right syntax to integrate with this, so I'm interested to hear
your answers to the above.


Thanks for your work,
John


> --
> Julien Danjou
> ❱ http://julien.danjou.info
>
> _______________________________________________
> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 3990 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Sébastien Vauban]

Hi Julien,

John Hendy wrote:
> From skimming the website and org-contacts.el, is the main advantage that it
> can search multiple files as well as integrate with gnus?

This looks very neat. Thanks for sharing.

From skimming on the available docs, would I be right to state that the only
missing *features set* (vs bbdb) is the *scanning done on the incoming mails*:
detecting a new email address, asking to add it, eventually as the primary
one, detecting the Organization field and storing it, parsing the X-Face and
storing it, etc.?

Would such features be added in the future?  Or do we have to choose for the
simplicity of the new format, eventually losing some minor features?

Best regards,
  Seb

-- 
Sébastien Vauban


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

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

[Julien Danjou]

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

On Wed, Feb 09 2011, Sébastien Vauban wrote:

> From skimming on the available docs, would I be right to state that the only
> missing *features set* (vs bbdb) is the *scanning done on the incoming mails*:
> detecting a new email address, asking to add it, eventually as the primary
> one, detecting the Organization field and storing it, parsing the X-Face and
> storing it, etc.?
>
> Would such features be added in the future?  Or do we have to choose for the
> simplicity of the new format, eventually losing some minor features?

Snarffing info from known contacts and adding other mail addresses
email, faces, etc is planned.

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

[Russell Adams]

On Wed, Feb 09, 2011 at 09:43:33PM +0100, Julien Danjou wrote:
> On Wed, Feb 09 2011, S??bastien Vauban wrote:
>
> > From skimming on the available docs, would I be right to state that the only
> > missing *features set* (vs bbdb) is the *scanning done on the incoming mails*:
> > detecting a new email address, asking to add it, eventually as the primary
> > one, detecting the Organization field and storing it, parsing the X-Face and
> > storing it, etc.?
> >
> > Would such features be added in the future?  Or do we have to choose for the
> > simplicity of the new format, eventually losing some minor features?
>
> Snarffing info from known contacts and adding other mail addresses
> email, faces, etc is planned.
>
> --
> Julien Danjou
> ??? http://julien.danjou.info

I currently have lbdb caching incoming addresses to it's own format,
not Org. Then I have my contacts in Org, and I have a perl plugin for
lbdb to find my Org contacts when I trigger a quick lookup from mutt.

If there's interest, I'll post the relevant portions.

Thanks.



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

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

[Marcelo de Moraes Serpa]

This is amazing; if you export as HTML, it even preserves the
color-scheme from the theme!

I think I need to do this:

C-x C-r "Read the fine org manual" <RET>

Thank you!

Marcelo.

On Wed, Feb 9, 2011 at 3:10 PM, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> On Wed, Feb 09, 2011 at 09:43:33PM +0100, Julien Danjou wrote:
>> On Wed, Feb 09 2011, S??bastien Vauban wrote:
>>
>> > From skimming on the available docs, would I be right to state that the only
>> > missing *features set* (vs bbdb) is the *scanning done on the incoming mails*:
>> > detecting a new email address, asking to add it, eventually as the primary
>> > one, detecting the Organization field and storing it, parsing the X-Face and
>> > storing it, etc.?
>> >
>> > Would such features be added in the future?  Or do we have to choose for the
>> > simplicity of the new format, eventually losing some minor features?
>>
>> Snarffing info from known contacts and adding other mail addresses
>> email, faces, etc is planned.
>>
>> --
>> Julien Danjou
>> ??? http://julien.danjou.info
>
> I currently have lbdb caching incoming addresses to it's own format,
> not Org. Then I have my contacts in Org, and I have a perl plugin for
> lbdb to find my Org contacts when I trigger a quick lookup from mutt.
>
> If there's interest, I'll post the relevant portions.
>
> Thanks.
>
>
>
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
> _______________________________________________
> 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Julien Danjou]

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

On Wed, Feb 09 2011, John Hendy wrote:

> From skimming the website and org-contacts.el, is the main advantage that it
> can search multiple files as well as integrate with gnus? I don't use gnus
> (can't access personal email via pop/imap from behind work firewall) and so
> that feature isn't wholly attractive. It looks like I could use the remember
> template as well for my current method. Is there something else that you
> would put forth as the primary benefits of this system? I'm quite interested
> in it.

Not yet. I'm working with Bastien to integrate a set of patches so the
`org-contacts' function will print contacts in a better way.

They will probably be more at the time come, we'll see.

> A few other questions:
> -- can you add additional fields? It looks like I could keep repeating the
> pattern in your .el like so:
> ,-----
> |(defcustom org-contacts-SOME-NAME-property "SOME-NAME"
> |  "Name of the property for contact email address."
> |  :type 'string
> |  :group 'org-contacts)
> `-----

You add what you want. Org-contacts does not care at all. It just use
some fields like EMAIL for Gnus completion, so it has to know it. Other
fields are up to your choices.

> -- I will often need to look up a contact at work and reproduce it in an
> email. It would be nice to standardize the order of the properties and then
> have a way to "export" the whole contact into the kill-ring for pasting into
> email format. Do you think something like that could be integrated? For
> example 'M-x export-selected-contact' would take the highlighted area and
> create:
>
> ,-----
> | Name
> | Title
> | Company
> | Email
> | Phone
> `-----
>
> And perhaps one could define the fields for export (I wouldn't, for example,
> hardly ever need to export the address and my notes about the
> contact).

That would be easy. Maybe a vcard export even?

> Just my thoughts! I was very excited to see this in my inbox and look
> around. I'm assuming with the right fields, my current system would already
> be in the right syntax to integrate with this, so I'm interested to hear
> your answers to the above.

I think so, yes. Org-contacts let you be free about how you manage your
contacts, so it should adapt to your current organization.

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[John Hendy]

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

On Wed, Feb 9, 2011 at 2:42 PM, Julien Danjou <julien@danjou.info> wrote:

> On Wed, Feb 09 2011, John Hendy wrote:
>
> You add what you want. Org-contacts does not care at all. It just use
> some fields like EMAIL for Gnus completion, so it has to know it. Other
> fields are up to your choices.
>
>
> That would be easy. Maybe a vcard export even?
>
> > Just my thoughts! I was very excited to see this in my inbox and look
> > around. I'm assuming with the right fields, my current system would
> already
> > be in the right syntax to integrate with this, so I'm interested to hear
> > your answers to the above.
>
> I think so, yes. Org-contacts let you be free about how you manage your
> contacts, so it should adapt to your current organization.
>
>
Great -- thanks for the response. Though, did you see my other email? I've
pointed it toward my contacts.org file and it wants to keep doing something
odd with agenda and asking to remove lines from the file itself. What do you
think about the errors I'm getting? To duplicate:

,---------
| I just gave it a whirl, but am having a strange result. Here were my
steps:
| - org-contacts.el moved to load path
| - added =(require 'org-contacts)= to .emacs
| - created ~/org/contact-example.org and used your website's example of
Dave Null
| - I used org-customize to set the definition of the =org-contacts-files=
variable like so:
| ,-----
| | (custom-set-variables
| | '(org-contacts-files "/home/jwhendy/org/contact-example.org"))
| `-----
| - restarted emacs and did 'M-x org-contacts' followed by typing "dave"
| - the minibuffer shows the following:
| ,-----
| | non-existent agenda file ~/org/#+startup: showeverything. [R]emove from
list or [A]bort?
| `-----
|
| Removing the line just moves to the next line and asks if I want to remove
'~/org/* Friends', then '~/org/** Dave Null' and so on.
|
| What am I doing wrong?
`----------

Is anyone else having that issue?


Thanks,
John


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

[-- Attachment #1.2: Type: text/html, Size: 3481 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Julien Danjou]

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

On Thu, Feb 10 2011, John Hendy wrote:
> Is anyone else having that issue?

 (custom-set-variables
 '(org-contacts-files '("/home/jwhendy/org/contact-example.org")))

will work better.

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

Hi Julien,

> Following my short presentation at the Paris OrgCamp, I've now written
> a page and officially released org-contacts. It is a contact manager
> based on Org, that can possibly replace BBDB for certain usage.
>
>    http://julien.danjou.info/org-contacts.html

Awesome, Julien!  I'll give it a try as soon as I find some time.

Bye,
Tassilo

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

[John Hendy]

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

On Wed, Feb 9, 2011 at 3:02 AM, Julien Danjou <julien@danjou.info> wrote:

> Hi,
>
> Following my short presentation at the Paris OrgCamp, I've now written a
> page and officially released org-contacts. It is a contact manager based
> on Org, that can possibly replace BBDB for certain usage.
>
>   http://julien.danjou.info/org-contacts.html
>
>
I just gave it a whirl, but am having a strange result. Here were my steps:
- org-contacts.el moved to load path
- added =(require 'org-contacts)= to .emacs
- created ~/org/contact-example.org and used your website's example of Dave
Null
- I used org-customize to set the definition of the =org-contacts-files=
variable like so:
,-----
| (custom-set-variables
| '(org-contacts-files "/home/jwhendy/org/contact-example.org"))
`-----
- restarted emacs and did 'M-x org-contacts' followed by typing "dave"
- the minibuffer shows the following:
,-----
| non-existent agenda file ~/org/#+startup: showeverything. [R]emove from
list or [A]bort?
`-----

Removing the line just moves to the next line and asks if I want to remove
'~/org/* Friends', then '~/org/** Dave Null' and so on.

What am I doing wrong?


Best regards,
John



> --
> Julien Danjou
> ❱ http://julien.danjou.info
>
> _______________________________________________
> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 2594 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Dan Griswold]

Julien,

This is pretty neat. I would like to use this eventually, as bbdb
exhibits some strange behaviors occasionally, and the data is kind of
locked into bbdb's own peculiar format.

What I would need to see before I could make org-contacts part of my
workings system is an analogue to bbdb/gnus-split-method, that is, an
org-contacts function that would hook into nnimap-split-rule so incoming
messages could be deposited into folders based on a specific property,
for example, "gnus-private".

Thank you for your great work. I really think there is huge potential in
this.

Dan



-- 
--------------
Dan Griswold
Rochester, NY
--------------

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

[Julien Danjou]

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

On Thu, Feb 10 2011, Dan Griswold wrote:

> This is pretty neat. I would like to use this eventually, as bbdb
> exhibits some strange behaviors occasionally, and the data is kind of
> locked into bbdb's own peculiar format.
>
> What I would need to see before I could make org-contacts part of my
> workings system is an analogue to bbdb/gnus-split-method, that is, an
> org-contacts function that would hook into nnimap-split-rule so incoming
> messages could be deposited into folders based on a specific property,
> for example, "gnus-private".

Yeah, this has been already asked. I don't know this mechanism well, but
I'll try to study it and implement such a thing.
It shouldn't be too hard.

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Dan Davison]

Julien Danjou <julien@danjou.info> writes:

> Hi,
>
> Following my short presentation at the Paris OrgCamp, I've now written a
> page and officially released org-contacts. It is a contact manager based
> on Org, that can possibly replace BBDB for certain usage.
>
>    http://julien.danjou.info/org-contacts.html

Hi Julien,

I'm using it (with gnus). Looks great and seems to work very nicely so
far.

One little thing: I don't seem to be getting case-insensitive
completion, despite having org-contacts-completion-ignore-case set to t.

Side-issue: Columns view is going to be nice for editing our
org-contacts file. Can someone tell me if there is a way to instruct a
file (or subtree) to start up in columns view, rather than having to
issue C-c C-x C-c manually? (Like #+startup: columns or something)?

Thanks very much,

Dan

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

[Julien Danjou]

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

On Thu, Feb 10 2011, Dan Davison wrote:

> Hi Julien,
>
> I'm using it (with gnus). Looks great and seems to work very nicely so
> far.
>
> One little thing: I don't seem to be getting case-insensitive
> completion, despite having org-contacts-completion-ignore-case set to t.

Your the second one to report that to me, but it does work for me with
Emacs 24 at least.

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

[John Hendy]

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

I can confirm, but it's flaky.

For example, with the default settings, it worked (M-x org-contacts + "dave"
= "Dave"). But I just changed my rule to this:

|----- in org-contacts.el
,-----
| (defcustom org-contacts-company-property "Company"
| (defcustom org-contacts-matcher (concat org-contacts-company-property
"<>\"\"")
`-----

I don't always have an email property, but I always have a :Company:
property. Once I did that... the case insensitivity disappeared. I now have
to be case explicit when searching (only "Dave" works).


John

On Thu, Feb 10, 2011 at 8:56 AM, Julien Danjou <julien@danjou.info> wrote:

> On Thu, Feb 10 2011, Dan Davison wrote:
>
> > Hi Julien,
> >
> > I'm using it (with gnus). Looks great and seems to work very nicely so
> > far.
> >
> > One little thing: I don't seem to be getting case-insensitive
> > completion, despite having org-contacts-completion-ignore-case set to t.
>
> Your the second one to report that to me, but it does work for me with
> Emacs 24 at least.
>
> --
> Julien Danjou
> ❱ http://julien.danjou.info
>
> _______________________________________________
> 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
>
>

[-- Attachment #1.2: Type: text/html, Size: 2091 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Dan Davison]

Julien Danjou <julien@danjou.info> writes:

> On Thu, Feb 10 2011, Dan Davison wrote:
>
>> Hi Julien,
>>
>> I'm using it (with gnus). Looks great and seems to work very nicely so
>> far.
>>
>> One little thing: I don't seem to be getting case-insensitive
>> completion, despite having org-contacts-completion-ignore-case set to t.
>
> Your the second one to report that to me, but it does work for me with
> Emacs 24 at least.

I'm using Emacs 24 on OS X cocoa. I did have a quick look at the code;
I'm not familiar with the common lisp constructs, so maybe it will be
educational for me to look again.

Dan

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

[Rodrigo Lazo]

Julien Danjou <julien@danjou.info> writes:

> On Thu, Feb 10 2011, Dan Davison wrote:
>
>> Hi Julien,
>>
>> I'm using it (with gnus). Looks great and seems to work very nicely so
>> far.
>>
>> One little thing: I don't seem to be getting case-insensitive
>> completion, despite having org-contacts-completion-ignore-case set to t.
>
> Your the second one to report that to me, but it does work for me with
> Emacs 24 at least.

I have the exact same issue, using a fairly recent emacs-24
checkout.

Other than that, works as advertised, Great work!

-- 

Rodrigo Lazo

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

[Tassilo Horn]

Julien Danjou <julien@danjou.info> writes:

Hi Julien,

>> One little thing: I don't seem to be getting case-insensitive
>> completion, despite having org-contacts-completion-ignore-case set to
>> t.
>
> Your the second one to report that to me,

Yeah, I mentioned that on irc.

> but it does work for me with Emacs 24 at least.

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

GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.22.1) of
2011-02-07 on thinkpad

When at the start of the To: header, I have to start with A<tab> to
complete to some of the various Andreases.  a<tab> simply inserts a tab
character after the a.

Bye,
Tassilo

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

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: Completing with anything

[Eric Abrahamsen]

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

This is what I've been using to insert other people's contact
information into emails. Probably no good for general use, but maybe
will provide food for thought.

#+BEGIN_SRC emacs-lisp
(defun my-cite-contact (name)
  (interactive "sName (regexp): ")
  (let ((rec)
	(records (bbdb-search (bbdb-records) name name name nil nil)))
    (if (= (length records) 1)
	(setq rec (car records))
      (if (zerop (length records))
	  (error "No matching records")
	(setq rec
	      (let ((int-name (ido-completing-read "Pick one: "
						   (mapcar 'bbdb-record-name records))))
		(car (bbdb-search (bbdb-records) int-name))))))
    (insert (bbdb-dwim-net-address rec))))
#+END_SRC

Re: Re: Completing with anything

[Eric S Fraga]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

[...]

> This is what I've been using to insert other people's contact
> information into emails. Probably no good for general use, but maybe
> will provide food for thought.
>
> #+BEGIN_SRC emacs-lisp
> (defun my-cite-contact (name)
>   (interactive "sName (regexp): ")
>   (let ((rec)
> 	(records (bbdb-search (bbdb-records) name name name nil nil)))
>     (if (= (length records) 1)
> 	(setq rec (car records))
>       (if (zerop (length records))
> 	  (error "No matching records")
> 	(setq rec
> 	      (let ((int-name (ido-completing-read "Pick one: "
> 						   (mapcar 'bbdb-record-name records))))
> 		(car (bbdb-search (bbdb-records) int-name))))))
>     (insert (bbdb-dwim-net-address rec))))
> #+END_SRC

This looks quite nice; I have been missing the possibility of a regex
search for mail addresses and the combination with ido is quite
appealing.

How do you invoke it?  I am currently struggling with the interactions
between .mailrc (emacs mail aliases, expanding as abbrevs) and bbdb
(expanding with TAB).  This is partly why I haven't even considered
using org-contacts yet...

As always, with Emacs, too many choices, too little time!  ;-)

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.92.gf702.dirty)

Re: Completing with anything

[Eric Abrahamsen]

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
> [...]
>
>> This is what I've been using to insert other people's contact
>> information into emails. Probably no good for general use, but maybe
>> will provide food for thought.
>>
>> #+BEGIN_SRC emacs-lisp
>> (defun my-cite-contact (name)
>>   (interactive "sName (regexp): ")
>>   (let ((rec)
>> 	(records (bbdb-search (bbdb-records) name name name nil nil)))
>>     (if (= (length records) 1)
>> 	(setq rec (car records))
>>       (if (zerop (length records))
>> 	  (error "No matching records")
>> 	(setq rec
>> 	      (let ((int-name (ido-completing-read "Pick one: "
>> 						   (mapcar 'bbdb-record-name records))))
>> 		(car (bbdb-search (bbdb-records) int-name))))))
>>     (insert (bbdb-dwim-net-address rec))))
>> #+END_SRC
>
> This looks quite nice; I have been missing the possibility of a regex
> search for mail addresses and the combination with ido is quite
> appealing.
>
> How do you invoke it?  I am currently struggling with the interactions
> between .mailrc (emacs mail aliases, expanding as abbrevs) and bbdb
> (expanding with TAB).  This is partly why I haven't even considered
> using org-contacts yet...
>
> As always, with Emacs, too many choices, too little time!  ;-)

I only ever invoke it through M-x, as I only ever use it to paste other
people's contact details into an email (something I find myself doing
surprisingly often).

The trick was definitely figuring out at what "level" to let ido do its
thing. The key was that bbdb came with both its own generic search
function, and its own formatting function—ido is just the glue between,
if necessary.

I don't really like the fact that you first produce a collection of
records, then pick *the name* of one record and essentially re-search
all the records for that particular name, but I couldn't figure out a
way to have ido select from among *representations* of actual records,
and then return the record directly. I think that's where ido will trip
you up: it's only made to select from strings.

E

Re: Re: Completing with anything

[Julien Danjou]

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

On Tue, Mar 22 2011, Eric S Fraga wrote:

> How do you invoke it?  I am currently struggling with the interactions
> between .mailrc (emacs mail aliases, expanding as abbrevs) and bbdb
> (expanding with TAB).  This is partly why I haven't even considered
> using org-contacts yet...

I promise you'll soon have both features in org-contacts. ;)

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

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

Re: Re: Completing with anything

[Eric S Fraga]

Julien Danjou <julien@danjou.info> writes:

> On Tue, Mar 22 2011, Eric S Fraga wrote:
>
>> How do you invoke it?  I am currently struggling with the interactions
>> between .mailrc (emacs mail aliases, expanding as abbrevs) and bbdb
>> (expanding with TAB).  This is partly why I haven't even considered
>> using org-contacts yet...
>
> I promise you'll soon have both features in org-contacts. ;)

excellent!  I'm definitely willing to be pulled further into the
all-encompassing org world... ;-)

Will you provide a means to capturing email addresses from emails
directly into an org-contacts db, as bbdb does with ":" and ";" (the
latter for annotation of the entry)?  That would be necessary for any
move away from bbdb, IMO.

Thanks,
eric

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.99.gac6e4.dirty)

Re: Re: Completing with anything

[Julien Danjou]

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

On Wed, Mar 23 2011, Eric S Fraga wrote:

> Will you provide a means to capturing email addresses from emails
> directly into an org-contacts db, as bbdb does with ":" and ";" (the
> latter for annotation of the entry)?  That would be necessary for any
> move away from bbdb, IMO.

This is already provided.

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

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

Re: Re: Completing with anything

[Eric S Fraga]

Julien Danjou <julien@danjou.info> writes:

> On Wed, Mar 23 2011, Eric S Fraga wrote:
>
>> Will you provide a means to capturing email addresses from emails
>> directly into an org-contacts db, as bbdb does with ":" and ";" (the
>> latter for annotation of the entry)?  That would be necessary for any
>> move away from bbdb, IMO.
>
> This is already provided.

Oh, right!  Need to check it out more closely obviously.  Thanks.

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.50.1
: using Org-mode version 7.5 (release_7.5.105.g8d0c)

Re: Re: Completing with anything

[Cian]

Can you separate out the gnus specific code at some point. If I ever
get any time (two small children and a day job, so big if) I'd like to
integrate it into Wanderlust. But currently the code assumes that
you're using gnus.

On Wed, Mar 23, 2011 at 3:05 PM, Julien Danjou <julien@danjou.info> wrote:
> On Wed, Mar 23 2011, Eric S Fraga wrote:
>
>> Will you provide a means to capturing email addresses from emails
>> directly into an org-contacts db, as bbdb does with ":" and ";" (the
>> latter for annotation of the entry)?  That would be necessary for any
>> move away from bbdb, IMO.
>
> This is already provided.
>
> --
> Julien Danjou
> ❱ http://julien.danjou.info
>

Re: Re: Completing with anything

[Julien Danjou]

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

On Thu, Mar 24 2011, Cian wrote:

> Can you separate out the gnus specific code at some point. If I ever
> get any time (two small children and a day job, so big if) I'd like to
> integrate it into Wanderlust. But currently the code assumes that
> you're using gnus.

Sure, I'll add that to my todo list.

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

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

Re: Re: Completing with anything

[Michael Markert]

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

On 25 Mar 2011, Julien Danjou wrote:
> [1  <text/plain; utf-8 (quoted-printable)>]
> On Thu, Mar 24 2011, Cian wrote:
>
>> Can you separate out the gnus specific code at some point. If I ever
>> get any time (two small children and a day job, so big if) I'd like to
>> integrate it into Wanderlust. But currently the code assumes that
>> you're using gnus.
>
> Sure, I'll add that to my todo list.

I've wrote some code at least for template support:
#+BEGIN_SRC emacs-lisp
(require 'std11)                        ; from FLIM
(require 'wl-address)                   ; from Wanderlust
(defun wl-get-from-header-content (buffer)
  (save-excursion
    (set-buffer buffer)
    (std11-narrow-to-header)
    (prog1
        (std11-fetch-field "From")
      (widen))))

(defun org-contacts-template-wl-name ()
  (wl-address-header-extract-realname (wl-get-from-header-content
                                      (org-capture-get :original-buffer))))
(defun org-contacts-template-wl-email ()
  (wl-address-header-extract-address (wl-get-from-header-content
                                      (org-capture-get :original-buffer))))
#+END_SRC

Because Wanderlust keeps several message buffers you have to start
capture from within a message buffer, not a summary buffer. But I'll
look into it.

Michael

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

Re: Re: Completing with anything

[Michael Markert]

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

On 26 Mar 2011, Michael Markert wrote:
> Because Wanderlust keeps several message buffers you have to start
> capture from within a message buffer, not a summary buffer. But I'll
> look into it.

Attached code handles both capturing from summary and message
buffer.

Michael


[-- Attachment #1.2: org-contacts-wl.el --]
[-- Type: text/plain, Size: 1211 bytes --]

(require 'std11)
(require 'elmo)
(require 'wl-address)
(require 'wl-summary)

(defun wl-get-from-header-content ()
  (save-excursion
    (set-buffer (org-capture-get :original-buffer))
    (cond
     ((eq major-mode 'wl-summary-mode) (when wl-summary-buffer-elmo-folder
                                         (elmo-message-field
                                          wl-summary-buffer-elmo-folder
                                          (wl-summary-message-number)
                                          'from)))
     ((eq major-mode 'mime-view-mode) (std11-narrow-to-header)
                                      (prog1
                                          (std11-fetch-field "From")
                                        (widen))))))

(defun org-contacts-template-wl-name (&optional return-value)
  (let ((from (wl-get-from-header-content)))
    (or (and from (wl-address-header-extract-realname from))
       return-value
       "%^{Name}")))

(defun org-contacts-template-wl-email (&optional return-value)
  (let ((from (wl-get-from-header-content)))
    (or (and from (wl-address-header-extract-address from))
       return-value
       (concat "%^{" org-contacts-email-property "}p"))))

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



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

Re: Re: Completing with anything

[Julien Danjou]

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

On Sun, Mar 27 2011, Michael Markert wrote:

> Attached code handles both capturing from summary and message
> buffer.

I'd like to merge this, but I have to ask: did you signed the copyright
assignement papers?

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

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

Re: Re: Completing with anything

[Michael Markert]

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

On 9 Apr 2011, Julien Danjou wrote:
> On Sun, Mar 27 2011, Michael Markert wrote:
>> Attached code handles both capturing from summary and message
>> buffer.
>
> I'd like to merge this, but I have to ask: did you signed the copyright
> assignement papers?

No, but if it's necessary (or helping) I'll do so.

Michael

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

Re: Re: Completing with anything

[Julien Danjou]

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

On Sat, Apr 09 2011, Michael Markert wrote:

> No, but if it's necessary (or helping) I'll do so.

Well, since org-contacts is part of contrib I think it's not necessary,
so I'll merge it as it is unless Bastien says I'm wrong.

Thanks.

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

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

Re: Re: Completing with anything

[Bastien]

Julien Danjou <julien@danjou.info> writes:

> On Sat, Apr 09 2011, Michael Markert wrote:
>
>> No, but if it's necessary (or helping) I'll do so.
>
> Well, since org-contacts is part of contrib I think it's not necessary,
> so I'll merge it as it is unless Bastien says I'm wrong.

You're right.  No need for FSF copyright assignment for code in the
contrib/ directory, as this directory does not go to the Emacs trunk.

Still, it's always better to get the assignment process done in case 
code from contrib has to move to Org's core.

-- 
 Bastien

Re: Re: Completing with anything

[Michael Markert]

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

On 11 Apr 2011, Bastien wrote:

> Julien Danjou <julien@danjou.info> writes:
>
>> On Sat, Apr 09 2011, Michael Markert wrote:
>>
>>> No, but if it's necessary (or helping) I'll do so.
>>
>> Well, since org-contacts is part of contrib I think it's not necessary,
>> so I'll merge it as it is unless Bastien says I'm wrong.
>
> You're right.  No need for FSF copyright assignment for code in the
> contrib/ directory, as this directory does not go to the Emacs trunk.
>
> Still, it's always better to get the assignment process done in case
> code from contrib has to move to Org's core.

I'll do so then.

Michael

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

Re: Completing with anything

[Michael Markert]

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

On 11 Apr 2011, Michael Markert wrote:
> On 11 Apr 2011, Bastien wrote:
>
>> Julien Danjou <julien@danjou.info> writes:
>>
>>> On Sat, Apr 09 2011, Michael Markert wrote:
>>>
>>>> No, but if it's necessary (or helping) I'll do so.
>>>
>>> Well, since org-contacts is part of contrib I think it's not necessary,
>>> so I'll merge it as it is unless Bastien says I'm wrong.
>>
>> You're right.  No need for FSF copyright assignment for code in the
>> contrib/ directory, as this directory does not go to the Emacs trunk.
>>
>> Still, it's always better to get the assignment process done in case
>> code from contrib has to move to Org's core.
>
> I'll do so then.
>
> Michael

Today I received the assignment papers and signed them. Next week
they'll be on their way to the FSF.

So feel free to include my code if that hindered you from doing so yet.

Michael

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

Re: Completing with anything

[Julien Danjou]

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

On Sun, Mar 27 2011, Michael Markert wrote:

> Attached code handles both capturing from summary and message
> buffer.

I've added this file into contrib, beside org-contacts.el

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

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

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

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 

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

[Darlan Cavalcante Moreira]

This is awesome. I always wanted to move from bbdb to org for my contacts.
Any chance this will work with other Emacs mail clients, such as
Wanderlust?

--
Darlan

At Wed, 09 Feb 2011 10:02:58 +0100,
Julien Danjou <julien@danjou.info> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; utf-8 (quoted-printable)>]
> Hi,
> 
> Following my short presentation at the Paris OrgCamp, I've now written a
> page and officially released org-contacts. It is a contact manager based
> on Org, that can possibly replace BBDB for certain usage.
> 
>    http://julien.danjou.info/org-contacts.html
> 
> -- 
> Julien Danjou
> ❱ http://julien.danjou.info
> [1.2  <application/pgp-signature (7bit)>]
> 
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Julien Danjou]

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

On Fri, Feb 11 2011, Darlan Cavalcante Moreira wrote:

> This is awesome. I always wanted to move from bbdb to org for my contacts.
> Any chance this will work with other Emacs mail clients, such as
> Wanderlust?

I use Gnus, so there's no chance I'll work on that. But I'm willing to
accept well written patches, of course.

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Bastien]

Hi Julien,

Julien Danjou <julien@danjou.info> writes:

> Following my short presentation at the Paris OrgCamp, I've now written a
> page and officially released org-contacts. It is a contact manager based
> on Org, that can possibly replace BBDB for certain usage.
>
>    http://julien.danjou.info/org-contacts.html

This is great, thanks for this!

I've played around with it, and I can already see the benefit.  When
org-contacts will insinuate into Gnus, that will be a real win.

I'm willing to add this to contrib/lisp/ - would that be okay for you?

Thanks,

-- 
 Bastien

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

[John Hendy]

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

>
> Julien Danjou <julien@danjou.info> writes:
>
> > Following my short presentation at the Paris OrgCamp, I've now written a
> > page and officially released org-contacts. It is a contact manager based
> > on Org, that can possibly replace BBDB for certain usage.
> >
> >    http://julien.danjou.info/org-contacts.html
>
>
I know people have responded re. the A/a+tab when trying to use for email...
but did anyone solve the pure 'M-x org-contacts N/name' issue? Are they the
same? I just want proper case insensitivity and don't use it for email.


Thanks,
John


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

[-- Attachment #1.2: Type: text/html, Size: 1475 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: Announcing org-contacts, a bbdb-like contact manager for Org

[Bastien]

Hi John,

John Hendy <jw.hendy@gmail.com> writes:

> I know people have responded re. the A/a+tab when trying to use for
> email... but did anyone solve the pure 'M-x org-contacts N/name'
> issue? Are they the same? I just want proper case insensitivity and
> don't use it for email.

Julien is away for more than a week, I guess he will answer these
questions when he's back.

-- 
 Bastien

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

[Julien Danjou]

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

On Sat, Feb 12 2011, John Hendy wrote:

> I know people have responded re. the A/a+tab when trying to use for email...
> but did anyone solve the pure 'M-x org-contacts N/name' issue? Are they the
> same? I just want proper case insensitivity and don't use it for email.

Case insensitivity works correctly with M-x org-contacts AFAIK.

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Matt Lundin]

Bastien <bastien.guerry@wikimedia.fr> writes:

> Hi Julien,
>
> Julien Danjou <julien@danjou.info> writes:
>
>> Following my short presentation at the Paris OrgCamp, I've now written a
>> page and officially released org-contacts. It is a contact manager based
>> on Org, that can possibly replace BBDB for certain usage.
>>
>>    http://julien.danjou.info/org-contacts.html
>
> I've played around with it, and I can already see the benefit.  When
> org-contacts will insinuate into Gnus, that will be a real win.

Agreed. Thanks, Julien!

I'm curious how others are planning to organize contacts (i.e., in a
single file or scattered throughout agenda files).

I tried org-contacts with my rather large agenda files, but because it
uses org-scan-tags instead of regexp searches, queries are slow. E.g.,
org-contacts-filter takes approximately 15-20 seconds.

Also, the function org-contacts uses a tags/property search and then a
skip function. Would it perhaps be quicker to use org-search-view to
match against two regexps (the name and the contacts email property)?

Best,
Matt

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

[Julien Danjou]

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

On Sat, Feb 12 2011, Matt Lundin wrote:

> I tried org-contacts with my rather large agenda files, but because it
> uses org-scan-tags instead of regexp searches, queries are slow. E.g.,
> org-contacts-filter takes approximately 15-20 seconds.

Yeah, it's hard to use if you contacts are accross large agenda files.
It's slow. Using the anniversary code is currently impossible if you do
not use a single small contact file.

I plan to improve that later.

> Also, the function org-contacts uses a tags/property search and then a
> skip function. Would it perhaps be quicker to use org-search-view to
> match against two regexps (the name and the contacts email property)?

Maybe. Anyhow I've a lot of ideas for that. Considers the current
version as a quick hack. :)

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Wes Hardaker]

>>>>> On Sat, 12 Feb 2011 13:18:10 +0100, Bastien <bastien.guerry@wikimedia.fr> said:

B> I've played around with it, and I can already see the benefit.  When
B> org-contacts will insinuate into Gnus, that will be a real win.

Ditto!  This will be such a wonderful way to maintain contacts that will
have significant advantages over the elisp based storage mechanisms.  I
frequently need to look up contacts away from emacs and resort to 'grep'
in my .bbdb file as quick hack, which is far less than pretty.  Having
the data in org will mean better export support, better free-form
support, ...

Please keep plugging away at it!

[oh, and I can't wait for the first person to write bbdb-to-org-contacts :-]
-- 
Wes Hardaker                                     
My Pictures:  http://capturedonearth.com/
My Thoughts:  http://pontifications.hardakers.net/

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

[Julien Danjou]

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

On Sat, Feb 12 2011, Bastien wrote:

> I'm willing to add this to contrib/lisp/ - would that be okay for you?

Since I plan to continue working and improving it soon, it seems like it
would be too much work getting it update for now since I couldn't commit
directly. So maybe it's best to wait a bit, and I'll ask for its
inclusion later?

-- 
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: Announcing org-contacts, a bbdb-like contact manager for Org

[Bastien]

Julien Danjou <julien@danjou.info> writes:

> On Sat, Feb 12 2011, Bastien wrote:
>
>> I'm willing to add this to contrib/lisp/ - would that be okay for you?
>
> Since I plan to continue working and improving it soon, it seems like it
> would be too much work getting it update for now since I couldn't commit
> directly. So maybe it's best to wait a bit, and I'll ask for its
> inclusion later?

Yes, let's do that.  Thanks!

-- 
 Bastien