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 https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
