(patch) sort cycling completion candidates (was: bbdb-complete-name return value)

2011-03-08 Thread Ted Zlatanov
Attached please find a patch to sort cycling completion candidates by
the text property :completion-cycle-penalty (lower is better).

Thanks
Ted

=== modified file 'lisp/minibuffer.el'
--- lisp/minibuffer.el	2011-02-12 18:30:13 +
+++ lisp/minibuffer.el	2011-03-08 14:51:07 +
@@ -704,7 +704,19 @@
 (when last
   (setcdr last nil)
   ;; Prefer shorter completions.
-  (setq all (sort all (lambda (c1 c2) ( (length c1) (length c2)
+  (setq
+   all
+   (sort all
+ (lambda (c1 c2)
+   (let ((s1 (get-text-property
+  0 :completion-cycle-penalty c1))
+ (s2 (get-text-property
+  0 :completion-cycle-penalty c2)))
+ (cond ((and s1 s2) (cond (( s1 s2) t)
+  (( s1 s2) nil)
+  (t ( (length c1) (length c2)
+   (s1 t)
+   (s2 nil))
   ;; Prefer recently used completions.
   (let ((hist (symbol-value minibuffer-history-variable)))
 (setq all (sort all (lambda (c1 c2)

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d___
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

2011-03-05 Thread Stefan Monnier
 I thought that would be easier too, but it's counter-intuitive.

It's only counter intuitive if you think of it (and name it) something
like score.  So yes, we need another name to make it less
counter-intuitive.  E.g. `completion-penalty'.  And I think it would be
good to make it clear that this is for cycling, so the name could be
`completion-cycle-penalty'.


Stefan


!   (let ((s1 (get-text-property 0 :completion-score c1))
! (s2 (get-text-property 0 :completion-score c2)))
! (cond ((and s1 s2) ( s1 s2))
!   (s1 t)
!   (s2 nil)

BTW, I'd rather use something like

!   (let ((s1 (get-text-property 0 :completion-score c1))
! (s2 (get-text-property 0 :completion-score c2)))
! (cond ((and s1 s2) (cond (( s1 s2) t)
!  (( s1 s2) nil)
!  (t ( (length c1) (length c2)
!   (s1 t)
!   (s2 nil)

PS: Please Cc the patch to emacs-devel because I don't read this
bbdb-list as regularly.


--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
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

2011-03-01 Thread Ted Zlatanov
On Mon, 28 Feb 2011 18:50:20 -0500 Stefan Monnier monn...@iro.umontreal.ca 
wrote: 

 The only thing I need to clarify is sorting.  Right now shorter string
 wins.  In the new method, higher score should win.

SM I think it's easier if lower scores win, so it's consistent with the
SM current use of `length'.  It's really not a big issue: just negate the
SM values you put on the property and you're done.

I thought that would be easier too, but it's counter-intuitive.  Well,
here's the patch.  It doesn't check that the completion score is a
number but otherwise seems OK to me.  A string with a completion score
always wins over one without.

Ted

=== modified file 'lisp/minibuffer.el'
*** lisp/minibuffer.el  2011-02-12 18:30:13 +
--- lisp/minibuffer.el  2011-03-01 15:39:33 +
***
*** 704,710 
  (when last
(setcdr last nil)
;; Prefer shorter completions.
!   (setq all (sort all (lambda (c1 c2) ( (length c1) (length c2)
;; Prefer recently used completions.
(let ((hist (symbol-value minibuffer-history-variable)))
  (setq all (sort all (lambda (c1 c2)
--- 704,719 
  (when last
(setcdr last nil)
;; Prefer shorter completions.
!   (setq
!all
!(sort all
!  (lambda (c1 c2)
!(let ((s1 (get-text-property 0 :completion-score c1))
!  (s2 (get-text-property 0 :completion-score c2)))
!  (cond ((and s1 s2) ( s1 s2))
!(s1 t)
!(s2 nil)
!(t ( (length c1) (length c2
;; Prefer recently used completions.
(let ((hist (symbol-value minibuffer-history-variable)))
  (setq all (sort all (lambda (c1 c2)




--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-28 Thread Ted Zlatanov
On Mon, 28 Feb 2011 00:17:05 -0500 Stefan Monnier monn...@iro.umontreal.ca 
wrote: 

TZ Maybe accept the score as a property to the candidate strings and use
TZ that property, if it exists, instead of the string length?
TZ That would side-step the current completion mechanism nicely, requiring
TZ little extra code except in the final sort of candidates.  If the
TZ strings aren't mangled by the completion mechanism, of course--but I
TZ don't think they are after a quick scan.

SM That would work.  It's a quicksimple solution (i.e. generally a good
SM sign), but it has one drawback: the properties will be often added
SM without being used, since the list of completions is used not only to
SM build the *Completions* buffer or to cycle through completions but also
SM to do TAB completion (often just handled by try-completion, but with
SM substring completion it instead needs to get the all-completions list
SM and then weed it out).

SM So it has a performance downside (which means, it's not the last word in
SM this respect), but I'd probably accept a patch to add such a feature to
SM minibuffer.el since the performance impact is only incurred by
SM completion tables that really use the feature and it's unlikely to be
SM a serious maintenance problem in the future.

So something like this would work in `completion-all-sorted-completions':

(or (get-text-property 0 :completion-score (propertize hello 
:completion-score 100)) 0)
= 100

...and we're adding an extra `get-text-property' call to all the sorts:

(or (get-text-property 0 :completion-score hello) 0)
= 0

...which should not be a big deal since it's just a plist lookup.

The only thing I need to clarify is sorting.  Right now shorter string
wins.  In the new method, higher score should win.  So I propose these
rules:

- if both have the :completion-score property, sort by highest score
  first

- if one has it, put it first

- if neither has it, shorter string wins

Let me know if you agree and I'll propose the code+doc patch.

Thanks
Ted


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-28 Thread Stefan Monnier
 The only thing I need to clarify is sorting.  Right now shorter string
 wins.  In the new method, higher score should win.

I think it's easier if lower scores win, so it's consistent with the
current use of `length'.  It's really not a big issue: just negate the
values you put on the property and you're done.


Stefan


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-27 Thread Roland Winkler
On Wed Feb 23 2011 Ted Zlatanov wrote:
 SM Currently, the cycling code is fairly naive and it uses a fixed ordering
 SM based on string length (shorter first).  Patches to make it more
 SM customizable (by the completion table, not just by the end-user) would
 SM be very welcome (e.g. for file completion, it could first cycle through
 SM VCS-managed files).
 
 TZ Maybe accept the score as a property to the candidate strings and use
 TZ that property, if it exists, instead of the string length?
 
 TZ That would side-step the current completion mechanism nicely, requiring
 TZ little extra code except in the final sort of candidates.  If the
 TZ strings aren't mangled by the completion mechanism, of course--but I
 TZ don't think they are after a quick scan.
 
 Should I pursue this myself or are you guys (Stefan or Roland)
 interested in doing it?

It appears to me that any such things should be implemented as a
feature of the generic completion code of emacs. To the best of my
knowledge, this is something that Stefan has worked on a lot
(and done a great job!).

Yet I simply do not know his strategies. So I do not know how your
specific suggestion would relate to his plans.

Roland

--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-27 Thread Stefan Monnier
TZ Maybe accept the score as a property to the candidate strings and use
TZ that property, if it exists, instead of the string length?
TZ That would side-step the current completion mechanism nicely, requiring
TZ little extra code except in the final sort of candidates.  If the
TZ strings aren't mangled by the completion mechanism, of course--but I
TZ don't think they are after a quick scan.

That would work.  It's a quicksimple solution (i.e. generally a good
sign), but it has one drawback: the properties will be often added
without being used, since the list of completions is used not only to
build the *Completions* buffer or to cycle through completions but also
to do TAB completion (often just handled by try-completion, but with
substring completion it instead needs to get the all-completions list
and then weed it out).

So it has a performance downside (which means, it's not the last word in
this respect), but I'd probably accept a patch to add such a feature to
minibuffer.el since the performance impact is only incurred by
completion tables that really use the feature and it's unlikely to be
a serious maintenance problem in the future.


Stefan


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-23 Thread Ted Zlatanov
On Thu, 17 Feb 2011 11:09:28 -0600 Ted Zlatanov t...@lifelogs.com wrote: 

TZ On Mon, 14 Feb 2011 02:03:55 -0500 Stefan Monnier 
monn...@iro.umontreal.ca wrote: 
 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.

SM Currently, the cycling code is fairly naive and it uses a fixed ordering
SM based on string length (shorter first).  Patches to make it more
SM customizable (by the completion table, not just by the end-user) would
SM be very welcome (e.g. for file completion, it could first cycle through
SM VCS-managed files).

TZ Maybe accept the score as a property to the candidate strings and use
TZ that property, if it exists, instead of the string length?

TZ That would side-step the current completion mechanism nicely, requiring
TZ little extra code except in the final sort of candidates.  If the
TZ strings aren't mangled by the completion mechanism, of course--but I
TZ don't think they are after a quick scan.

Should I pursue this myself or are you guys (Stefan or Roland)
interested in doing it?

Thanks
Ted


--
Free Software Download: Index, Search  Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
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

2011-02-17 Thread Ted Zlatanov
On Mon, 14 Feb 2011 02:03:55 -0500 Stefan Monnier monn...@iro.umontreal.ca 
wrote: 

 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.

SM Currently, the cycling code is fairly naive and it uses a fixed ordering
SM based on string length (shorter first).  Patches to make it more
SM customizable (by the completion table, not just by the end-user) would
SM be very welcome (e.g. for file completion, it could first cycle through
SM VCS-managed files).

Maybe accept the score as a property to the candidate strings and use
that property, if it exists, instead of the string length?

That would side-step the current completion mechanism nicely, requiring
little extra code except in the final sort of candidates.  If the
strings aren't mangled by the completion mechanism, of course--but I
don't think they are after a quick scan.

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-complete-name return value

2011-02-15 Thread Roland Winkler
On Tue Feb 15 2011 Stefan Monnier wrote:
  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.
 
 I think it makes a lot of sense to provide:
 - bbdb-complete-name, behaving as it currently does.
 - an appropriate function on completion-at-point-functions; with the
   current state of completion-at-point, this will probably not be very
   usable, but we can work (on the Emacs side) to make it better.

Much agreed!

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

2011-02-14 Thread Roland Winkler
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

Re: bbdb-complete-name return value

2011-02-13 Thread Stefan Monnier
 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

2011-02-12 Thread Roland Winkler
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/


Re: bbdb-complete-name return value

2011-02-11 Thread Roland Winkler
On Thu Feb 10 2011 Stefan Monnier wrote:
 Since BBDB3 only works on Emacs 23, its completion could use
 completion-at-point-functions and/or completion-in-region.

I looked into completion-in-region. Here the problem is that the
completion done by bbdb-complete-name is not a comventional
completion. If you type a name appearing in a BBDB record,
bbdb-complete-name replaces this name by the email address for this
record. Yet the name and the email address can be completely
different.

I have not yet looked into completion-at-point-functions whether it
can handle this kind of unusual behavior.

  In any event, a simple t after (run-hooks 'bbdb-complete-mail-hook)
  does the trick, but it probably needs to be changed in some other
  places.
 
 Note also that I've already installed a hack in message.el (at least in
 Emacs's trunk) that checks that the buffer really was not modified
 before trusting a nil return value from bbdb, to work around
 the problem.

Thanks, that's good. Anyway, it might take more time till people
might switch to BBDB 3 and the problem exists both with the old and
the current BBDB.

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

2011-02-11 Thread Roland Winkler
On Fri Feb 11 2011 Stefan Monnier wrote:
 Indeed, we have a problem here, and I think that part of the problem is
 on the side of bbdb-complete-name's behavior: it should include the name
 (with quotes) along with the email address so that it is actually
 a completion rather than a lookup.
 
 Of course, that won't fix it all, since the kind of completion it would
 then offer would still not be prefix completion, so you'd have to make
 sure you use something like `substring' in completion-styles (and that
 was not available in Emacs-23).

I am really not sure how BBDB email completeion could be squeezed
into the usual emacs completion styles. Say, we are talking about
the email address

   Joe Smith f...@bar.org

Now the idea is that typing foo would give you the above line.

Also, this command implements the concept of cycling, which is yet
more orthogonal to usual completion:
If Joe Smith also has the email sm...@baz.com and you apply this
command to the above (already expanded) email address, you can cycle
through all (properly expanded) email addresses of Joe Smith.

On the other hand, I am not sure whether it's worth the effort to
try to use more sophisticated high-level functions for this problem.
(Maybe my problem is that I do not know the latest GNU Emacs
completion goodies I am missing without these high-level functions.)

In any case, currently the most complicated part of
bbdb-complete-mail calculates possible completions. But inserting
them requires just three lines:

   (let ((completion-base-position (list beg end)))
 (with-output-to-temp-buffer *Completions*
   (display-completion-list dwim-completions)))

which is already based on some more recent code for performing
completions.

Cheers,

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

2011-02-11 Thread Roland Winkler
On Fri Feb 11 2011 Stefan Monnier wrote:
 Joe Smith f...@bar.org
 
  Now the idea is that typing foo would give you the above line.
 
 `substring' completion does that since `foo' is a substring of the
 above string.

Fine!

  Also, this command implements the concept of cycling, which is yet
  more orthogonal to usual completion:
 
 Welcome to completion-cycle-threshold.

Here I am stuck! Certainly I cannot claim that I understood
completion-cycle-threshold which seems to be unknown to my current
emacs 23.2.93. More importantly, my problem is that BBDB cycling
refers to different email addresses for one record. So in that case
different completions might not have any common substring. So any
generic completion algorithm needs to communicate to BBDB whether it
wants to perform completion based on a common substring or based on
cycling.

I guess it's fair to say that within bbdb-complete-mail (that you
can look at) the smaller part of the code tries to figure out what
type of completion is requested. But the larger part then generates
the appropriate completion table (where the elements need to be
calculated based on the content of the database).

 To tell you the truth, the infrastructure might have some missing
 elements, but I'm interested in addressing those issues. 

bbdb-complete-mail is certainly one of the more intransparent pieces
of code in BBDB. If this can be changed, I'll definitely appreciate
it!

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

2011-02-10 Thread Stefan Monnier
 Currently bbdb-complete-mail (the new name of bbdb-complete-name)
 really has no well-defined return values whatsoever. Would it help
 if it returned non-nil whenever it had done something?

Yes, that's generally the expected behavior of completion functions.

 Would this be the right thing??

Since BBDB3 only works on Emacsā‰„23, its completion could use
completion-at-point-functions and/or completion-in-region.


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

2011-02-10 Thread Stefan Monnier
 In any event, a simple t after (run-hooks 'bbdb-complete-mail-hook)
 does the trick, but it probably needs to be changed in some other
 places.

Note also that I've already installed a hack in message.el (at least in
Emacs's trunk) that checks that the buffer really was not modified
before trusting a nil return value from bbdb, to work around
the problem.


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

2011-02-06 Thread Antoine Levitt
Hi, thanks for looking into it!
06/02/11 17:45, Roland Winkler
 On Fri Feb 4 2011 Antoine Levitt wrote:
 I've got an issue with the bbdb-complete-name function. 

 It seems you are using BBDB 2.xx.  Recently BBDB has been upgraded
 significantly.  You might want to try BBDB 3 which is avaiable at
 http://cvs.savannah.gnu.org/viewvc/bbdb/?root=bbdb
 To check it out, use
 cvs -d:pserver:anonym...@cvs.sv.gnu.org:/sources/bbdb co bbdb

Ah, thanks! I tried using the sourceforge CVS, but it was down. Anyway,
I just updated to latest CVS (bbdb-version: BBDB version 3.02 ($Date:
2011/01/16 18:03:33 $)), and the problem is still the same.


 When using another completion in message mode, such as
 
 (setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
 nil)))
 
 , a successful BBDB completion also triggers the dabbrev-expand
 completion.

 I am not sure I understand your problem.  (I am not using
 message-mode myself.)

The way message, as insinuated by bbdb, works, is that it calls bbdb
first, and then if the return value is nil, calls
message-tab-body-function : see message-tab and message-expand-name.

Therefore, message depends on the return value of
bbdb-complete-name. Without going into the details of message, simply
type Bo and eval (bbdb-complete-name) in a buffer. If it completes to
a single name, it returns nil, which is not the behaviour relied upon by
message (and possibly other MUAs).

Antoine

--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
___
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

2011-02-06 Thread Roland Winkler
On Sun Feb 6 2011 Antoine Levitt wrote:
  When using another completion in message mode, such as
  
  (setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
  nil)))
  
  , a successful BBDB completion also triggers the dabbrev-expand
  completion.
 
  I am not sure I understand your problem.  (I am not using
  message-mode myself.)
 
 The way message, as insinuated by bbdb, works, is that it calls bbdb
 first, and then if the return value is nil, calls
 message-tab-body-function : see message-tab and message-expand-name.
 
 Therefore, message depends on the return value of
 bbdb-complete-name. Without going into the details of message, simply
 type Bo and eval (bbdb-complete-name) in a buffer. If it completes to
 a single name, it returns nil, which is not the behaviour relied upon by
 message (and possibly other MUAs).

I see! It seems we have here another example that other code has
evolved, but BBDB is still behaving in some kind of old-fashioned way.

Currently bbdb-complete-mail (the new name of bbdb-complete-name)
really has no well-defined return values whatsoever. Would it help
if it returned non-nil whenever it had done something?  Would this
be the right thing??

Possibly, we should continue this discussion on some other list,

Roland

--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/


bbdb-complete-name return value

2011-02-04 Thread Antoine Levitt
Hi,

I've got an issue with the bbdb-complete-name function. When using
another completion in message mode, such as 

(setq message-tab-body-function (lambda () (interactive) (dabbrev-expand
nil)))

, a successful BBDB completion also triggers the dabbrev-expand
completion.

Suppose I've got Bob as only contact beginning with Bo. When I type Bo
TAB in a To: header, Bob is completed, but I also get the dabbrev-expand
(sometimes inserting garbage when I have a SMTP trace buffer open). I
traced it to bbdb's return value in bbdb-complete-name:

;; call the exact-completion hook
(run-hooks 'bbdb-complete-name-hooks)))

I'm not entirely sure what the return value should be in all
circumstances, but in the one described above it should be t, so that
message doesn't try to complete.

Antoine


--
The modern datacenter depends on network connectivity to access resources
and provide services. The best practices for maximizing a physical server's
connectivity to a physical network are well understood - see how these
rules translate into the virtual world? 
http://p.sf.net/sfu/oracle-sfdevnlfb
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/