From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#4748: 23.1; least recently used window - is it? Date: Sun, 18 Oct 2009 11:48:17 -0700 Message-ID: References: <4D3E3BC7322D4F79988F82996F46CE28@us.oracle.com> <4ADAECF8.7020200@gmx.at> <361C5607E07445959296A72FA999D368@us.oracle.com> <4ADB5223.4070007@gmx.at> Reply-To: Drew Adams , 4748@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1255892857 15908 80.91.229.12 (18 Oct 2009 19:07:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 18 Oct 2009 19:07:37 +0000 (UTC) Cc: 4748@emacsbugs.donarmstrong.com To: "'martin rudalics'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 18 21:07:28 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 1Mzb6F-0003ku-9d for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2009 21:07:27 +0200 Original-Received: from localhost ([127.0.0.1]:48573 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzb6E-00065a-LK for geb-bug-gnu-emacs@m.gmane.org; Sun, 18 Oct 2009 15:07:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzb6A-00065K-Bq for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 15:07:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzb64-00064k-Bt for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 15:07:20 -0400 Original-Received: from [199.232.76.173] (port=55039 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzb64-00064h-9i for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 15:07:16 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:50645) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mzb63-0005zr-Hc for bug-gnu-emacs@gnu.org; Sun, 18 Oct 2009 15:07:16 -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 n9IJ7ChW000897; Sun, 18 Oct 2009 12:07:12 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n9IIt7Vh030853; Sun, 18 Oct 2009 11:55:07 -0700 Resent-Date: Sun, 18 Oct 2009 11:55:07 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Sun, 18 Oct 2009 18:55:06 +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.125589178630081 (code B ref 4748); Sun, 18 Oct 2009 18:55:06 +0000 Original-Received: (at 4748) by emacsbugs.donarmstrong.com; 18 Oct 2009 18:49:46 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from rgminet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n9IInix6030073 for <4748@emacsbugs.donarmstrong.com>; Sun, 18 Oct 2009 11:49:45 -0700 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rgminet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9IInEXs008623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Oct 2009 18:49:15 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n9IGYIgL029082; Sun, 18 Oct 2009 18:50:40 GMT Original-Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 20467195311255891703; Sun, 18 Oct 2009 11:48:23 -0700 Original-Received: from dradamslap1 (/24.5.184.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Oct 2009 11:48:23 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4ADB5223.4070007@gmx.at> Thread-Index: AcpQGY8t9tLmWm7tQPyahWL5g0XqNAAAKa1Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4ADB633F.00F2:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Sun, 18 Oct 2009 15:07:20 -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:32070 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. > > Which means you cannot use `pop-up-buffer' in any > > reasonable way to get the window-selection behavior of > > `switch-to-buffer'. Or else please show me how. > > Maybe. My `switch-to-buffer' is in Elisp for quite some > time. It goes like ... > ((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?) 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. > > `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')? 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. > > And yet `switch-to-buffer' _is_ used in Lisp code, > > including in the Emacs sources. It is called from commonly > > used commands, such as `bookmark-bmenu-list' > > and `view-buffer'/`view-file' (which means, e.g., > > `view-emacs-news'). > > 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. 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). > > Presumably, there is a common use case there that should > > be respected: someone wants to substitute for the current > > buffer preferably in the same window, > > instead of opening a new window and moving focus there. > > Dunno if that's a reasonable use case - I never need that > > behavior myself, but it seems to be fairly common. > > 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. > > Assuming we should be able to meet that use case, what's > > the right replacement for `switch-to-buffer' for that case? > > 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". > > What code will do the same thing wrt which > > window gets used and which buffer will be put in place > > after using, say, `quit-window' in the newly displayed buffer? > > 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. > > 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? 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? > > Here's another attempt, which at least doesn't loop > > forever: Replace the `let' sexp above by this: > > > > (dotimes (i (1- (count-windows))) (other-window 1)) > > > > That suffers from more or less the same problem: the newly > > displayed buffer is never shown in the right-hand window - > > the full-width window is always used whenever the right-hand > > window is selected. (But of course this preference for > > full-width is inconsistent - the just-as-small left-hand > > window _is_ used to display the buffer. IOW, this dwim does > > not dwim.) > > > > [You cannot just use (other-window (1- (count-window)) > > instead of a loop, because that doesn't cycle the > > window-selection (lru) order.] > > 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). And also to keep the same `quit-window' behavior that you get when you use `switch-to-buffer'. > > 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'. At least that's what I saw. Try the examples I mentioned - C-x 2 C-x 3. > > 1. The reason for avoiding `switch-to-buffer' here, and > > using `pop-to-buffer' instead, is so that variables > > such as `special-display-*' and `pop-up-frames' > > will be respected. E.g., if `special-display-regexps' > > is ("[ ]?[*][^*]+[*]"), then *foo* will be opened in > > its own, special frame. > > Good. > > > 2. The reason for trying to simulate `switch-to-buffer's > > which-window-gets-used behavior and its `quit-window' behavior > > I still don't understand - what is `switch-to-buffer's `quit-window' > behavior? God only knows. I don't try to characterize any of the behavior in a meaningful way. It does what it does - why and how I do not know. 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. > > 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. But if that makes `pop-to-buffer' use the same window, and users are happy with it, then that's the way to go. However, that won't help with older Emacs versions, which is a concern I also have. IOW, even if the main concern (for me too) is to fix Emacs in this regard going forward, I would also like to know what code I can use in older versions to get a solution (act like `switch-to-buffer' except when the use-other-frame vars say to use another frame). Maybe the answer is that there is no such solution. But I'd like to know. > > Again, dunno about #2. Maybe we should just forget about > > that use case and replace `switch-to-buffer' willy nilly by > > `pop-to-buffer'/`display-buffer'? > > > > Or maybe we should redefine `switch-to-buffer' so that it > > respects the variables in question (and possibly other > > relevant variables, if any). IOW, make it use > > `display-buffer'. (Why doesn't it?) > > It does (if the selected window is dedicated). That's not a solution. `special-display-*' and `pop-up-frames' do not affect only dedicated windows. Have it respect _all_ such don't-use-this-window stuff, not just dedicated windows. > > Or (more likely) maybe I'm missing something, and there is > > already a reasonable way to get both (a) the > > `switch-to-buffer' behavior wrt window selection and > > `quit-window' and (b) the `display-buffer' behavior wrt > > the use-another-frame variables? > > > > In which case, please enlighten me. How should we replace > > `switch-to-buffer' in, say, `view-buffer' or > > `bookmark-bmenu-list' (or...)? > > First you have to enlighten me wrt the quit-window behavior. Just try it. I saw a difference, when you: (a) use `quit-window' after using `switch-to-buffer' versus (b) use `quit-window' after using `pop-to-buffer' in such a way that it reuses the same window (not possible for some windows, but possible for most - see the code I sent). The buffer that is displayed in the window after `quit-window' is not the same. If I'm wrong about that, fine - one less thing to worry about when trying to keep the current `switch-to-buffer' behavior (except when proscribed by use-other-frame vars). > >> > Currently, it doesn't seem easy to predict or control > >> > which window is used by things such as `pop-to-buffer' > >> > that try to use another window. Being able to set the > >> > so-called lruw that such functions use would > >> > make things a lot more straightforward. > >> > >> We can easily remove the FULL-WIDTH feature. But _who_ would be > >> responsible for "touching" windows in order to make them LRU? > > > > I would do it in my code - if it worked. > > But it's the _user_ who should touch the windows, not the application > programmer. Agreed. So show me how to do it without fiddling with lru. I tried that fiddling only to try to get `pop-to-buffer' to reuse the same window. The aim was to keep the `switch-to-buffer' behavior for people who do not use `special-display-*' or `pop-to-frames', but otherwise have the behavior that `pop-to-buffer' has when those vars are used. > > But the main question is posed above. Given the aim of, in > > effect, making `pop-to-buffer' use a particular window, I tried to > > somehow set a window to be the lru. But that doesn't work because > > of the full-width criterion. ... > > I was hoping that simply making a window be the least > > recently used one would cause `pop-to-buffer' to use that window. > > But things are apparently far from so simple. I'm hoping you or > > someone else (e.g. Stefan) has a simple solution that I've been blind to. > > Stefan has proposed to enhance the NOT-THIS-WINDOW argument of > `display-buffer' for this purpose and I'm all for it. I haven't seen such a proposal discussed in emacs-devel. What is the thread? And what is a solution for older Emacs versions (is there one)?