On Thu, Oct 01, 2026 at 02:43:01AM +0200, Vincent Lefevre wrote: > This is actually more complex: this depends on the scrollbar. > > With > > env -u XAPPLRESDIR xterm -fa "DejaVu Sans Mono-10" > > column $COLUMNS is affected, but with a scrollbar: > > env -u XAPPLRESDIR xterm -fa "DejaVu Sans Mono-10" -sb > > column $COLUMNS-1 is affected. > > This could be a miscalculation of a position somewhere.
something like that. In your example, it's unclear what the actual window size is. That matters. For instance, it could be interchanged x/y ordinates (I don't know where, but some explanation of the internals may help...). xterm stores each cell for the screen in a FIFO of lines of data. repainting uses that data; the screen-painting in forward scrolling does not (it saves the data into the FIFO while painting the screen). The new option "brokenCopyArea" which I added in 411 uses the data in the FIFO directly. Getting that to work required some reorganizing inside xterm to ensure that the FIFO is updated at consistent places within the screen-updating functions. Now... forward scrolling has (still the default) relied upon XCopyArea to move things around on the X window to reflect the changes which would be made to the FIFO. If your window has more columns than rows, and there was some interchange of x/y in one of those reorganizing changes, then I might see some case where repainting is clearing (or otherwise mistreating) some column(s) at the right margin of the window. I've seen none, but that TrueType font is also a factor. The experimental VS15/VS16 feature (inactive by default) seems to be the only aspect which might affect TrueType display. I don't see that in your screenshot, so I'm not expecting it to be relevant. With that in mind, you might find some easy way to reproduce the problem and provide a detailed explanation of how others can repeat it. -- Thomas E. Dickey <[email protected]> https://invisible-island.net
signature.asc
Description: PGP signature
