From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#13594: Planning Emacs-24.4 Date: Mon, 18 Nov 2013 19:31:18 -0500 Message-ID: References: <5289F003.5040708@gmx.at> <528A13DA.1030309@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1384821136 13515 80.91.229.3 (19 Nov 2013 00:32:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Nov 2013 00:32:16 +0000 (UTC) Cc: 13594@debbugs.gnu.org, Leo Liu To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 19 01:32:20 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ViZEq-0002M3-1q for geb-bug-gnu-emacs@m.gmane.org; Tue, 19 Nov 2013 01:32:20 +0100 Original-Received: from localhost ([::1]:46489 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViZEp-0003Tu-Hy for geb-bug-gnu-emacs@m.gmane.org; Mon, 18 Nov 2013 19:32:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViZEf-0003Sn-Oa for bug-gnu-emacs@gnu.org; Mon, 18 Nov 2013 19:32:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ViZEY-0002X7-Eu for bug-gnu-emacs@gnu.org; Mon, 18 Nov 2013 19:32:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ViZEY-0002Wd-Bb for bug-gnu-emacs@gnu.org; Mon, 18 Nov 2013 19:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ViZEX-00022u-Sd for bug-gnu-emacs@gnu.org; Mon, 18 Nov 2013 19:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 19 Nov 2013 00:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13594 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 13594-submit@debbugs.gnu.org id=B13594.13848210877820 (code B ref 13594); Tue, 19 Nov 2013 00:32:01 +0000 Original-Received: (at 13594) by debbugs.gnu.org; 19 Nov 2013 00:31:27 +0000 Original-Received: from localhost ([127.0.0.1]:60563 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViZDy-000224-JV for submit@debbugs.gnu.org; Mon, 18 Nov 2013 19:31:26 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:59309) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ViZDx-00021l-4S for 13594@debbugs.gnu.org; Mon, 18 Nov 2013 19:31:26 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFHO+KWN/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kLodwBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="38566096" Original-Received: from 206-248-165-141.dsl.teksavvy.com (HELO pastel.home) ([206.248.165.141]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Nov 2013 19:31:19 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id C1C8D60120; Mon, 18 Nov 2013 19:31:18 -0500 (EST) In-Reply-To: <528A13DA.1030309@gmx.at> (martin rudalics's message of "Mon, 18 Nov 2013 14:19:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:80746 Archived-At: >> t was just a value to stop display-buffer searching down the action >> list. this seems enough to manage display-buffer via >> display-buffer-alist or the like. > It is not. In which sense is it not? > Returning t when calling `display-buffer' without may-fail > set doesn't improve anything. Indeed, an FUNCTION that returns t when may-fail is not set is in error. But this has never happened so far, so I'm not sure it's terribly important to check it. > And if my-fail is set, we can return nil > because the caller is prepared for it. t is the return value of the FUNCTION. It can't be nil, since nil already means "try the next FUNCTION". `display-buffer' can then take this t return value and turn it into a nil. > And you still don't handle the case where a user doesn't want to see > the buffer in the first place. I think his code does handle it (by having the FUNCTION return t without displaying the buffer). > (1) Provide two actions designators may-fail and do-fail, say. What would `do-fail' mean? Is that a FUNCTION or an element of the ALIST? > (2) When may-fail is set and no window is found, return nil. We already do that (regardless of `may-fail', actually). But "no window is found" can pretty much never happen. > When may-fail is not set, return the most suitable window. If no window is found, there is no "most suitable window". > (3) When may-fail and do-fail are both set, break the > (while (and functions (not window)) > (setq window (funcall (car functions) buffer alist) > functions (cdr functions))) > loop in `display-buffer' (for example, by having the function called > return 'fail) and return nil. That sounds cumbersome, compared to the simple solution he uses now of stopping when FUNCTION returns t (which the code already does, by virtue of stopping as soon as FUNCTION returns non-nil). Stefan