Matthew Miller had an interesting idea (https://bugzilla.redhat.com/show_bug.cgi?id=867841#c5):
> It's too bad less doesn't have an "upside down" mode where it reverses
> the input, starts at the end and loads more data as one scrolls up.
> If it did, journalctl could default to serializing in reverse order,
> and then the upside down mode would invert again, presenting it in
> chronological order but starting from the end.
It would be nice if less had a "--reverse" option that would act as a built-in 'tac' filter. In other words, the first line read from the input file would be displayed as the most bottom line.
The difference versus just using 'tac' would be that when combined with "+G" the input lines could be read from a pipe progressively as the users scrolls up from the initial bottom.
This sounds reasonable and it shouldn't be so hard to implement to be fast enough...
I know this can't be super high-priority, but I've got systemd with `journalctl -r` now so I'm excited to see this part too. :)
Yes, well, I have discussed this with Mark Nudelman (the upstream) regarding what it would involve to implement this. It seems the amount of work I estimated at the first glance wasn't so small as I thought:
Of course simple browsing and paging through the text wouldn't be a problem. The problem here lies in the fact less provides some quite advanced functionality such as searching for matching braces, jumping to a percentage of the whole document or one particular line number.
All of this (and possibly more) would need modification to be consistent with the UI that the "regular" top->bottom mode uses.
In conclusion, I'm sorry for my low responsiveness in regards of this issue and for the fact I currently simply don't have enough time to spend implementing this.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I will contact upstream again whether this RFE is feasible. If I start working on it, I will change it to ASSIGNED again.