headers
Roland Winkler | 6 Jan 2011 22:27
Picon

Re: [feature/bug] bbdb-update-records / search

On Mon Dec 27 2010 Philipp Haselwarter wrote:
> Hi,
> I'm trying to get bbdb3 working and I came across a (potential)
> bug. When I'm in the summary-buffer and I hit ':' to run
> `bbdb-mua-display-sender', I get an error.
> 
> The relevant code is in "bbdb-mua.el" at `bbdb-update-records' line 206:
> ,----
> |   (if (functionp update-p)                
> |       (setq update-p (funcall update-p))) 
> `----
> 
> If 'cl is loaded, `search' is a function, which gets called with no
> arguments here:

Thanks for reporting this! -- Up to now, I always considered name
clashes due to loading cl a more academic problem because I never
had to deal with real-world examples.

> ,----
> | search is a compiled Lisp function in `cl-seq.el'.
> | 
> | (search SEQ1 SEQ2 [KEYWORD VALUE]...)
> `----

... But here we are! This must fail.

Let me think about this. One solution would be to check first whether
the value of UPDATE-P is the symbol 'search, and only if it is not
the code could check whether UPDATE-P is callable.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Winkler | 7 Jan 2011 03:59
Picon

ChangeLog 2011-01-06

The new ChangeLog is attached below.

I fixed some autoload problems.

The name clash with the function `search' in cl-seq.el should now be
fixed.

> MUA-specific BBDB insinuation adds key bindings for BBDB _and_ it
> puts bbdb-mua-pop-up-bbdb-buffer into respective MUA hooks to feed
> BBDB. Yet if outgoing messages are used to feed BBDB (as in
> moy-bbdb) there is no need to have bbdb-mua-pop-up-bbdb-buffer
> also in the hook for incoming mail.

To make the BBDB initialization more flexible, I removed the code
from the BBDB insinuation functions that puts bbdb-mua-pop-up-bbdb-buffer
into the respective MUA hooks. Instead the new function
bbdb-mua-pop-up-init should be used.

The auto-notes stuff did not work well if BBDB hooks both into MUAs
for receiving mail as well as into agents for sending mail. Moy-bbdb
addressed this problem by duplicating a large part of the MUA
auto-notes stuff. I thought that this was an unsatisfactory solution.
So I ended up with a complete re-write of bbdb-auto-notes that uses
more flexible rules for configuring auto-notes. However, up to now I
have not figured out a situation for myself, where I really want to
permanently use these auto-notes. So maybe I am missing something
here, or the code could possibly be further improved. Suggestions
welcome.

Normally, it should no longer be necessary to use a prefix arg with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philipp Haselwarter | 14 Jan 2011 15:57
Picon
Picon

Usability of 3.02 - gnus, message

Hi again,
thanks for fixing the issue with 'search.
But as it stands, bbdb3 is not working very well for me:

a) when I'm in the summary buffer (gnus) and hit ':',
   `bbdb-mua-display-sender' gets called, now without error, but nothing
   happens.
   I have `bbdb-update-records-p' set to the 'query lambda form, also
   tried it with 'create, no different.
   Shouldn't I get queried if I want to add the entry to the db?
   Wasn't there even a setting that allowed to get queried for every
   mail I receive?

b) tab-completion for mail addresses seems broken.
   In message-mode, TAB is bound to `message-tab', which ends up looking
   for `bbdb-complete-name' (cf. `message-expand-name').
   This is unbound, so no bbdb completion happens.
   I'm not familiar with previous versions of bbdb, but I guess
   `bbdb-complete-name' used to be what `bbdb-complete-mail' is now?
   I don't know about the motivation for the renaming, but the problem
   can be resolved with a simple

--8<---------------cut here---------------start------------->8---
   (defalias 'bbdb-complete-name 'bbdb-complete-mail)
--8<---------------cut here---------------end--------------->8---

   As I don't know about previous usage of bbdb-complete-name, I'm not
   sure this is a sane solution (might introduce trouble elsewhere?)

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Stefan Monnier | 15 Jan 2011 03:13
Picon

(error "Attempt to split minibuffer window")

