less
less copied to clipboard
gwsw
G is not useful if input is stdin
The docs include this warning for the G command:
Warning: this may be slow if N is large, or if N is not specified and standard input, rather than a file, is being read.
In fact, if you press G when input is stdin, less will just stop and wait until you press ctrl-C, which terminates the program writing to stdin.
The ESC-G command scrolls to bottom of the currently buffered text. This is nice, but isn't this a better default behavior for the regular G command? Is there a time when you want less to freeze until the program writing to stdin terminates? It seems like the current behavior is useless. When something is writing the input, you either want to scroll to the newest text (ESC-G) or scroll forever (F).
In my opinion, ESC-G should be deprecated and G should have the same behavior that ESC-G currently has if input is a pipe.
I am almost persuaded, but I'm worried about the change in behavior if someone does "less <bigfile". Currently G goes to end of file as expected. The proposed change would make it go to the last buffered line, which I agree is reasonable if the input is another program, but probably not if it's just a file coming into stdin.
While thinking about this, I realised that there is no way to jump to the end of the currently available input at all. F does this but continues to read and cannot be stopped w/o terminating the pipe. ESC-G does only jump to the end of the already-read buffer which can be highly confusing, esp. if that behaviour would be mapped to G. Should / could the behaviour of G in a pipe be altered to consume all available input, and then scroll to it its end? While still being slow, that would also address the considerations regarding less <bigfile.
Despite having a quick peek at the sources I cannot tell if it is possible to decide when we are at the end of the input w/o blocking or if implementing such a thing would suffer from the same issues as #49 (allow to stop F) is having.
Given the history and potential disruption of changing the behavior of the very commonly used G command, I'm inclined to leave things as they stand. The user can use ESC-G if they want to jump to the end of buffered data.
F does this but continues to read and cannot be stopped w/o terminating the pipe.
Just wanted to note that this is no longer true. From https://github.com/gwsw/less/issues/49
As of https://github.com/gwsw/less/commit/5bf862fde4a33ce4a602f369a0c3cb430c883a12, you should be able to exit F mode with control-X, in environments where poll() is supported.
