From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tom Gillespie Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fix display-buffer-use-some-window to honor reusable-frames Date: Tue, 31 Jan 2023 13:38:44 -0500 Message-ID: References: <834jsccepb.fsf@gnu.org> <30c3d810-ed96-a9bd-c622-1761a138515c@gmx.at> <115a6020-2b86-2653-844e-d19eb03cf62c@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26390"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org, larsi@gnus.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 31 19:39:57 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pMvXx-0006j9-GF for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Jan 2023 19:39:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pMvX7-0003gI-Sy; Tue, 31 Jan 2023 13:39:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pMvX3-0003bM-TS for emacs-devel@gnu.org; Tue, 31 Jan 2023 13:39:02 -0500 Original-Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pMvX2-0007F4-2O; Tue, 31 Jan 2023 13:39:01 -0500 Original-Received: by mail-pg1-x52f.google.com with SMTP id 7so5804249pgh.7; Tue, 31 Jan 2023 10:38:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=do3O0pvoi9nou1VFCegFWMdCdG49s4tvFi1yaza9XgY=; b=G53C4D4q8HHmNHNFjZ7XtDGLgRz9eVIgTsqZdcsh+VaD+qgE7r+nB5+yIDvKIM3JXv k6cXpUTIQ/F5msEJYkCJ7FVPmPclnLjyXgEXsuWLLLMUjeoOWWlaVjwumfMvFyh3nx4n D1fu6KxkRVkFN/b5XUjbMIfemBgWEjTxcnmKopsFhS6sXTTucphlFIiqbKr6JXoWzvK7 oeZApGyEjEzSwSIlw30jdLU7280iFRKhWivwc58N6EDPW4/Dk6xP48kujpX5uX+WEDEH tsr76VKgUR48BPccBLBleuTvi8yTJTWk8rkTmoXjMCd8ShEBfoha+NeExjvnoYhX0a50 dceg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=do3O0pvoi9nou1VFCegFWMdCdG49s4tvFi1yaza9XgY=; b=UftZFJlePU713Xq8s97FbQCqB5HPWDOxjFXCpgfX8YeM21Bm1gAjTSb+y40uBsX3WQ qZyvhbweTWtKL3XBxUTOx9sIk2yB/x0855Hg9C9UPQPTCsA0bwRRityKBeMANx+NkWml lQf6s+6sogVW6GpO97NFOaIjDnKhuvOg6qtsupIisvckMmykxInSfeKGnAsEkXTasnbA DXZtV5oZ1/3gEKV13maMyQ7z74Bo29DjcOGimtU+xsWkTXgaMVqD2JAPsXivn1ivyRx6 FdbJ2p1FBi+PuRb5qXmzHJNVDXpLdf3QcukgePkn73iagEwsOeu7DEjsS886DjbVa3zP yezA== X-Gm-Message-State: AFqh2krUBPhGJWSnIzSqOKCBme5v/iCw8qBfJadrAsWpHl/9yBvF4XkX F+XYquZMdkT0v1waLhJSJa28KNaPoxAidbG4QoA= X-Google-Smtp-Source: AMrXdXuWB7FI3PsIwj7htZpG389TM5E9KBg275aS1+dgbzr/y8JmaUoKwAi6Iw3gwktBV9LE87qOyBwJX/HrsAYEHvI= X-Received: by 2002:aa7:9182:0:b0:58d:ce70:4683 with SMTP id x2-20020aa79182000000b0058dce704683mr7419074pfa.39.1675190337295; Tue, 31 Jan 2023 10:38:57 -0800 (PST) In-Reply-To: <115a6020-2b86-2653-844e-d19eb03cf62c@gmx.at> Received-SPF: pass client-ip=2607:f8b0:4864:20::52f; envelope-from=tgbugs@gmail.com; helo=mail-pg1-x52f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:302841 Archived-At: > That's why 'display-buffer-use-least-recent-window' will never succeed > to become a good citizen in the department of buffer display functions. > The former will not bump the use time and if the window used by > 'display-buffer-reuse-window' happens to be the LRU one, > 'display-buffer-use-least-recent-window' may use it for displaying the > next buffer. I tried to convince Lars that this is the basic problem of > his approach but he didn't listen. If you try with a 'bump-use-time' > action alist entry you will see that it works. In testing I do indeed see the issue where display-buffer-reuse-window does not bump the use time and thus the reused window which should have been bumped remains the least recently used and is thus select for the next buffer when it should not. I can also see, but have not tested that bump-use-time in the action list would solve it. > Or, for example, a window that previously displayed the buffer. Yep, that one would be quite desirable if it could be achieved. > How would the other version handle it? The version that calls get-buffer-window internally reuses the window that currently contains the buffer making no apparent change to the user. The version that does NOT call get-buffer-widnow internally displays the buffer in the least recently used window (which in principle might be the buffer that it is already displayed in). Having played with it a bit, the behavior is rather confusing and probably undesirable. > BTW in the version you attached I see > + (get-lru-window (or reusable-frames frame) nil t)))) > > What's the purpose of 'reusable-frames' here? >From a previous message here is the scenario that I envisioned and have tested: > they have 3 visible frames, one for each monitor, and they want > the lru window to be selected from any of those visible frames They achieve this by including '(reusable-frames . visible) in the alist. That way they can get the same behavior for all visible windows as they would if they had a single monitor and a single frame. In light of this discussion which patch do we want to go with? The one that calls get-buffer-window internally or the one that does not? Once we have the answer I will summarize what we have discussed here in the comments and send a final patch. Best, Tom