On Mon Feb 14 2011 Stefan Monnier wrote:
- 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.
My concerns are related to the *Completions* buffer.
If every element in a completion list has just 10 or 20 characters,
a *Completions* buffer with 30 or 40 elements is still managable in
the sense that it will not take more than 10 or 12 screen lines
that one can look over fairly quickly.
If, on the other hand, the elements in the completion list have 50
or 60 characters (which can happen for email addresses plus real
names), I find that the *Comletions* buffer is of little help. This
is just my personal opinion. Maybe others are better in finding what
they want.
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.
Personally, I much agree with you. And one of the reasons that I
myself do not use bbdb-complete-name might be that somehow this
command behaves too different from what I am used to in other
emacs-related context.
Yet I also agree that the approach implemented in bbdb-complete-name
has has some justification for its particular purpose: We cannot ask
people they should always use email addresses which contain their
real name because that's what emacs cycling requires... Sometimes
one might want to send an email to Joe Smith to his address
f...@bar.com without including his real name.
In any case, it appears to me that this function is one of the
features of BBDB some people really like, so that at best one could
use alternative approach and let the users choose what they want.
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.
Such word boundaries imply some restriction on possible completions.
But personally I want to say: this should be good enough!
(Anybody else wants to comment here?)
(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.
I understand this point!
- 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.
Thanks! I might want to write an alternative bbdb-complete-name-2
that uses these features. Then people can choose the approach they
like better.
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.
Thanks, that's a very good point. This function could also translate
a precomputed completion table using a format convenient for BBDB
into the standard format, as needed.
I need to think about how this could possibly simplify things.
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).
Again, thanks for your help with these things. I need to think about
this more carefully.
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