From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.bugs Subject: bug#44140: 26.3; ERC stamps: Really use latest buffer's window's width prior to `fill-column' Date: Wed, 07 Jul 2021 05:28:11 -0700 Message-ID: <87v95m71gk.fsf__14628.067873285$1625660955$gmane$org@neverwas.me> References: <1821306.tpkKSVv8f3@ravel> <87bl8f7ktf.fsf@neverwas.me> <7448139.J7Vt23MMP5@ravel> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2905"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 44140@debbugs.gnu.org, emacs-erc@gnu.org To: Olivier Certner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 07 14:29:10 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1m16ft-0000b0-Bv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 14:29:09 +0200 Original-Received: from localhost ([::1]:52602 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m16fr-00040D-IN for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 08:29:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48826) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m16fm-000402-Jw for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 08:29:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39526) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m16fm-0004dO-CF for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 08:29:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m16fm-0005BT-A9 for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 08:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "J.P." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Jul 2021 12:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44140 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44140-submit@debbugs.gnu.org id=B44140.162566090819867 (code B ref 44140); Wed, 07 Jul 2021 12:29:02 +0000 Original-Received: (at 44140) by debbugs.gnu.org; 7 Jul 2021 12:28:28 +0000 Original-Received: from localhost ([127.0.0.1]:51065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m16fE-0005AN-Gy for submit@debbugs.gnu.org; Wed, 07 Jul 2021 08:28:28 -0400 Original-Received: from mail-109-mta37.mxroute.com ([136.175.109.37]:35235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m16fD-0005AA-0Z for 44140@debbugs.gnu.org; Wed, 07 Jul 2021 08:28:27 -0400 Original-Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-109-mta37.mxroute.com (ZoneMTA) with ESMTPSA id 17a80f0b54c000ae11.001 for <44140@debbugs.gnu.org> (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Wed, 07 Jul 2021 12:28:16 +0000 X-Zone-Loop: 0bd4fd9cf033f9aad5fbe9140824843b43cbea6114ed X-Originating-IP: [149.28.56.236] In-Reply-To: <7448139.J7Vt23MMP5@ravel> (Olivier Certner's message of "Tue, 06 Jul 2021 17:15:34 +0200") X-AuthUser: masked@neverwas.me X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0, FROM_HAS_DN=0, RCPT_COUNT_THREE=0, TO_DN_SOME=0, FREEMAIL_TO=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0, FREEMAIL_ENVRCPT=0, MID_RHS_MATCH_FROM=0, NEURAL_SPAM=0] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:209585 Archived-At: Olivier Certner writes: > After reading some code (in "window.c"), I think `get-buffer-window' works > like this: > 1. It browses all windows in cyclic order (including windows of other frames > or not, depending on the ALL-FRAMES parameter). > 2. If the currently selected window contains the wanted buffer, it is returned > immediately. > 3. If 2 never occurs, and there is a window containing the current buffer in > the selected frame, then the first one (i.e., the most recently activated) is > returned. > 4. If 2 and 3 never occur, than the first window containing the current buffer > is returned (so, a window from another frame). I ended up stepping through some of the underlying functions that determine this behavior. It seems I failed to grasp/remember what "cyclic ordering" meant when reviewing your patch initially. Shocking, I know (cough). It's now my "belief" that the most recently selected ("other"/"old") window (or frame) does *not* impact selecting/visiting by these core functions. New windows/frames are just consed onto the front of global variables designated for this purpose. So the visiting order is set in stone and starts from the next oldest after the querying entity, moving toward the oldest. It then wraps around and goes from the youngest (newest) back toward itself. You likely had the right idea originally but were thrown off by my stupidity re "most recently activated" in #3. Anyway, the takeaway is that this behavior is predictable as long as people grok and expect (info "(elisp) Cyclic Window Ordering"). > Your changes seem interesting. I'm not very familiar with display properties, > and I'm wondering if this would work as expected on text displays. Since I > don't have much time to test that, and since these changes are independent of > the bugs fixed here, I'd suggest to put them in a separate report. If only there were folks familiar enough with display properties to offer some guidance to little old ERC. Assuming no, then no matter; it's not worth fussing over what's basically only a cosmetic concern when we have bigger fish to fry. Anyway, good job. This one's ready, I guess.