[ Apparently my messages don't make it to the list because the list
does not accept messages from the Gmane gateway. ]
> - 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.
The normal completion code was designed to handle the case of "many
completion candidates" reasonably well (i.e. by not cycling).
completion-cycle-threshold tries to combine the best of both worlds.
> - 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.
I'm not sure I understand what you're referring to.
> - 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...
I think it's important to ensure that the original string appears
somehow in the completion, to avoid such confusions. That's one of the
basic ideas behind traditional completion.
> (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:
Current `substring' completion does not enjoy this property, but I've
bumped into this need in the past and I agree that there are many cases
where it would be very welcome. We (c|sh)ould clearly add a such new
completion style that only consider substring matches that start at
a word-boundary.
> One could possibly use text properties to mark allowed starting
> points for substring completion in a string like <johnler...@bar.com>
We could also just accept CamelCase as a word boundary. It'd probably
be just as easy to implement.
> (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:
The generic completion is basically designed to make that very difficult
if not impossible: the user-provided string should appear somehow (the
definition of this somehow depends on the completion style) in the
suggested completions.
> - <f...@bar.com> and <g...@baz.org> might be addresses of the same
> person so that we want to cycle through them
I think you can't do that with the generic completion code, but I also
think this is not actually a feature. OTOH, the current code shouldn't
have any trouble cycling between
"Henry Toto" <f...@bar.com>
and
"Henry Toto" <g...@baz.org>
if the user typed "Henry T" or even "H T".
> 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.
The completion table can be a function: there's no need to precompute
all possible completions.
> 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.
You can use completion-table-in-turn to combine two completion tables
into a new one that only considers the second when the first did not
find any candidates. This said, this sometimes doesn't interacts too
well with non-prefix completions (these are bugs, tho, so we should be
hopefully able to fix them).
Stefan
------------------------------------------------------------------------------
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/
