Re-wraping with partial end of line at start of save buffer

Fri Oct 2 02:10:11 CEST 2015

Hi Marc, I think I was not clear enough in my explanation. you are
right: it would not make sense to throw away all "partial lines". Let
me try to explain it a little better.

As background: I have saveLines set to 5000, and I typically use a
30-line terminal window (80 chars wide). This makes for an even number
of lines that can be stored, but the last line is usually the command
prompt, so there is room in the save buffer for an odd number of lines
above the prompt.

If I use "ls -l" to show the contents of a directory with ~3000 files,
and each line is somewhat longer than 80 characters due to long
filenames, I initially get wrapped lines, so this would require ~6000
lines of capacity in the terminal (since each line wraps to the next
line, causing twice as many buffered lines). In other words, lines
scroll out of the save buffer, which is too small to hold them all.

If I scroll back as far as I can until I hit the start of the save
buffer, the very top line shown is the *end* of a line (e.g. the few
characters that wrapped past the 80 character width). This is key,
since now the terminal knows all of the lines, except that very top
partial/end piece, are wrapped, but it does not seem to know (or does
not handle) the one partial end piece that used to be part of a longer
line.

So if I widen the terminal window so that all of these lines the fit
(and BTW, this is a fantastic, cool, and unique feature of urxvt - I
use it often!), All lines correctly re-wrap except that first end
piece that partially scrolled out of the save buffer. That first end
piece is treated as if it were a complete line (since the start of
that line scrolled out), so it behaves differently than all of the
following lines, and we are left with all but the first line looking
correct. That first line looks like a corrupt/left-over piece of an
old line, as if urxvt did not handle it correctly (i.e. it looks like
it was caused by a bug). It is even a bit misleading, since the
position of the left-over characters does not match the position of
their counterparts in the other lines.

There is really no advantage to keeping that first "end of a line",
since the first part of that line is gone, anyway. So my suggestion
would be to either:

1) On re-wrap, detect if the first line is not a complete line (i.e.
if the first part of that line scrolled out of the buffer) and discard
just that first partial line, leaving the start of the first complete
line as the first saved line.

or

2) When part of a line scrolls out of the buffer, just discard the
rest of that line as well, leaving the start of the first complete
line as the first saved line.

I prefer #1, since it minimizes needless discarding and still makes
the re-wrap look correct. The left-over end part of a line does not
look wrong until a rewrap is done. As an aside, re-wrapping discards
saved lines, anyway, when (e.g.) the window is made less wide and then
widened again, so users understand that re-wrapping is a process that
changes the capacity of the save buffer.

The problem I see with leaving things as they are is that the first
incomplete line, after rewrap, looks like leftover kruft and is
confusing. When I first saw it, the lines were only longer than the
width by one character, and I wondered, "What is that odd letter by
itself on the first line of my terminal window?"

I've attached a few screenshots of what this looks like as follows:

1. Dir listing with wrapped lines (just one char too long - the "T")
2. After back-scrolling to top (looks as expected)
3. Unwrapped lines after widening term (looks good here)
4. Again back-scrolled to top (just the errant "T" on first line)

I'd be glad to put together a patch, and if you can point me to
approximately where the change would be appropriate, it would help,
but I can investigate this on my own, too (i.e., I am willing to do
the footwork for this).

On 1 October 2015 at 01:02, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Wed, Sep 30, 2015 at 03:01:09PM -0600, Joe Peterson <joe at wildlava.com> wrote:
>> I believe the correct behavior would be to throw away any partial line
>
> I believe the current behaviour is much more sensible. Basically, you are
> asking that partial lines get thrown away when they can't fully fit, but
> *only* when making your window larger. That makes absolutely no sense,
> as the visual result you are complaining about is the same as before the
> resize (you had a partial line before).
>
> It might have merit to remove full lines when they scroll out of the save
> buffer, instead of cutting them apart, but I don't think we will implement
> that.
>
> --
>                 The choice of a       Deliantra, the free code+content MORPG
>       -----==-     _GNU_              http://www.deliantra.net
>       ----==-- _       generation
>       ---==---(_)__  __ ____  __      Marc Lehmann
>       --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>       -=====/_/_//_/\_,_/ /_/\_\
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 2214 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151001/ea4a6994/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 2006 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151001/ea4a6994/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.png
Type: image/png
Size: 2643 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151001/ea4a6994/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.png
Type: image/png
Size: 2400 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20151001/ea4a6994/attachment-0003.png>