When I invoke M-x bbdb from my minibuffer-only frame, BBDB burps with
the above error.  The Elisp backtrace is:

  split-window(#<window 8 on  *Minibuf-0*> 0)
  bbdb-pop-up-buffer(t nil)
  bbdb-display-records-internal((...) multi-line nil t nil)
  bbdb-display-records((...) multi-line nil t)
  bbdb("" multi-line)
  call-interactively(bbdb t nil)
  execute-extended-command(nil)
  call-interactively(execute-extended-command nil nil)

This is with the CVS code from nongnu.org.

        Stefan

PS: BTW, I suggest the patch below to let users initialize BBDB in their
.emacs with a single `load' (i.e. without messing with load-path
themselves):

--- Makefile.~1.2.~	2010-12-15 01:24:53.000000000 -0500
+++ Makefile	2011-01-14 21:06:59.000000000 -0500
 <at>  <at>  -88,6 +88,7  <at>  <at> 
 bbdb-autoloads.el: $(DEPSRCS)
 	 <at> -$(RM) $ <at> ;
 	 <at> echo "(provide 'bbdb-autoloads)" > $ <at> ;
+	 <at> echo "(add-to-list 'load-path (or (file-name-directory load-file-name) (car load-path)))\n\n"
>> $ <at> ;
 	 <at> echo "" >> $ <at> ;
 	 <at> $(emacs) -batch -l autoload \
(Continue reading)

Permalink | Reply | 2 comments |
headers
Roland Winkler | 15 Jan 2011 14:28
Picon

Re: (error "Attempt to split minibuffer window")

On Fri Jan 14 2011 Stefan Monnier wrote:
> When I invoke M-x bbdb from my minibuffer-only frame, BBDB burps with
> the above error.  The Elisp backtrace is:
> 
>   split-window(#<window 8 on  *Minibuf-0*> 0)
>   bbdb-pop-up-buffer(t nil)
>   bbdb-display-records-internal((...) multi-line nil t nil)
>   bbdb-display-records((...) multi-line nil t)
>   bbdb("" multi-line)
>   call-interactively(bbdb t nil)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command nil nil)

No surprise! -- I've never used a minibuffer-only frame.  What kind
of behavior would you consider appropriate?  Use a new frame?
Probably this should be customizable... Are there other emacs
packages dealing with a similar problem that I can look at?

> PS: BTW, I suggest the patch below to let users initialize BBDB in their
> .emacs with a single `load' (i.e. without messing with load-path
> themselves):

Thanks! I have not yet looked into the Makefile more carefully.
There is probably more that should be cleaned up.

Roland

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Winkler | 15 Jan 2011 17:53
Picon

Re: (error "Attempt to split minibuffer window")

On Sat Jan 15 2011 Stefan Monnier wrote:
> > No surprise! -- I've never used a minibuffer-only frame.  What kind
> > of behavior would you consider appropriate?  Use a new frame?
> 
> Call display-buffer or pop-to-buffer (this has the major advantage of
> letting the user customize the resulting behavior via
> special-display-regexp).  There can probably be other circumstances
> where split-window fails (dedicated window, maybe, and unsplittable
> frames).  So better do it for all failure cases than only the ones you
> know about.

Thanks, I'll do that!

Roland

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
bbdb-info <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bbdb-info
BBDB Home Page: http://bbdb.sourceforge.net/
Permalink | Reply | 0 comments |
headers
Roland Winkler | 15 Jan 2011 19:30
Picon

Re: (error "Attempt to split minibuffer window")

On Fri Jan 14 2011 Stefan Monnier wrote:
> > No surprise! -- I've never used a minibuffer-only frame.  What kind
> > of behavior would you consider appropriate?  Use a new frame?
> 
> Call display-buffer or pop-to-buffer (this has the major advantage of
> letting the user customize the resulting behavior via
> special-display-regexp).  There can probably be other circumstances
> where split-window fails (dedicated window, maybe, and unsplittable
> frames).  So better do it for all failure cases than only the ones you
> know about.

I've looked at your suggestions more closely. 

The spirit of the current approach in BBDB for displaying buffers is
still the one which I guess was implemented years ago. I guess the
above makes more sense. Yet implementing this properly might break
again some backward compatibility... (And it might take a little
while since I need to understand better how something like
special-display-regexp is supposed to work.)

Oh well, this new BBDB is still in an alpha stage!

> PS: BTW, I suggest the patch below to let users initialize BBDB in their
> .emacs with a single `load' (i.e. without messing with load-path
> themselves):
> 
>  bbdb-autoloads.el: $(DEPSRCS)
>  	 <at> -$(RM) $ <at> ;
>  	 <at> echo "(provide 'bbdb-autoloads)" > $ <at> ;
> +	 <at> echo "(add-to-list 'load-path (or (file-name-directory
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland Winkler | 16 Jan 2011 00:15
Picon

ChangeLog 2011-01-15 (was: Usability of 3.02 - gnus, message)

On Fri Jan 14 2011 Philipp Haselwarter wrote:
> when I'm in the summary buffer (gnus) and hit ':',
> `bbdb-mua-display-sender' gets called, now without error, but
> nothing happens. 

