On Fri Feb 11 2011 Stefan Monnier wrote:
> To tell you the truth, the infrastructure might have some missing
> elements, but I'm interested in addressing those issues.
Some more thoughts on this:
- One problem with completion in BBDB can be that if the algorithm
isn't optimized enough for its particular problem, it happens too
easily that the algorithm offers too many completions, so that
identifying the right ones becomes the search for a needle in a
haystick - which in the end is of little help.
- Individual completions can be pretty long. Not everybody has a
short address <f...@gnu.org>. So just a few completions can easily
occupy a lot of screen space, which adds to the confusion.
- In the end, BBDB can consider quite many criteria for possibly
including an address in the completion set (first names, last
names, AKAs, organizations, mail addresses,...). Sometimes I
wonder myself: why am I getting this completion here?? (And I am
getting very distracted by this kind of stuff...)
Of course, this behavior is customizable, but next time you miss
the completion you were aiming for...
So I would suggest the following "BBDB task sheet" for a generic
completion algorithm that could possibly replace the current code in
bbdb-complete-mail:
(1) Substring completion needs to have some understanding of the
text that is completed so that completion starting points within
the full strings are meaningful:
- typing `ler' should complete `john leremy <l...@bar.com>'
or `<johnler...@bar.com>' (or even `<johnler...@bar.com>'),
but not `Joe Miller <j...@bar.com>'
- typing `com' should only complete to your buddy's name
`John Combs <co...@bar.org>' but never j...@bar.com
...you can easily figure out more such examples.
One could possibly use text properties to mark allowed starting
points for substring completion in a string like <johnler...@bar.com>
(2) The algorithm needs to recognize which lexicographically
unrelated mail addresses belong to one record so that cycling
can be based on these entries only:
- <f...@bar.com> and <g...@baz.org> might be addresses of the same
person so that we want to cycle through them
- <f...@bar.com> and <f...@baz.com> might be addresses for
different persons so that cycling makes no sense.
(The latter is to some extent a matter of taste. In any case,
this is the currently implemented behavior of bbdb-complete-mail.)
So if all possible completions were calcluated in advance, the
completion list could become something like a list of sublists,
where each sublist means: these different strings should be
considered for cycling.
(3) Before I started to use BBDB, I only used mail-abbrev-complete-alias
for completing mail abbrevs. I'd like to have a way that
combines these concepts. Namely, it should be customizable
whether mail-abbrev expansion is tried first and then the
completion command tries to use BBDB records for completion;
or we do these steps in opposite order.
Probably, this can be achieved if both mail-abbrev-complete-alias
and bbdb-complete-mail use non-nil return values if they "did
something" and nil otherwise -- which was the original question
for bbdb-complete-mail that started this thread.
Then, a wrapper around these commands could try each of them in
a customizable order.
Roland
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/
