On 4/5/20 2:58 PM, Greg Reagle wrote:
> On Sun, Apr 5, 2020, at 06:57, Laslo Hunhold wrote:
>> On Sun, 5 Apr 2020 12:11:09 +0200
>> Georg Lehner <jorge_AT_at.anteris.net> wrote:
>>> A question: why is the scrollback-patch not included in `st` already
>> exactly my point. I see no reason why there can't at least be a
>> scrollback, which defaults to 0 in config.h.
>> Wouldn't this make all sides happy?
> Now I am thinking that it would be good idea to have a scrollback program and/or library that is used by st, xterm, dvtm, tmux, splitvt, mtm. For those programs that do not come with a scrollback feature, this would add the scrollback feature with very little (scrollback library) or no (scrollback program) extra code. For some of those programs that already have the feature, stripping out their custom code would reduce complexity. If all of these programs used the same program/library, there would be a consistent user interface which would be really nice.
>
> I think that some people consider a scrollback buffer in st to be feature bloat, so they keep it out of the main line and force it into an extra patch. The attitude is: If you want scrollback, use dvtm or tmux, or the scrollback patch, or do things in a Plan 9 sort of way (which I am not too familiar with).
>
> When I first learned of st, this attitude really baffled me. How could a scrollback feature in a terminal be considered extraneous? Now that I've learned more about suckless and about how Plan 9 works (though Plan 9 still confuses me, I haven't completely wrapped my head around it), it doesn't seem so crazy. But still, I always use the scrollback patch for st.
>
Hi Greg,
Last week I created a standalone scrollback utility by stripping down dvtm.
Jochen reported, that some suckless people are doing the same thing, but
from scratch, see:
http://git.suckless.org/scroll/
One can use also use the -o recording feature of st itself for achieving
part of the functionality.
The standalone utility approach is in fact code duplication:
1. st launches the child process the user specified or a shell. It reads
the input stream, intercepts certain special key sequences in order to
control the terminal and sends the rest to the child proces.
Additionally, st reads the output stream from the child process and
intercepts special control sequences.
2. in order to use a standalone scrollback utility, the user specifies
the scrollback utility, which in turn launches a child process specified
by the user, or a shell, it intercepts certain key sequences .... the
rest is the same.
If st and the scrollback do not agree on what to intercept and what to
let through you - the user - have a problem.
Now to the Plan9 terminal: It has an unlimited, editable scrollback
buffer and extensive mouse and keyboard interaction with it.
One difference is, that there is no such thing like curses or
"commandline" programs which try to get fancy with painting on a
character terminal. Either it is a pipe, or it is a graphical program
using the window system. There is no need for a terminal emulator in
Plan9, just a graphical application which facilitates running the shell:
the Plan9 terminal.
The scrollback patch is one of the simplest and cleanest solution, it's
93 lines of code.
The minimal scroll utility is already 417 SLOC and growing...
I could visualize an alternative solution with external buffering via an
"automatic" -o recording and launching external viewers via keyboard
shortcuts, but that might require some more thougth.
Regards
Best Regards
Received on Sun Apr 05 2020 - 17:14:17 CEST