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 <[email protected]> wrote: > On Wed, Sep 30, 2015 at 03:01:09PM -0600, Joe Peterson <[email protected]> > 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 > --==---/ / _ \/ // /\ \/ / [email protected] > -=====/_/_//_/\_,_/ /_/\_\
_______________________________________________ rxvt-unicode mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
