From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thierry Volpiatto Newsgroups: gmane.emacs.devel Subject: Re: pop-to-buffer and friends new behavior or bug? Date: Mon, 20 Jun 2011 10:29:15 +0200 Message-ID: <87aadckisk.fsf@gmail.com> References: <87zklhhcys.fsf@gmail.com> <87ei2tzg3o.fsf@gmail.com> <4DFA690A.20205@gmx.at> <87d3iccuqo.fsf@gmail.com> <4DFCCDE6.30007@gmx.at> <87boxu3oic.fsf@gmail.com> <4DFDF921.5090407@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1308558597 24287 80.91.229.12 (20 Jun 2011 08:29:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 20 Jun 2011 08:29:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 20 10:29:53 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QYZrk-0004zq-CW for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 10:29:52 +0200 Original-Received: from localhost ([::1]:48596 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYZrj-0001t6-3r for ged-emacs-devel@m.gmane.org; Mon, 20 Jun 2011 04:29:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:59478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYZrU-0001ss-BA for emacs-devel@gnu.org; Mon, 20 Jun 2011 04:29:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QYZrT-0000D3-1u for emacs-devel@gnu.org; Mon, 20 Jun 2011 04:29:36 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:47940) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QYZrS-0000Cy-NW for emacs-devel@gnu.org; Mon, 20 Jun 2011 04:29:35 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QYZrN-0004se-6c for emacs-devel@gnu.org; Mon, 20 Jun 2011 10:29:29 +0200 Original-Received: from 43.77.197.77.rev.sfr.net ([77.197.77.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Jun 2011 10:29:29 +0200 Original-Received: from thierry.volpiatto by 43.77.197.77.rev.sfr.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Jun 2011 10:29:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 54 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 43.77.197.77.rev.sfr.net User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:s7MvbFs+5ekOWOsuaRYQey4YOss= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140708 Archived-At: martin rudalics 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