[BBDB] ChangeLog 2012-07-09

2012-07-09 Thread Roland Winkler 
On Sun Jul 8 2012 Roland Winkler wrote:
 When I looked at the code once more, I realized an annoying
 inconsistency:
 
 bbdb-mua-edit-field and friends do not use the default user
 variable bbdb-mua-update-interactive-p used by commands such as
 bbdb-mua-display-records. Currently they simply ignore the optional
 arg update-p so that the mua-specific fallbacks such as
 bbdb/gnus-update-records-p are used by these commands.
 
 I consider this a suboptimal solution. It would be more consistent
 if these commands obeyed bbdb-mua-update-interactive-p just like the
 other MUA commands. Yet the problem lies in the usage of the prefix
 arg:
 
 Commands such as bbdb-mua-display-records can use their prefix arg for
 the two alternatives implemented by bbdb-mua-update-interactive-p.
 Commands such as bbdb-mua-edit-field use their prefix arg for something
 else.
 
 So I can think of two possible strategies:
 
 (1) bbdb-mua-edit-field and friends use the no-prefix value of
 bbdb-mua-update-interactive-p.
 
 (2) All MUA commands use a separate prefix key for the two
 alternatives provided by bbdb-mua-update-interactive-p. This
 would be similar to the prefix keys `*' and `+' in the *BBDB*
 buffer. Then the different MUA commands can use the normal
 prefix arg for whatever they like without a conflict with
 bbdb-mua-update-interactive-p.
 
 Here a problem is finding a suitable key: The *BBDB* buffer has
 its own keymap so that there are many keys available for such a
 feature. In the MUA buffers, the key bindings for the MUA
 commands can use only those keys that are not used for anything
 else.
 
 Thoughts? Comments? Other suggestions?

I decided that strategy (2) would be nice, but hard to implement.
In the meanwhile strategy (1) is at least a meaningful starting
point that is even mostly compatible with (2). So the patch below
implements (1). 

With the patch described below, all MUA commands now come with an
arg update-p that controls in the same way how they operate on a
message. Interactive calls of these commands always use the user
variable bbdb-mua-update-interactive-p. Overall this should make the
usage of the BBDB commands for MUAs yet more consistent.

(I still appreciate suggestions for a yet better scheme!)


2012-07-09  Roland Winkler  wink...@gnu.org
* lisp/bbdb-mua.el (bbdb-mua-annotate-sender)
(bbdb-mua-annotate-recipients, bbdb-mua-edit-field)
(bbdb-mua-edit-field-sender, bbdb-mua-edit-field-recipients): New arg
update-p.
(bbdb-mua-edit-field-interactive): Handle arg update-p.


BBDB is available at
http://savannah.nongnu.org/projects/bbdb/
To check it out, use
git clone git://git.savannah.nongnu.org/bbdb.git

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/

Re: nameless records

2012-07-09 Thread Roland Winkler 
On Sun Jul 8 2012 Sam Steingold wrote:
 When I receive a confirmation message from no-re...@foo.com,
 I create a record and copy into its notes the url and all the relevant
 information about the service I just registered for.
 Since bbdb creates a record with first name no-reply and last
 name ,

This should be the other way round: first name  and last name
no-reply. Why is it reversed for you?

 loading the file becomes very slow because bbdb pauses for a
 second to report that I have a dozen duplicates for webmaster,
 no-reply, bugzilla-daemon c c. I don't think it makes much
 sense to add first name/last name to such records.

It appears that binding bbdb-allow-duplicates to t is the easiest
solution here.

 It seems that treating the e-mail names just like AKAs is better.
 I.e., right now a record is assumed to already have name X if X matches
 either bbdb-record-name or one of bbdb-record-aka.
 
 Proposal: additionally, assume a record to already have name X if X
 matches one of

This is supposed to be relevant under which circumstances?
How is this supposed to address the issue you describe above?

If for whatever reason Joe Smith has the email address f...@bar.com 
I wouldn't like to have Joe's record match a search for name Foo.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
bbdb-info@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/