[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44140: 26.3; ERC stamps: Really use latest buffer's window's width p
bug#44140: 26.3; ERC stamps: Really use latest buffer's window's width prior to `fill-column'
Wed, 07 Jul 2021 05:28:11 -0700
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Olivier Certner <firstname.lastname@example.org> 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
> 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
> 4. If 2 and 3 never occur, than the first window containing the current
> 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.