using less for live log viewing with columnisation

[calestyo]

Hey.

Not sure what the following is, maybe a question or maybe (1-n) feature requests ;-)

I guess many people use less to view log files or similar output that is continuing.

1. This already kinda works partially with F mode. The problem though seems that while following, none of the usual navigation commands (scrolling up/down, searching or search terms highlighted, right/left when not wrapping words) seems to work.

Would that be feasible? Especially also, that e.g. new lines don't cause less to jump to the last line, but input is just buffered ... and there is a command which causes it to stick to the last line again?

I think there are actually two ways here:

• what F mode does right now, i.e. "just" continuing to record output as new one occurs.
• whether the currently shown text follows the last line or not

Think of it like a GUI Terminal, which are always in F mode even if one scrolls up (they still record any output), but when one scrolls up they don't follow the last line anymore, until one presses a key (when they jump down) or scrolls all the way down (when they also stick to the last line again).

So for less I think it would be nice if per default it would stick to the last line, even when moving right/left, but as soon as one goes up it stops (while still recording output). Similarly, it should stop to stick to the line when one presses some command key. Last but not least, only that same command key should make it sticky again (i.e. not when just accidentally scrolling down to the current last line).

2. Columnisation (yeas I know about column(1)) :-P

What one often has are loglines which are pretty long (i.e. longer then the screen). In this case one can already use -S . Often one can set up the logs so that fields are separated with a uniqe separator (like tab).

There it would be nice if less could automatically align columns on such separator. The difference to using something like column would be, that less could align just based on the lengths of the currently shown lines. Which would mean that if one goes a line up/down it might need to reprint the whole screen, as the newly visible lines might either require larger columns or smaller ones could suffice.

Cheers, Chris.

[haydenflinner]

You might like visidata or lnav

[gwsw]

1. I for one would find the proposed change quite disruptive and would immediately disable it. If I scroll down to the end of a file and then am reading the content visible there, I certainly do not want the screen to start uncommanded scrolling just because new data has been written to the file. I think following new data should only happen when deliberately invoked by the F command.
2. I think it would also be very irritating to have the columns visible on the screen potentially jump around left and right every time the user scrolls by one line. Text visible on the screen should simply scroll, not be reformatted, when a new line appears.