On Sat Jan 15 2011 Stefan Monnier wrote:
> > 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... (A
> > 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
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 be
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 be
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(# 0)
> bbdb-pop-up-buffer(t nil)
> bbdb-display-records-internal((...) multi-line nil t nil)
> bbdb-display-records(
When I invoke M-x bbdb from my minibuffer-only frame, BBDB burps with
the above error. The Elisp backtrace is:
split-window(# 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-in
