Re: bbdb-complete-name return value
>> IMO the cycling should only be based on scores. That would, I think, >> accomplish all your items and produce less "DWIM but that's not it." Currently, the cycling code is fairly naive and it uses a fixed ordering based on string length (shorter first). Patches to make it more customizable (by the completion table, not just by the end-user) would be very welcome (e.g. for file completion, it could first cycle through VCS-managed files). > Do you have any thoughts / plans on implementing something like that > for the generic completion code? Directly, no. But adding "hooks" so that the completion table can come with its own sorting function, yes. 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/
Re: bbdb-complete-name return value
[ 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 . 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 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. > - and 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" and "Henry Toto" 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/
Re: bbdb-complete-name return value
On Sun Feb 13 2011 Ted Zlatanov wrote: > I would approach this as a scoring problem. Let BBDB have a score for > each address (so multiples can be in a record), defaulting to 0. [snip] > And so on, but the important thing is to have scoring rules and base > scores. The user should be able to customize both. Then just order the > candidates by score. > > RW> (2) The algorithm needs to recognize which lexicographically > RW> unrelated mail addresses belong to one record so that cycling > RW> can be based on these entries only: > > IMO the cycling should only be based on scores. That would, I think, > accomplish all your items and produce less "DWIM but that's not it." In principle, this sounds like a good idea. (It kind of reminds me of how TeX is doing its line breaks. But there are probably zillions of other applications that do similar things.) Maybe Stefan can comment here: Do you have any thoughts / plans on implementing something like that for the generic completion code? Again, it appears to me that an important question would be: How can one communicate such scores to the generic algorithm? 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/
Re: bbdb-complete-name return value
On Sat, 12 Feb 2011 11:47:40 -0600 "Roland Winkler" wrote: RW> So I would suggest the following "BBDB task sheet" for a generic RW> completion algorithm that could possibly replace the current code in RW> bbdb-complete-mail: RW> (1) Substring completion needs to have some understanding of the RW> text that is completed so that completion starting points within RW> the full strings are meaningful: RW> - typing `ler' should complete `john leremy ' RW> or `' (or even `'), RW> but not `Joe Miller ' RW> - typing `com' should only complete to your buddy's name RW> `John Combs ' but never j...@bar.com RW> ...you can easily figure out more such examples. I would approach this as a scoring problem. Let BBDB have a score for each address (so multiples can be in a record), defaulting to 0. Then: - exact matches (matching the beginning-of-word boundary) get +1 - case-sensitive substring matches get +5000 - case-insensitive substring matches get +2000 - substring on the name gets 100, substring on the address gets +50 - each completion to an address does (incf address-score 10) in BBDB - user can edit the record's scores directly And so on, but the important thing is to have scoring rules and base scores. The user should be able to customize both. Then just order the candidates by score. RW> (2) The algorithm needs to recognize which lexicographically RW> unrelated mail addresses belong to one record so that cycling RW> can be based on these entries only: IMO the cycling should only be based on scores. That would, I think, accomplish all your items and produce less "DWIM but that's not it." Ted -- 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/
Re: BBDB 3.0
On Sun Feb 13 2011 Antoine Levitt wrote: > > I guess from your perspective bbdb-mua-pop-up-bbdb-buffer is, first > > of all, a misnomer. The main action is hidden in > > bbdb-mua-update-records. -- I'll look into this. > > Yes. Maybe there should be two separate functions added to the hook, one > for noticing and the other for displaying the popup. Having one function is cleaner because order matters here. The pop-up make sense only after evaluating the records. Yet with hooks it's better not to assume that its elements are run in a specific 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/
Re: BBDB 3.0
On Sun Feb 13 2011 Antoine Levitt wrote: > 13/02/11 14:12, Roland Winkler > > On Sun Feb 13 2011 Antoine Levitt wrote: > >> It does work, but this enables a pop-up window, which I don't want. With > >> this init, setting bbdb-message-pop-up to nil also disables the > >> noticing, is that normal? > > > > I am sorry, this could be a bug. Let me look at this more carefully. > > -- What kind of action do you expect to get from noticing? > > Indeed, up to now I have not much thought about it, because I did > > not recognize a good purpose from noticing for myself. For which > > purpose do you use it? > > My main use case of bbdb is to have it automatically notice any email I > get or send, so that I can use it to complete emails in message-mode, > and occasionally store other information (such as phone > numbers). Therefore, I don't want any popups when bbdb notices someone, > I just want it to silently add the contact to the bbdb (according to the > settings in bbdb-accept/ignore-message-alist). This used to work just > fine in BBDB 2.0, with minimal config. I see, thanks! > I think the let should be before the if in > bbdb-mua-pop-up-bbdb-buffer. Or even better, bbdb-insinuate would hook a > function to notice contacts, independently from pop-ups. I guess from your perspective bbdb-mua-pop-up-bbdb-buffer is, first of all, a misnomer. The main action is hidden in bbdb-mua-update-records. -- I'll look into this. Roland PS: The above two message did not appear on the mailing list. Now we should be back. -- 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/