The problem was that `bbdb-mua-update-records' needs a line

  (set-buffer gnus-article-buffer)

I added this. Yet I also realized something strange about the Gnus
*Article* buffers. The key ':' is not bound to
`bbdb-mua-display-sender' but to `gnus-article-read-summary-keys'
that provides an additional wrapper that restores the window
configuration. So calling `bbdb-mua-display-sender' becomes really
useless inside *Article* buffers.  It only works in the *Summary*
buffer.

-- Suggestions welcome (I do not know much about Gnus).

> b) tab-completion for mail addresses seems broken.
>    In message-mode, TAB is bound to `message-tab', which ends up looking
>    for `bbdb-complete-name' (cf. `message-expand-name').
>    This is unbound, so no bbdb completion happens.
>    I'm not familiar with previous versions of bbdb, but I guess
>    `bbdb-complete-name' used to be what `bbdb-complete-mail' is now?
>    I don't know about the motivation for the renaming, but the problem
>    can be resolved with a simple
>    
>    (defalias 'bbdb-complete-name 'bbdb-complete-mail)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Philipp Haselwarter | 16 Jan 2011 03:47
Picon
Picon

Re: ChangeLog 2011-01-15

"RW" == Roland Winkler <winkler <at> gnu.org> writes:
---8<---[snipped 10 lines]---8<---
RW> I added this. Yet I also realized something strange about the Gnus
RW> *Article* buffers. The key ':' is not bound to
RW> `bbdb-mua-display-sender' but to `gnus-article-read-summary-keys'
RW> that provides an additional wrapper that restores the window
RW> configuration. So calling `bbdb-mua-display-sender' becomes really
RW> useless inside *Article* buffers.  It only works in the *Summary*
RW> buffer.

RW> -- Suggestions welcome (I do not know much about Gnus).

As far as I can see ':' is unbound in the *Summary* buffer in gnus
v5.13 (emacs bzr) and nognus.
`bbdb-mua-display-sender' seems to _update_ the *BBDB* buffer even when
called from the summary, but fails to open the pop-up window.

>> b) tab-completion for mail addresses seems broken.  In message-mode,
---8<---[snipped 13 lines]---8<---

RW> So I used define-obsolete-function-alias instead.

works for me now, thanks!

---8<---[snipped 26 lines]---8<---

--

-- 
Philipp Haselwarter

------------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roland Winkler | 16 Jan 2011 04:04
Picon

Re: ChangeLog 2011-01-15

On Sun Jan 16 2011 Philipp Haselwarter wrote:
> "RW" == Roland Winkler <winkler <at> gnu.org> writes:
> ---8<---[snipped 10 lines]---8<---
> RW> I added this. Yet I also realized something strange about the Gnus
> RW> *Article* buffers. The key ':' is not bound to
> RW> `bbdb-mua-display-sender' but to `gnus-article-read-summary-keys'
> RW> that provides an additional wrapper that restores the window
> RW> configuration. So calling `bbdb-mua-display-sender' becomes really
> RW> useless inside *Article* buffers.  It only works in the *Summary*
> RW> buffer.
> 
> RW> -- Suggestions welcome (I do not know much about Gnus).
> 
> As far as I can see ':' is unbound in the *Summary* buffer in gnus
> v5.13 (emacs bzr) and nognus.
> `bbdb-mua-display-sender' seems to _update_ the *BBDB* buffer even when
> called from the summary, but fails to open the pop-up window.

That is strange. My observations refer to Gnus that comes with Emacs
23.2.90.1.

I discovered the `gnus-article-read-summary-keys' wrapper using
edebug. -- You can put something like (sit-for 10) at the end of
`bbdb-mua-display-sender'. For me, this shows that
`bbdb-mua-display-sender' gives exactly the expected behavior (a
BBDB window for the sender of the message). Yet this BBDB window
disappears after the execution of the command
`bbdb-mua-display-sender'. Note also that
`gnus-article-read-summary-keys' has an optional arg
not-restore-window which is probably needed here. Yet I don't know
(Continue reading)

Permalink | Reply | 0 comments |

Gmane