From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#4748: 23.1; least recently used window - is it? Date: Mon, 19 Oct 2009 09:36:07 +0200 Message-ID: <4ADC16E7.9010406@gmx.at> References: <4D3E3BC7322D4F79988F82996F46CE28@us.oracle.com> <4ADAECF8.7020200@gmx.at> <361C5607E07445959296A72FA999D368@us.oracle.com> <4ADB5223.4070007@gmx.at> Reply-To: martin rudalics , 4748@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255938479 18989 80.91.229.12 (19 Oct 2009 07:47:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 19 Oct 2009 07:47:59 +0000 (UTC) Cc: 4748@emacsbugs.donarmstrong.com To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 19 09:47:48 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Mzmy3-0007bV-CQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2009 09:47:48 +0200 Original-Received: from localhost ([127.0.0.1]:53857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzmy2-00017Q-VQ for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Oct 2009 03:47:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzmxc-0000yT-5Z for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2009 03:47:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MzmxX-0000xk-Sr for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2009 03:47:19 -0400 Original-Received: from [199.232.76.173] (port=46583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MzmxX-0000xg-OB for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2009 03:47:15 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:46383) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MzmxW-0005Bn-Ud for bug-gnu-emacs@gnu.org; Mon, 19 Oct 2009 03:47:15 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9J7lCJL021894; Mon, 19 Oct 2009 00:47:13 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9J7jGnu021681; Mon, 19 Oct 2009 00:45:16 -0700 Resent-Date: Mon, 19 Oct 2009 00:45:16 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: martin rudalics Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Mon, 19 Oct 2009 07:45:15 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4748 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4748-submit@emacsbugs.donarmstrong.com id=B4748.125593777720527 (code B ref 4748); Mon, 19 Oct 2009 07:45:15 +0000 Original-Received: (at 4748) by emacsbugs.donarmstrong.com; 19 Oct 2009 07:36:17 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with SMTP id n9J7aFS5020524 for <4748@emacsbugs.donarmstrong.com>; Mon, 19 Oct 2009 00:36:16 -0700 Original-Received: (qmail invoked by alias); 19 Oct 2009 07:36:09 -0000 Original-Received: from 62-47-42-63.adsl.highway.telekom.at (EHLO [62.47.42.63]) [62.47.42.63] by mail.gmx.net (mp034) with SMTP; 19 Oct 2009 09:36:09 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX184bW1+nHY45aqusgUXfLZVqdT2IDUmupU3RVHpZp gBvYNozm/9YWNG User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: X-Y-GMX-Trusted: 0 X-FuHaFi: 0.57 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Mon, 19 Oct 2009 03:47:19 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:32094 Archived-At: >> (let ((owin (selected-window))) >> (dolist (window (window-list)) >> (unless (eq window owin) >> (select-window window))) >> (get-lru-window)) > > That doesn't work either. For the same reason: `get-lru-window' will never > return certain windows. But it correctly sets the LRU window internally without looping. >> ((or (window-minibuffer-p) (eq (window-dedicated-p) t)) >> (pop-to-buffer buffer-or-name nil norecord)) > > (I'm curious: Why not call `pop-to-buffer' if the window is dedicated or a > minibuffer? What's the reason for that conditional?) Why "Why not" ... ? > If you feel that your version of `switch-to-buffer' makes it respect the > use-other-frame variables but otherwise have the same behavior as the current > `switch-to-buffer', then why don't you install it? > > But do you in fact claim that? If not, I don't see it as a solution to the > question. My version tried to be faithful to the one written in C. >> > `switch-to-buffer', which Stefan says repeatedly (and it >> > sounds right to me) should not be used in Lisp code (i.e. >> > should be used pretty much only interactively), does not >> > respect `special-display-regexps', >> > `special-display-buffer-names', or `pop-up-frames'. >> >> Because it wouldn't make much sense to respect these ;-) > > Huh? Why not? Why shouldn't it use the current window (as now) except when those > variables say not to (a la `switch-to-buffer-other-window' and `pop-to-buffer')? Presently a `not-this-window' argument to `display-buffer' overrides these variables. Any `same-window' argument would override them too. > IOW, have it do just what you claim it already does for dedicated windows. Just > as a dedicated window says "don't use me", so the use-other-frame variables also > say "don't use me". You say that we listen to the former - but we unfortunately > still do not listen to the latter. The idea of `switch-to-buffer' is to switch to a buffer in the selected window. This won't change ever. The only thing we can (and probably should) change is whether an application like bookmarks does call `switch-to-buffer' in the first place. >> We'd have to look at each of these cases to tell whether they can use >> `pop-to-buffer' directly. > > They cannot, by definition, if we intend to keep the current behavior of using > the same window (except when the use-other-frame vars say not to) and having the > same `quit-window' behavior. If using the same window is intentional (and I think in the case of `view-buffer' this is at least discussable) it will have to use the same window. > The problem is not just looking at each occurrence individually. The problem is > how to get the intended behavior (current window unless frame vars say > otherwise; same `quit-window' behavior). Nevertheless we have to look at each occurrence individually. >> I can't tell. Obviously `same-window-buffer-names' and friends >> implicitly provide the same service. > > How so? If you have a solution to the question I raised, please post it, by all > means. By default `same-window-buffer-names' has `display-buffer' emulate the behavior of `switch-to-buffer' for buffers like *shell* or *mail*. I don't know whether bookmark buffers would fit that category as well. Buffers handled by `view-buffer' certainly won't. >> If and when we enhance `display-buffer' with a same-window argument >> `switch-to-buffer' could become obsolete (for Elisp calls). OTOH this >> might lead programmers to call `display-buffer' with the same-window >> argument in these and other cases. > > Is that a discussion topic for emacs-devel? If you're proposing such a change to > `display-buffer', then it should be discussed there. Such a change shouldn't > "just happen". It's discussed in the "dired-pop-to-buffer in wrong place" thread. >> Does `quit-window' behave differently wrt whether >> `switch-to-buffer' was called or `pop-to-buffer'? > > Try it. I gave the recipe. Use the code I sent that uses `pop-to-buffer' and > compare, using the C-x 2 C-x 3 situation, with different buffers and with the > same buffer in all 3 windows. What do you want me to try? Replace the `switch-to-buffer' call in `quit-window' with `pop-to-buffer'? That would be dead wrong. >> > The above code loops forever in some cases (e.g. C-x 2 C-x >> > 3; put 3 diff buffers in the windows; then the small, >> > right-hand window will never be used by >> > `pop-to-buffer'. That is, this will not work: >> > >> > (cond ((one-window-p) ; This part works. >> > (pop-to-buffer (get-buffer-create "*foo*")) >> > (delete-other-windows)) >> > (t ; This part works except for some windows. >> > (let ((owin (selected-window))) >> > (while (not (eq (get-lru-window) owin)) >> > (other-window 1))) >> > (pop-to-buffer (get-buffer-create "*foo*")))) >> > >> > (You'll recommend comparing with the root window, instead >> > of calling `one-window-p', but that doesn't change the >> > point in question.) >> >> You shouldn't use `other-window' because it doesn't bury the window as >> you expect. Loop over `window-list' instead. > > Please show me what you mean. You can see what I'm trying to do. How to do it? I do _not_ know what you're trying. If you want to reconstruct how `display-buffer' finds its window without using the underlying C primitives then I can only refer you to Stefan's remark on this: You won't be able to do that. > And please explain why `other-window' should not be used - in what way doesn't > it "bury the window as you expect"? Is it also a dwim function? What about > `next-window' - would that work better? You said you got an endless loop here. Obviously that happens because you use `other-window'. >> I still don't understand why and how you want to control the >> setting of the LRU window in practice. > > I don't really care about the lru window. I was trying to get `pop-to-buffer' to > use the selected window (whatever that window is, no exceptions). Above you wanted `pop-to-buffer' follow user customizations. Unless you settle on either - respect user customizations thus getting a behavior different from `switch-to-buffer', or - implement the `switch-to-buffer' behavior thus not respecting user customizations, this won't get us anywhere. > And also to > keep the same `quit-window' behavior that you get when you use > `switch-to-buffer'. Can you please describe in a few words what a "`quit-window' behavior" is? >> > And if you have the same buffer in more than one window, >> > then such "solutions" also behave differently from >> > `switch-to-buffer' when you use `quit-window'. E.g. >> > C-x 2 C-x 3, without using 3 different buffers, etc. >> >> In what sense do they behave differently? > > When you quit the window, you get a different buffer from what you get when you > use `switch-to-buffer'. ... use `switch-to-buffer' _where_? In the code of `quit-window'? > At least that's what I saw. Try the examples I mentioned > - C-x 2 C-x 3. Do you mean that the `other-buffer' call in `switch-to-buffer' when called by `quit-window' chooses another buffer to display? Are you sure you have set all NORECORD arguments correctly? > The point is that if you use `switch-to-buffer' and then quit the window, the > buffer that is displayed is different than what you see if you use > `pop-to-buffer' (successfully forcing it to use the same window, at least for > most windows) and then you quit the window. Try the examples I gave, and see for > yourself. > > Again, personally I don't care about preserving the same behavior that > `switch-to-buffer' gives (wrt using the same window and quitting). But I imagine > that someone does, or we wouldn't still be using it. Do you mean the examples where you call `other-window'? `other-window' calls `select-window' which calls record_buffer so you obviously get a completely stochastic behavior. >> > is that such behavior is apparently a common use case. >> > If replacing `switch-to-buffer' in, say, `view-buffer', >> > we would presumably want to keep the same behavior as now >> > for users who do not use `special-display-*' and `pop-up-frames'. >> >> So try to experiment with the following: Have `display-buffer' >> interpret a 'same-window value for the NOT-THIS-WINDOW argument >> and replace calls like (switch-to-buffer buffer) with >> (pop-to-buffer buffer 'same-window). > > I don't have any time for that, sorry. Then I won't be able to help you at the moment. martin