Bug 467911 - bbdb-display-layout ignored when set to multiline
bbdb-display-layout ignored when set to multiline
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: emacs-bbdb (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jonathan Underwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-21 13:09 EDT by Joe Bayes
Modified: 2008-11-22 11:49 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-12 22:35:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
A cut-down version of my .emacs, which exhibits the offending behavior (1.91 KB, application/octet-stream)
2008-10-23 14:21 EDT, Joe Bayes
no flags Details
Cut-down version of my .vm (6.04 KB, application/octet-stream)
2008-10-23 14:26 EDT, Joe Bayes
no flags Details

  None (edit)
Description Joe Bayes 2008-10-21 13:09:24 EDT
Description of problem:
In bbdb.el, the variable bbdb-display-layout is set to multiline. According to the documentation, this means that records should display in multiline format. But when I start vm and select a message, the records are displayed in single-line format. 

Version-Release number of selected component (if applicable):
emacs-bbdb-2.35-9.20080928cvs.fc9.noarch

How reproducible:
always

Steps to Reproduce:
1.Set up bbdb to work with vm. 
2.Start vm, select a message

  
Actual results:
Records are displayed in multi-line format

Expected results:
records are displayed in single-line format

Additional info:
Also, it seems that bbdb is now noticing *every* email address in the message, not just the sender. This is a change from the previous package. This is a problem for several reasons. 

First, when I am named in the To: field, this means that my own info is displayed in the *bbdb* buffer. This produces clutter; I am rarely interested in my own bbdb entry. 

Second, people I correspond with often have nicknames for each other that are not in widespread use. For example, my friend might send a mail to me and to his wife. The To: line might look like this:

To: Joe Bayes <jbayes@bar.com>, Wifey <julia@foo.com>

bbdb will notice the second address, and ask me if I want to add "Wifey" as an alternate name for julia@foo.com. Every. Single. Time. Eventually, my bbdb will contain every single pet name of every single one of my friends. This is bloated, and creates clutter. (I don't even want to *think* about what will happen if two of my friends both call their wives "Wifey".)

Can we please have a variable setting that will tell bbdb to go back to the old way of doing things, where just the sender of a message was noticed by bbdb?

I realize I'm sort of sneaking two or three bugs into one bug report here. If you like, I can file them separately.
Comment 1 Jonathan Underwood 2008-10-23 09:46:36 EDT
As a general comment, note that this new package is the first time that the bbdb-vm.el(c) file has been properly packaged allowing full integration of vm and bbdb - in previous packages this was not being included due to a packaging bug. Some of what you're seeing is as a result of that, I think, and are features rather than bugs.

It would be helpful to post your setup as well, i.e the relevant parts of the .emacs and .vm files (obfuscate any usernames and passwords, obviously).

(In reply to comment #0)
> Actual results:
> Records are displayed in multi-line format
> 
> Expected results:
> records are displayed in single-line format

OK, will look into this, this does seem like a bug.

> 
> Additional info:
> Also, it seems that bbdb is now noticing *every* email address in the message,
> not just the sender. This is a change from the previous package. This is a
> problem for several reasons. 
> 
> First, when I am named in the To: field, this means that my own info is
> displayed in the *bbdb* buffer. This produces clutter; I am rarely interested
> in my own bbdb entry. 
> 

Have you set bbdb-user-mail-names correctly?

> Second, people I correspond with often have nicknames for each other that are
> not in widespread use. For example, my friend might send a mail to me and to
> his wife. The To: line might look like this:
> 
> To: Joe Bayes <jbayes@bar.com>, Wifey <julia@foo.com>
> 
> bbdb will notice the second address, and ask me if I want to add "Wifey" as an
> alternate name for julia@foo.com. Every. Single. Time. Eventually, my bbdb will
> contain every single pet name of every single one of my friends. This is
> bloated, and creates clutter. (I don't even want to *think* about what will
> happen if two of my friends both call their wives "Wifey".)
> 

Please see the variable bbdb-use-alternate-names


> Can we please have a variable setting that will tell bbdb to go back to the old
> way of doing things, where just the sender of a message was noticed by bbdb?
> 
> I realize I'm sort of sneaking two or three bugs into one bug report here. If
> you like, I can file them separately.

No need, we can tackle them all here.
Comment 2 Jonathan Underwood 2008-10-23 10:04:41 EDT
(In reply to comment #0)
> Can we please have a variable setting that will tell bbdb to go back to the old
> way of doing things, where just the sender of a message was noticed by bbdb?

Please see:

bbdb-get-addresses-headers is a variable defined in `bbdb-autoloads.el'.
Its value is 
((authors "From" "Resent-From" "Reply-To")
 (recipients "Resent-To" "Resent-CC" "To" "CC" "BCC"))



Documentation:
*List of headers to search for senders and recipients email addresses.
The headers are grouped into two classes, the authors and the senders headers.

You can customize this variable.


Seems fine to me, but maybe you've customized it?
Comment 3 Jonathan Underwood 2008-10-23 10:07:20 EDT
(In reply to comment #0)
> Description of problem:
> In bbdb.el, the variable bbdb-display-layout is set to multiline. According to
> the documentation, this means that records should display in multiline format.
> But when I start vm and select a message, the records are displayed in
> single-line format. 
> 
> Version-Release number of selected component (if applicable):
> emacs-bbdb-2.35-9.20080928cvs.fc9.noarch
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1.Set up bbdb to work with vm. 
> 2.Start vm, select a message
> 
> 
> Actual results:
> Records are displayed in multi-line format
> 
> Expected results:
> records are displayed in single-line format
> 


Please see:
bbdb-display-layout is a variable defined in `bbdb.el'.
Its value is multi-line


Documentation:
*The default display layout.

You can customize this variable.

[back]


So, the default is multi-line. You need to set this variable (or the accompanying alist) appropriately. 

So, this seems like it's not a bug to me.
Comment 4 Joe Bayes 2008-10-23 14:15:22 EDT
>> Actual results:
>> Records are displayed in multi-line format
>> 
>> Expected results:
>> records are displayed in single-line format
>
>OK, will look into this, this does seem like a bug.

First off, I apologize profusely, I got that exactly backwards. 

What I meant to write was, when bbdb-display-layout is left as the default multi-line, I'm still getting a single-line display. For example:

Paul  		818 (Home), 818 (Cell); foo@bar.com
JLC - Them 		818 (Home); bar@baz.com
Teresa Lynn Johnson 	foo@hotmail.com
...etc

But: (cut 'n' paste)

bbdb-display-layout is a variable defined in `bbdb.el'.
Its value is multi-line

>Have you set bbdb-user-mail-names correctly?

No, I was using bbdb-extract-address-component-ignore-regexp to accomplish the effect, which used to work but now doesn't. (It's in my .emacs, attached.) It was nil, though, so it should have defaulted to user-login-name, which is jbayes, so it should have matched and worked anyways. 

In any case, bbdb-user-mail-names says that, if matched, "the BBDB record for the To: line will be shown instead of the one for the From: line." I'm not sure what field it's matching on, but I assume it's the From: field; but in any case, even when there is a match in the From: field, my entry still comes up in the *BBDB* buffer. 

And in any case, I realize this is a little pedantic, but I don't want bbdb to just not display my address; I want it to ignore it entirely. But I will be happy if we can get it to just not display. 

>Please see the variable bbdb-use-alternate-names

Hmm. That documentation is a little confusing; it says that if bbdb-use-alternate-names is t, then it when it notices a name change it will ask if I want both names to map to the same record. It doesn't say what bbdb does when it's nil (whether it ignores the new name, or silently adds it to the database); the behavior seems to be the same (to ask) whether it's set to t or nil as far as I can tell. (That behavior being, every time my friend sends me and his wife an email, bbdb tries to add the name "Wifey" to the database. Every. Single. Email. I don't really care whether it's adding it silently (cluttering up the database), or prompting me each time (wasting my time telling it "no"); both behaviors are highly annoying. But I still want bbdb to snarf information from the From: line, because that is usually accurate, and changes are rare.)

But I think I was unclear: the problem here is that, while From: fields are usually accurate, addresses in the To: field are quite often inaccurate and/or strange. The only sane way to deal with this situation is to treat all data in the To: field as "tainted", and not add it to the database. (Name<->email mappings are especially tainted, due to people using pet names.) 

I checked out bbdb-get-addresses-headers. I can get bbdb to exhibit something approximating the behavior I want, by changing it to:

((authors "From" "Resent-From" "Reply-To")
 (recipients ))

Essentially, I'm telling bbdb that there are no recipients to any of my messages...which works, but it's klugey. The elegant solution is to let me tell bbdb to not snarf from the recipients, only the authors. (The only reason I mention this is that I can see somebody using this variable in the future to do something other than snarf addresses. If I hide the recipients, then whatever new behavior they have added won't work.) 

The value of bbdb-get-addresses-headers hasn't changed since 2.35-8, so clearly it was one of the other changes that caused the behavior change; in 2.35-8, recipients' addresses were not snarfed.
Comment 5 Joe Bayes 2008-10-23 14:21:12 EDT
Created attachment 321324 [details]
A cut-down version of my .emacs, which exhibits the offending behavior
Comment 6 Joe Bayes 2008-10-23 14:26:13 EDT
Created attachment 321325 [details]
Cut-down version of my .vm
Comment 7 Jonathan Underwood 2008-10-23 14:47:27 EDT
I haven't had time to look carefully at this (about to leave for home), and your files, but have you checked the variable:

 bbdb-quiet-about-name-mismatches

    If this is false (the default), then BBDB will prompt you when it notices a name change, that is, when the "real name" in a message doesn't correspond to a record already in the database with the same network address. As in, "John Smith <jqs@frob.com>" versus "John Q. Smith <jqs@frob.com>". If this is true, then you will not be asked if you want to change it (and it will not be changed.) If a number then it is the number of seconds to sit-for while displaying the name mismatch.
Comment 9 Joe Bayes 2008-10-23 15:18:30 EDT
> bbdb-quiet-about-name-mismatches

Yeah, I suppose that's another way of handling it. It will do for now. 

Though I feel like we're kluging around the root of the problem. bbdb has
clearly differentiated between senders and recipients in the past (else why
have 2 lines in bbdb-get-addresses-headers), and doing so is clearly useful. So
if we can restore the behavior from the previous rpm, then many of these
problems would simply go away (or at least become so trivial that I won't be
motivated to file bug reports, which is pretty much the same thing). 

I'll take another look at the code, but I kind of feel like I'm in over my head
there.
Comment 10 Jonathan Underwood 2008-10-23 15:35:56 EDT
Yes, I see your point, but restoring the behaviour of the previous rpm actually is reverting to unintended incorrect behaviour in some sense, since bbdb-vm.elc wasn't previously installed (that's a bug).  I'm trying to work out which of the issues is actually a bug and which corresponds to a change in defaults caused by the installation of bbdb-vm.el
Comment 11 Jonathan Underwood 2008-11-06 19:23:56 EST
Hi Joe, I'm trying to work out which of these issues remains unresolved. 

It seems to me that all of the issues except one are fixed by correctly setting variables that arise from bbdb-vm.el[c] having not been installed in previous packages.

The one remaining issue seems to be that when bbdb-display-layout is left as it's default value (multiline) you're still seeing single line display of contact information. 

Is this a correct summary of the current situation?
Comment 12 Joe Bayes 2008-11-06 20:23:42 EST
Issue #1, that bbdb-display-layout=multiline produces single-line display, is unresolved.

Issue #2, that bbdb still displays my own entry when I am named in the To: line, is also unresolved. 

Issue #3, that bbdb still pays any attention at all to people in the To: line, is unresolved. (bbdb used to ignore these people entirely, which is just fine. The Right Thing To Do is probably to display their record if it's already there, but not modify the database by default, and allow the user to modify this behavior. But recording this information, and not allowing the user to selectively turn off this recording, is definitely the wrong thing to do).

Issue #4, that bbdb is quiet about name mismatches, is not resolved, but it is significantly less annoying. bbdb now displays 
  name mismatch: "foo" changed to "bar"
in the minibuffer, which it shouldn't do, but it doesn't interrupt my typing or demand user interaction. It also doesn't actually make any change in the .bbdb, which is the correct behavior.

Finally, issue #5, which I mentioned in comment #4, is that bbdb-user-mail-names does not default to (user-login-name) like the docs say it does. Instead it defaults to nil. (You can test this with emacs -q, then run bbdb, so this last issue has nothing to do with my personal configuration files.)

In addition to what I posted earlier, my .emacs now contains:
(setq bbdb-user-mail-names "jbayes@foo.com|jbayes@bar.edu|jbayes@baz.com")
(setq bbdb-use-alternate-names nil)
(setq bbdb-quiet-about-name-mismatches t)
Comment 13 Joe Bayes 2008-11-06 20:51:07 EST
To clarify, the reason I consider issue 2 unresolved for two reasons. First, when my address is in the TO line, I still see both my entry and the sender's entry in the BBDB buffer. This actually has nothing to do with bbdb-user-mail-names: that variable addresses how bbdb behaves when my address is in the FROM line. And second, when I have a message from me but not to me in my mailbox, bbdb still displays my record. This would be correct behavior if bbdb-user-mail-names were unset, but it's not.

And I realize that, unlike the other issues, issue 3 is neither contrary to the documentation nor blatant wrongness; it's merely really annoying. 

And the change in issue 4 from unresolved to sorta-resolved is because I set bbdb-quiet-about-name-mismatches, but even as documented it doesn't give me the behavior I want, and even though it behaves as documented, it lies about doing so. 

I believe that the solution to issue 5 is changing 
  (defcustom bbdb-user-mail-names nil
to
  (defcustom bbdb-user-mail-names (user-login-name)
in bbdb.el.
Comment 14 Jonathan Underwood 2008-11-08 09:25:25 EST
Ok, thanks for clarifying. Am working on a fix.
Comment 15 Fedora Update System 2008-11-09 08:38:24 EST
emacs-bbdb-2.35-1.fc8 has been submitted as an update for Fedora 8.
http://admin.fedoraproject.org/updates/emacs-bbdb-2.35-1.fc8
Comment 16 Fedora Update System 2008-11-09 08:39:29 EST
emacs-bbdb-2.35-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/emacs-bbdb-2.35-1.fc9
Comment 17 Fedora Update System 2008-11-09 08:40:19 EST
emacs-bbdb-2.35-1.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/emacs-bbdb-2.35-1.fc10
Comment 18 Jonathan Underwood 2008-11-09 08:42:52 EST
OK, I have reverted to the 2.35 release and patched it to install
bbdb-vm.el(c). Can you try this package, hopefully we should be back to where
we were before moving to the CVS head.

http://koji.fedoraproject.org/koji/buildinfo?buildID=68942
Comment 19 Joe Bayes 2008-11-10 02:33:43 EST
Yes, this works as it used to. All issues appear to be resolved. Thanks!
Comment 20 Jonathan Underwood 2008-11-10 05:12:13 EST
Thanks for your help with this Joe.
Comment 21 Fedora Update System 2008-11-11 21:52:13 EST
emacs-bbdb-2.35-1.fc8 has been pushed to the Fedora 8 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update emacs-bbdb'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-9527
Comment 22 Fedora Update System 2008-11-11 21:56:28 EST
emacs-bbdb-2.35-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update emacs-bbdb'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-9572
Comment 23 Fedora Update System 2008-11-12 22:35:02 EST
emacs-bbdb-2.35-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 24 Fedora Update System 2008-11-12 22:36:36 EST
emacs-bbdb-2.35-1.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 25 Fedora Update System 2008-11-22 11:49:01 EST
emacs-bbdb-2.35-1.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.