[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#44140: 26.3; ERC stamps: Really use latest buffer's window's wid

From: J.P.
Subject: Re: bug#44140: 26.3; ERC stamps: Really use latest buffer's window's width prior to `fill-column'
Date: Tue, 08 Jun 2021 20:56:12 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Hi Olivier,

Olivier Certner <olivier.certner@free.fr> writes:

> 4. Set `fill-column' to nil. Then, move to another window selecting
> another buffer, whose size is visibly smaller. Wait for messages to
> arrive in the ERC buffer and observe the timestamp position: It is
> relative to the currently selected window's width!

I followed the steps and observed the effects as you describe. Setting
fill-column to nil (which I wasn't aware was possible) makes it use the
width of whichever window's currently active. Definitely worthy of a "!".

> 2. `window-width' is called to obtain window's width, but this gets the
> width of the selected window, which is not necessarily where the buffer
> is actually displayed. Moreover, the buffer may not be displayed at the
> moment, so some other fallback is necessary.

Storing the last window's width seems like a good idea because these
buffers are often buried.

I'm a little fuzzy on how the ALL-FRAMES = t param for the function
`get-buffer-window' works exactly. The windows within each frame should
follow the normal cyclic ordering (right?). But I think I learned
somewhere that frame ordering is different and isn't affected by
whichever one was last selected. If true, I suppose frame users (not me)
are already used to this behavior and won't be surprised by it.

Anyway, I happened upon another approach for the final display part (see
attached sketch). If you see anything useful, just take it. Otherwise,
sorry for the distraction.

Attachment: 0001-ERC-stamps-Use-latest-buffer-s-window-s-width-prior-.patch
Description: Text Data

Attachment: 0002-Use-dynamic-align-to-spec-for-ERC-right-stamp.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]