pop-to-buffer and friends new behavior or bug?

pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

Hi,
with last emacs from trunk:

split window 

do e.g C-h f defun

now i have 3 windows


-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

Thierry Volpiatto <thierry.volpiatto@gmail.com> writes:

> Hi,
> with last emacs from trunk:
>
> split window 
>
> do e.g C-h f defun
>
> now i have 3 windows

Modification of display-buffer-alist seem to fix the problem for
pop-to-buffer but not for code that use switch-to-buffer-other-window.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 >> with last emacs from trunk:
 >>
 >> split window
 >>
 >> do e.g C-h f defun
 >>
 >> now i have 3 windows

Due to a downright silly default value of `display-buffer-alist', sorry.
(Actually, the default value is what I used personally to test all sorts
of strange cases.)  I'll fix that tomorrow.

 > Modification of display-buffer-alist seem to fix the problem for
 > pop-to-buffer

That's great.  I didn't expect anyone even to try to understand this.
Which values did you use?

 > but not for code that use switch-to-buffer-other-window.

That's bad.  `switch-to-buffer-other-window' does call

(pop-to-buffer buffer 'other-window norecord)

so something in the processing of the 'other-window argument must have
gone wrong.  Please tell me your values and I shall try to repeat it.

Thanks for reporting, martin

Re: pop-to-buffer and friends new behavior or bug?

[David Koppelman]

On a similar note, I find annoying the new behavior of deleting a frame
when its last buffer (whatever that means) is deleted, at least for
frames which I explicitly open. Is that intended? Perhaps there should
be some kind of option for this (more convenient than advicing
window-deletable-p).

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> with last emacs from trunk:
>>>
>>> split window
>>>
>>> do e.g C-h f defun
>>>
>>> now i have 3 windows
>
> Due to a downright silly default value of `display-buffer-alist', sorry.
> (Actually, the default value is what I used personally to test all sorts
> of strange cases.)  I'll fix that tomorrow.
>
>> Modification of display-buffer-alist seem to fix the problem for
>> pop-to-buffer
>
> That's great.  I didn't expect anyone even to try to understand this.
I tried but didn't understand all yet ;-)
More explanation welcome.

> Which values did you use?

#+BEGIN_SRC lisp
(when (boundp 'display-buffer-alist)
  (setq display-buffer-alist
        '((((regexp . ".*"))
           reuse-window
           (reuse-window nil same visible)
           pop-up-window
           (pop-up-window
            (fit-window-to-buffer)
            (nil))
           reuse-window
           (reuse-window other other nil)
           (reuse-window-even-sizes . nil)))))

#+END_SRC

>> but not for code that use switch-to-buffer-other-window.
>
> That's bad.  `switch-to-buffer-other-window' does call
>
> (pop-to-buffer buffer 'other-window norecord)
>
> so something in the processing of the 'other-window argument must have
> gone wrong.  Please tell me your values and I shall try to repeat it.
>
> Thanks for reporting, martin

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > (when (boundp 'display-buffer-alist)
 >   (setq display-buffer-alist
 >         '((((regexp . ".*"))
 >            reuse-window
 >            (reuse-window nil same visible)
 >            pop-up-window
 >            (pop-up-window
 >             (fit-window-to-buffer)
 >             (nil))
 >            reuse-window
 >            (reuse-window other other nil)
 >            (reuse-window-even-sizes . nil)))))

This "works" only because there's a bug when processing the
`pop-up-window' specifier whose cdr must be a list of (window . side)
pairs.  I suppose you didn't use the customization interface :-(

So what happens is that because of this bug Emacs doesn't pop up a new
window but reuses an existing one.

 >>> but not for code that use switch-to-buffer-other-window.

I checked in a fix which should handle `switch-to-buffer-other-window'
as well.  Please have another look.

Thanks, martin

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > On a similar note, I find annoying the new behavior of deleting a frame
 > when its last buffer (whatever that means) is deleted, at least for
 > frames which I explicitly open. Is that intended?

Yes.

 > Perhaps there should
 > be some kind of option for this (more convenient than advicing
 > window-deletable-p).

I'll write that tomorrow.  The option will allow to

- never delete a frame in such a case,

- delete the frame only if it has been created by one of the
   `display-buffer' family of functions,

- always delete the frame even if it was created by C-x 5 2 (the present
   default).

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

Hi Martin,

martin rudalics <rudalics@gmx.at> writes:

>>> with last emacs from trunk:
>>>
>>> split window
>>>
>>> do e.g C-h f defun
>>>
>>> now i have 3 windows
>
> Due to a downright silly default value of `display-buffer-alist', sorry.
> (Actually, the default value is what I used personally to test all sorts
> of strange cases.)  I'll fix that tomorrow.
>
>> Modification of display-buffer-alist seem to fix the problem for
>> pop-to-buffer
>
> That's great.  I didn't expect anyone even to try to understand this.
> Which values did you use?

That is ok now, except it doesn't honor 
(setq split-width-threshold nil)
The window is splitted | (vertically?)

>> but not for code that use switch-to-buffer-other-window.
>
> That's bad.  `switch-to-buffer-other-window' does call
>
> (pop-to-buffer buffer 'other-window norecord)
`switch-to-buffer-other-window' still not working as expected.
Maybe you can try ioccur.el and see what happen.
It is working as expected as it is, you will have to uncomment the line
with switch-to-buffer...(L964) and comment the next one
pop-to-buffer...(L965) In the function `ioccur'.

You can get it here
hg clone http://mercurial.intuxication.org/hg/ioccur
cd ../ioccur
hg update -C development

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > That is ok now, except it doesn't honor
 > (setq split-width-threshold nil)
 > The window is splitted | (vertically?)

I checked in a fix for this.  With `display-buffer-alist' you can
inhibit splitting by adding a (pop-up-window-min-width . 1.0) specifier
(this is currently overriden when `split-width-threshold' is nil).

 >>> but not for code that use switch-to-buffer-other-window.
 >> That's bad.  `switch-to-buffer-other-window' does call
 >>
 >> (pop-to-buffer buffer 'other-window norecord)
 > `switch-to-buffer-other-window' still not working as expected.
 > Maybe you can try ioccur.el and see what happen.
 > It is working as expected as it is, you will have to uncomment the line
 > with switch-to-buffer...(L964) and comment the next one
 > pop-to-buffer...(L965) In the function `ioccur'.

If the effect was that you got a new frame instead, then this should be
fixed now.  There was a silly bug inverting the value of `pop-up-frames'
in `display-buffer-normalize-specifiers-1'.  If you see another effect,
please tell me which one.

Thanks, martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> That is ok now, except it doesn't honor
>> (setq split-width-threshold nil)
>> The window is splitted | (vertically?)
>
> I checked in a fix for this.  With `display-buffer-alist' you can
> inhibit splitting by adding a (pop-up-window-min-width . 1.0) specifier
> (this is currently overriden when `split-width-threshold' is nil).

Seem fixed now.

>>>> but not for code that use switch-to-buffer-other-window.
>>> That's bad.  `switch-to-buffer-other-window' does call
>>>
>>> (pop-to-buffer buffer 'other-window norecord)
>> `switch-to-buffer-other-window' still not working as expected.
>> Maybe you can try ioccur.el and see what happen.
>> It is working as expected as it is, you will have to uncomment the line
>> with switch-to-buffer...(L964) and comment the next one
>> pop-to-buffer...(L965) In the function `ioccur'.
>
> If the effect was that you got a new frame instead, then this should be
> fixed now.  There was a silly bug inverting the value of `pop-up-frames'
> in `display-buffer-normalize-specifiers-1'.  If you see another effect,
> please tell me which one.

Yes, it seem fixed too.

Thanks for your work.;-)

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

In anything, i can browse image directory without quitting anything.
This function `anything-find-files-persistent-action', use
`display-buffer' and then display image with image-dired function in
this buffer.This doesn't work anymore (display-buffer).
The image is displayed ...in minibuffer!!!
However it is working fine if i use `switch-to-buffer'.
I have commited a fix at:
http://repo.or.cz/w/anything-config.git
where you can read the code.

To reproduce with old code (the one that use display-buffer):
M-x anything-find-files
navigate to an image directory.
hit C-u C-z on an image filename
You will have the image displayed in minibuffer and it is impossible to
quit.

The last code is working fine.

martin rudalics <rudalics@gmx.at> writes:

>> That is ok now, except it doesn't honor
>> (setq split-width-threshold nil)
>> The window is splitted | (vertically?)
>
> I checked in a fix for this.  With `display-buffer-alist' you can
> inhibit splitting by adding a (pop-up-window-min-width . 1.0) specifier
> (this is currently overriden when `split-width-threshold' is nil).
>
>>>> but not for code that use switch-to-buffer-other-window.
>>> That's bad.  `switch-to-buffer-other-window' does call
>>>
>>> (pop-to-buffer buffer 'other-window norecord)
>> `switch-to-buffer-other-window' still not working as expected.
>> Maybe you can try ioccur.el and see what happen.
>> It is working as expected as it is, you will have to uncomment the line
>> with switch-to-buffer...(L964) and comment the next one
>> pop-to-buffer...(L965) In the function `ioccur'.
>
> If the effect was that you got a new frame instead, then this should be
> fixed now.  There was a silly bug inverting the value of `pop-up-frames'
> in `display-buffer-normalize-specifiers-1'.  If you see another effect,
> please tell me which one.
>
> Thanks, martin

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > In anything, i can browse image directory without quitting anything.
 > This function `anything-find-files-persistent-action', use
 > `display-buffer' and then display image with image-dired function in
 > this buffer.This doesn't work anymore (display-buffer).
 > The image is displayed ...in minibuffer!!!
 > However it is working fine if i use `switch-to-buffer'.
 > I have commited a fix at:
 > http://repo.or.cz/w/anything-config.git
 > where you can read the code.
 >
 > To reproduce with old code (the one that use display-buffer):
 > M-x anything-find-files
 > navigate to an image directory.
 > hit C-u C-z on an image filename
 > You will have the image displayed in minibuffer and it is impossible to
 > quit.
 >
 > The last code is working fine.

Sorry, I build without image support so I won't be able to test this.
Could you please try to edebug `display-buffer-reuse-window' and find
out whether the line

	(when (and (not (window-minibuffer-p window))

is processed in this particular case?  If `window' is a minibuffer
window, it should not be added to the set of candidate windows denoted
by the variable `windows'.

Thank you, martin


PS: Basically, there would be already a bug if `window' were a minibuffer
window in the test above because my first list is constructed by calling

(window-list-1 nil 'nomini method-frame)

where the 'nomini argument should filter out minibuffer windows.

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > On a similar note, I find annoying the new behavior of deleting a frame
 > when its last buffer (whatever that means) is deleted, at least for
 > frames which I explicitly open.

Are you sure this happens?  I looked into this and it seems to me that
deleting a frame created via C-x 5 2 could not be deleted by deleting
the "last buffer".

 > Is that intended? Perhaps there should
 > be some kind of option for this (more convenient than advicing
 > window-deletable-p).

I have now installed an option called `frame-auto-delete'.  Please try
whether it helps you to get rid of the advice.  (If you set this to t
then you can now even delete frames created via C-x 5 2 ;-) )

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

[-- Attachment #1: Type: text/plain, Size: 2657 bytes --]

martin rudalics <rudalics@gmx.at> writes:

>> In anything, i can browse image directory without quitting anything.
>> This function `anything-find-files-persistent-action', use
>> `display-buffer' and then display image with image-dired function in
>> this buffer.This doesn't work anymore (display-buffer).
>> The image is displayed ...in minibuffer!!!
>> However it is working fine if i use `switch-to-buffer'.
>> I have commited a fix at:
>> http://repo.or.cz/w/anything-config.git
>> where you can read the code.
>>
>> To reproduce with old code (the one that use display-buffer):
>> M-x anything-find-files
>> navigate to an image directory.
>> hit C-u C-z on an image filename
>> You will have the image displayed in minibuffer and it is impossible to
>> quit.
>>
>> The last code is working fine.
>
> Sorry, I build without image support so I won't be able to test this.
> Could you please try to edebug `display-buffer-reuse-window' and find
> out whether the line
>
> 	(when (and (not (window-minibuffer-p window))
>
> is processed in this particular case?  If `window' is a minibuffer
> window, it should not be added to the set of candidate windows denoted
> by the variable `windows'.
This line return t for both windows, but the whole when clause return
nil for one of the 2 windows.
I will try to debug more (hard because i have to quit emacs at each
time) later.

Here the relevant piece of code:

--8<---------------cut here---------------start------------->8---
;; An image file and it is the second hit on C-z,
;; show the file in `image-dired'.
((string-match (image-file-name-regexp) candidate)
 (when (buffer-live-p image-dired-display-image-buffer)
   (kill-buffer image-dired-display-image-buffer))
 (image-dired-display-image candidate)
 (message nil)
 ;(switch-to-buffer image-dired-display-image-buffer) <<<< [1] 
 (display-buffer image-dired-display-image-buffer)    <<<< [2]
 (with-current-buffer image-dired-display-image-buffer
   (let ((exif-data (anything-ff-exif-data candidate)))
     (image-dired-update-property 'help-echo exif-data))))

--8<---------------cut here---------------end--------------->8---
See Capture-Emacs.png for [2]
See Capture-Emacs-1.png for [1]

Where [1] is what is expected.

After [2] C-g do nothing and i must quit Emacs.

> Thank you, martin
>
>
> PS: Basically, there would be already a bug if `window' were a minibuffer
> window in the test above because my first list is constructed by calling
>
> (window-list-1 nil 'nomini method-frame)
>
> where the 'nomini argument should filter out minibuffer windows.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

[-- Attachment #2: Capture-Emacs-1.png --]
[-- Type: image/png, Size: 1736960 bytes --]

[-- Attachment #3: Capture-Emacs.png --]
[-- Type: image/png, Size: 1535016 bytes --]

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> In anything, i can browse image directory without quitting anything.
>> This function `anything-find-files-persistent-action', use
>> `display-buffer' and then display image with image-dired function in
>> this buffer.This doesn't work anymore (display-buffer).
>> The image is displayed ...in minibuffer!!!
>> However it is working fine if i use `switch-to-buffer'.
>> I have commited a fix at:
>> http://repo.or.cz/w/anything-config.git
>> where you can read the code.
>>
>> To reproduce with old code (the one that use display-buffer):
>> M-x anything-find-files
>> navigate to an image directory.
>> hit C-u C-z on an image filename
>> You will have the image displayed in minibuffer and it is impossible to
>> quit.
>>
>> The last code is working fine.
>
> Sorry, I build without image support so I won't be able to test this.
You don't need to have image support enabled, because the same bug is in
anything-M-x:
Try f5-a M-x and on any command hit C-z.
The expected (old) behavior is to have describe-function displayed in
other window.
Now it is displayed in minibuffer!

> Could you please try to edebug `display-buffer-reuse-window' and find
> out whether the line
>
> 	(when (and (not (window-minibuffer-p window))
>
> is processed in this particular case?  If `window' is a minibuffer
> window, it should not be added to the set of candidate windows denoted
> by the variable `windows'.
>
> Thank you, martin
>
>
> PS: Basically, there would be already a bug if `window' were a minibuffer
> window in the test above because my first list is constructed by calling
>
> (window-list-1 nil 'nomini method-frame)
>
> where the 'nomini argument should filter out minibuffer windows.
>
>

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > You don't need to have image support enabled, because the same bug is in
 > anything-M-x:

What is anything-M-x?

 > Try f5-a M-x and on any command hit C-z.

What is f5-a?

 > The expected (old) behavior is to have describe-function displayed in
 > other window.
 > Now it is displayed in minibuffer!

Please try to give me a recipe starting with emacs -Q which I can
follow.

Thanks, martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> You don't need to have image support enabled, because the same bug is in
>> anything-M-x:
>
> What is anything-M-x?
>
>> Try f5-a M-x and on any command hit C-z.
>
> What is f5-a?
>
>> The expected (old) behavior is to have describe-function displayed in
>> other window.
>> Now it is displayed in minibuffer!
>
> Please try to give me a recipe starting with emacs -Q which I can
> follow.

1) git clone git://repo.or.cz/anything-config.git
2) emacs -Q
3) (add-to-list 'load-path "path/to/anything/directory")
4) (require 'anything-config)
5) f5-a M-x
6) start writing a command in the prompt
6) C-z

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[David Koppelman]

> Are you sure this happens?  I looked into this and it seems to me that
> deleting a frame created via C-x 5 2 could not be deleted by deleting
> the "last buffer".

I usually open a new frame with C-x 5 b or C-x 5 f, so maybe that's the
problem. I'll set the new frame-auto-delete to nil, but maybe it would
be a good idea to not have the kill buffer commands also kill frames,
except under very limited circumstances.

Thanks for adding the option, setting it to nil works.

martin rudalics <rudalics@gmx.at> writes:

>> On a similar note, I find annoying the new behavior of deleting a frame
>> when its last buffer (whatever that means) is deleted, at least for
>> frames which I explicitly open.
>
> Are you sure this happens?  I looked into this and it seems to me that
> deleting a frame created via C-x 5 2 could not be deleted by deleting
> the "last buffer".
>
>> Is that intended? Perhaps there should
>> be some kind of option for this (more convenient than advicing
>> window-deletable-p).
>
> I have now installed an option called `frame-auto-delete'.  Please try
> whether it helps you to get rid of the advice.  (If you set this to t
> then you can now even delete frames created via C-x 5 2 ;-) )
>
> martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

Hi Martin,

martin rudalics <rudalics@gmx.at> writes:

>> You don't need to have image support enabled, because the same bug is in
>> anything-M-x:
>
> What is anything-M-x?
>
>> Try f5-a M-x and on any command hit C-z.
>
> What is f5-a?
>
>> The expected (old) behavior is to have describe-function displayed in
>> other window.
>> Now it is displayed in minibuffer!
>
> Please try to give me a recipe starting with emacs -Q which I can
> follow.
I have fixed my problem in anything.el using this:

--8<---------------cut here---------------start------------->8---
[...]
    (when (boundp 'display-buffer-alist)
      (setq not-this-window '((reuse-window same other nil)
                              (pop-up-window (other)))))
    (display-buffer buf not-this-window)))
--8<---------------cut here---------------end--------------->8---

It is working fine like this, but i would like to know if that is
correct.

Thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > I have fixed my problem in anything.el using this:
 >
 > --8<---------------cut here---------------start------------->8---
 > [...]
 >     (when (boundp 'display-buffer-alist)
 >       (setq not-this-window '((reuse-window same other nil)
 >                               (pop-up-window (other)))))
 >     (display-buffer buf not-this-window)))
 > --8<---------------cut here---------------end--------------->8---
 >
 > It is working fine like this, but i would like to know if that is
 > correct.

I suppose it's reusing another window now because the reuse-window
specifier is correct - try the selected window if it shows another
buffer.  The pop-up-window specifier wants a list of window . side
conses like (pop-up-window (largest . below) (selected .right)) to split
the largest window with the new window below or the selected window with
the new window on the right.

But please don't fix this before I found the cause of the bug.  Having a
sample where it tries to use the minibuffer window is important for me.
(Unfortunately, I haven't git installed so I first have to get this from
somewhere else.  Or you send me the files exposing the bug via private
mail?)

Thanks, martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> I have fixed my problem in anything.el using this:
>>
>> --8<---------------cut here---------------start------------->8---
>> [...]
>>     (when (boundp 'display-buffer-alist)
>>       (setq not-this-window '((reuse-window same other nil)
>>                               (pop-up-window (other)))))
>>     (display-buffer buf not-this-window)))
>> --8<---------------cut here---------------end--------------->8---
>>
>> It is working fine like this, but i would like to know if that is
>> correct.
>
> I suppose it's reusing another window now because the reuse-window
> specifier is correct - try the selected window if it shows another
> buffer.  The pop-up-window specifier wants a list of window . side
> conses like (pop-up-window (largest . below) (selected .right)) to split
> the largest window with the new window below or the selected window with
> the new window on the right.
Ok, so the (pop-up-window (other)) is incorrect (or incomplete) and
maybe unuseful in this case.

> But please don't fix this before I found the cause of the bug.  Having a
> sample where it tries to use the minibuffer window is important for me.
> (Unfortunately, I haven't git installed so I first have to get this from
> somewhere else.  Or you send me the files exposing the bug via private
> mail?)
No problem if you have not git, just download the tarball here:
http://repo.or.cz/w/anything-config.git

Last revision have bug fixed with the code above, just comment it out,
or download the revision just before to have the bug:

--8<---------------cut here---------------start------------->8---
author	Thierry Volpiatto <thierry.volpiatto@gmail.com>	
Mon, 20 Jun 2011 20:28:20 +0000 (22:28 +0200)
committer	Thierry Volpiatto <thierry.volpiatto@gmail.com>	
Mon, 20 Jun 2011 20:28:20 +0000 (22:28 +0200)
commit	fe786b9d1cbcb8431468f309ed7fa5f5676d47b0
tree	21694f5a4f95654dac54d7e580dab1ca4b40fcd4
parent	9e7236e34f98ba1a5ad8b6414f7f45df70bc531e
--8<---------------cut here---------------end--------------->8---

The relevant code is in anything.el starting at line 3123 at:
;; (@* "Utility: Persistent Action")

and more exactly in `anything-persistent-action-display-buffer'.

Follow the recipe i sent in precedent mail.
To see what is expected use the fixed code.

You will find a pdf file in the ../doc directory, even if it's not
up to date, it can help you if you are not familiar with anything.

Thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > The relevant code is in anything.el starting at line 3123 at:
 > ;; (@* "Utility: Persistent Action")
 >
 > and more exactly in `anything-persistent-action-display-buffer'.

I tried to look at anything but it is much too complicated for me.

Besides, evaluating anything-config.el gives the bug

  global-set-key: Key sequence <f5> a starts with non-prefix key <f5>

Anyway: In the buggy version what is the value of NOT-THIS-WINDOW in the
call to `display-buffer' in `anything-persistent-action-display-buffer'?
And what is the selected window at that time?  The minibuffer window?

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> The relevant code is in anything.el starting at line 3123 at:
>> ;; (@* "Utility: Persistent Action")
>>
>> and more exactly in `anything-persistent-action-display-buffer'.
>
> I tried to look at anything but it is much too complicated for me.
It is less complicated than display-buffer-alist ;-)

> Besides, evaluating anything-config.el gives the bug
What is evaluating? C-M-x?
Please use load or require.

>  global-set-key: Key sequence <f5> a starts with non-prefix key <f5>

Please follow instruction i gave you in precedent mail, or 
_load_ FIRST anything.el and SECOND anything-config.el.

I have no error here with emacs -Q.

Here a minimal config for anything with emacs -Q:

(add-to-list 'load-path "~/elisp/anything") ; Change path to anything
(require 'anything-config)

> Anyway: In the buggy version what is the value of NOT-THIS-WINDOW in the
> call to `display-buffer' in
> `anything-persistent-action-display-buffer'?
I think it is not called in old code, at least here, maybe it is used in
other libraries.

> And what is the selected window at that time?
It is the window containing the anything-buffer.

You can check with this:
--8<---------------cut here---------------start------------->8---
(defun anything-select-persistent-action-window ()
  (select-window (get-buffer-window (anything-buffer-get)))
  (message "%S" (get-buffer-window (anything-buffer-get)))
  (select-window
   (setq minibuffer-scroll-window
     (anything-persistent-action-display-window)))
   (message "%S" (anything-persistent-action-display-window)))
--8<---------------cut here---------------end--------------->8---


+---------------------------+
|                           |
| anything-current-buffer   |
| (the window to display    |
|  persistent action result)| In this case the result of
+---------------------------+ describe-function.
|                           |
| anything-buffer           |
| (selected window)         |
|                           |
+---------------------------+
| minibuffer                |
+---------------------------+


> The minibuffer window?
no

NOTE:
In fixed version using only:

--8<---------------cut here---------------start------------->8---
(when (boundp 'display-buffer-alist)
  (setq not-this-window '(reuse-window same other nil)))
(display-buffer buf not-this-window)))
--8<---------------cut here---------------end--------------->8---

is enough. (no pop-up-window entry)


--
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

OK.  I managed to reproduce the behavior now.  It's due to a silly bug
in `display-buffer-pop-up-window'.  I'll install a fix soon.

 > +---------------------------+
 > |                           |
 > | anything-current-buffer   |
 > | (the window to display    |
 > |  persistent action result)| In this case the result of
 > +---------------------------+ describe-function.
 > |                           |
 > | anything-buffer           |
 > | (selected window)         |
 > |                           |
 > +---------------------------+
 > | minibuffer                |
 > +---------------------------+

I can't follow you here.  When I invoke C-z the window showing the
anything-current-buffer becomess the selected window.  That seems
intentional - because *Help* is by default shown in the selected window
and `describe-function' shows the result in that buffer.  If a user
changes that setting, this mechanism won't work as intended.

Or am I missing something?

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

> OK.  I managed to reproduce the behavior now.  It's due to a silly bug
> in `display-buffer-pop-up-window'.  I'll install a fix soon.
Nice thanks.

>> +---------------------------+
>> |                           |
>> | anything-current-buffer   |
>> | (the window to display    |
>> |  persistent action result)| In this case the result of
>> +---------------------------+ describe-function.
>> |                           |
>> | anything-buffer           |
>> | (selected window)         |
>> |                           |
>> +---------------------------+
>> | minibuffer                |
>> +---------------------------+
>
> I can't follow you here.  When I invoke C-z the window showing the
> anything-current-buffer becomess the selected window.  That seems
> intentional - because *Help* is by default shown in the selected window
> and `describe-function' shows the result in that buffer.
Yes it is intentional.
  
> If a user changes that setting, this mechanism won't work as intended.
Which different setting a user could use here for example?
pop-up-frames?
(i mean for displaying help buffer.)

> Or am I missing something?
No you're right here, maybe my explanation was bad.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 >> If a user changes that setting, this mechanism won't work as intended.
 > Which different setting a user could use here for example?
 > pop-up-frames?

The user could have made the window dedicated in which case
`same-window' won't work.  You should use a fallback in that case.

Anyway, testing things with anything.el revealed three bugs in my code
so this was a very fruitful experience for me.  Please try your original
code with the latest sources and tell me whether it works.

Thanks, martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> If a user changes that setting, this mechanism won't work as intended.
>> Which different setting a user could use here for example?
>> pop-up-frames?
>
> The user could have made the window dedicated in which case
> `same-window' won't work.  You should use a fallback in that case.
Ok thanks, i will try to fix this.

> Anyway, testing things with anything.el revealed three bugs in my code
> so this was a very fruitful experience for me.  Please try your original
> code with the latest sources and tell me whether it works.
I will.

Here another one:

Use C-t while in anything.
=> byte-code: Attempt to split minibuffer window

Here relevant code in anything.el:

#+BEGIN_SRC lisp
;; Original function that fail
(defun anything-toggle-resplit-window ()
  "Toggle resplit anything window, vertically or horizontally."
  (interactive)
  (with-anything-window
    (let ((before-height (window-height)))
      (delete-window)
      (set-window-buffer
       (select-window (if (= (window-height) before-height)
                          (split-window-vertically)
                        (split-window-horizontally)))
       anything-buffer))))

;; A quick fix that fix it (not fully tested, just write quickly now)
(defun anything-toggle-resplit-window ()
  "Toggle resplit anything window, vertically or horizontally."
  (interactive)
  (let (before-height) 
    (with-anything-window
      (setq before-height (window-height))
      (delete-window))
    (with-selected-window (get-buffer-window anything-current-buffer)
      (set-window-buffer
       (select-window (if (= (window-height) before-height)
                          (split-window-vertically)
                          (split-window-horizontally)))
       anything-buffer))))

#+END_SRC

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

> Use C-t while in anything.
> => byte-code: Attempt to split minibuffer window
> 
> Here relevant code in anything.el:

Is this with the most recent code from trunk?

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>> Use C-t while in anything.
>> => byte-code: Attempt to split minibuffer window
>>
>> Here relevant code in anything.el:
>
> Is this with the most recent code from trunk?
I didn't already push the second version of function i sent you.
So the first version (buggy one) is the last in the trunk.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

>> Is this with the most recent code from trunk?
> I didn't already push the second version of function i sent you.
> So the first version (buggy one) is the last in the trunk.

I meant "did you try with the latest version of the Emacs 24 trunk"?

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> Is this with the most recent code from trunk?
>> I didn't already push the second version of function i sent you.
>> So the first version (buggy one) is the last in the trunk.
>
> I meant "did you try with the latest version of the Emacs 24 trunk"?
No, i will try tonight, i didn't have the time today.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

>>> Is this with the most recent code from trunk?
>> I didn't already push the second version of function i sent you.
>> So the first version (buggy one) is the last in the trunk.
>
> I meant "did you try with the latest version of the Emacs 24 trunk"?
I have just installed last version.

anything-toggle-resplit-window: Last version from trunk, so the one that
was not working is now working perfectly.

anything-persistent-action-display-buffer:
I tried with the old version that was not working, and now it work
perfectly as before. (the version before the fix i did)

Many thanks.

Also it seem count-windows count the minibuffer-window even whithout
mini arg, when the minibuffer is active.
You can check with adding a message in an anything function:


--8<---------------cut here---------------start------------->8---
(defun anything-toggle-resplit-window ()
  "Toggle resplit anything window, vertically or horizontally."
  (interactive)
  (message "Window number: %s" (count-windows))
  (with-anything-window
    (let ((before-height (window-height)))
      (delete-window)
      (set-window-buffer
       (select-window (if (= (window-height) before-height)
                          (split-window-vertically)
                        (split-window-horizontally)))
       anything-buffer))))
--8<---------------cut here---------------end--------------->8---

But maybe it is the behavior of count-windows, i don't know.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: pop-to-buffer and friends new behavior or bug?

[martin rudalics]

 > Also it seem count-windows count the minibuffer-window even whithout
 > mini arg, when the minibuffer is active.

 From the doc-string of `walk-windows':

   MINIBUF t means include the minibuffer window even if the
   minibuffer is not active.  MINIBUF nil or omitted means include
   the minibuffer window only if the minibuffer is active.  Any
   other value means do not include the minibuffer window even if
   the minibuffer is active.

So if the MINIBUF argument is nil or omitted, the minibuffer window is
counted if the minibuffer is active.

martin

Re: pop-to-buffer and friends new behavior or bug?

[Thierry Volpiatto]

martin rudalics <rudalics@gmx.at> writes:

> So if the MINIBUF argument is nil or omitted, the minibuffer window is
> counted if the minibuffer is active.
Ok, good to know, thanks.

-- 
A+ Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997