Re: [dev] Scrollback utility for use with st
I just figured out, that `st` already has an unlimited scrollback buffer - kind of. Run `st -o /tmp/unlimited_scrollbackbuffer`. Than inside the `st` terminal, you can `less`, `vi` ... whatever you want. For a starter try: `less -r +G /tmp/unlimited_scrollbackbuffer` Of course it makes sense to start/stop the I/O writing while manipulating. ToDos: - find out the simplest way to specify a unique filename for each invocation (e.g. inside tabbed) - and of course how to remove it when `st` exits - find out how to programatically send the start stop sequence. Regards, Georg On 4/2/20 1:48 PM, Greg Reagle wrote: On Wed, Apr 1, 2020, at 16:51, Lehner Georg wrote: That is absolutely great! R.I.P `sb`. If a standalone scrollback program were good enough, could it be used to replace the scrollback code in tmux, dvtm, xterm? Would that be a good idea? Do you think the developers of these programs would be willing to remove their scrollback code and depend on a standalone scrollback program? DVTM has this really nice feature, the ability to see the scrollback buffer in an editor. I'd like to get access to the scrollback buffer with an editor or pager (like less). I don't want to have to learn a new and different way to search through the scrollback buffer for tmux, dvtm, screen, etc. I already know emacs (pretend I wrote "vi" if that offends you) and less. Duplication of scrollback code also is an opportunity for more bugs. By the way, if I can get access to the scrollback buffer in less, then I automatically get access to it in an editor, because less has the v command.
Re: [dev] Scrollback utility for use with st
On 4/3/20 9:17 AM, Laslo Hunhold wrote:
On Thu, 2 Apr 2020 21:14:11 +0200
Georg Lehner wrote:
Dear Georg,
...
at this point, why not just use the scrollback-patch?
With best regards
Laslo
Finally I felt nudged to test the scrollback patches. Nice work!
Two of the patches failed - the last one (configurable
mousescrollincrement) does not compile. Also the man page does not show
Find below a combined patch for the current version in git fixing all
the above (minus the mousescrollincrement).
A convenient scroll increment would be:
- 3 (1..n) for the mouse wheel
- Exactly one window height for the PageUp/Down keys. This would require
getting the current window height while scrolling
A question: why is the scrollback-patch not included in `st` already?
Best Regards,
Georg
diff --git a/config.def.h b/config.def.h
index 546edda..25d1951 100644
--- a/config.def.h
+++ b/config.def.h
@@ -161,8 +161,11 @@ static uint forcemousemod = ShiftMask;
* Internal mouse shortcuts.
* Beware that overloading Button1 will disable the selection.
*/
+const unsigned int mousescrollincrement = 1;
static MouseShortcut mshortcuts[] = {
/* mask button functionargument release */
+ { XK_ANY_MOD, Button4, kscrollup, {.i = 1}, 0, /* !alt */ -1 },
+ { XK_ANY_MOD, Button5, kscrolldown,{.i = 1}, 0, /* !alt */ -1 },
{ XK_ANY_MOD, Button2, selpaste, {.i = 0}, 1 },
{ XK_ANY_MOD, Button4, ttysend,{.s = "\031"} },
{ XK_ANY_MOD, Button5, ttysend,{.s = "\005"} },
@@ -186,6 +189,8 @@ static Shortcut shortcuts[] = {
{ TERMMOD, XK_Y, selpaste, {.i = 0} },
{ ShiftMask,XK_Insert, selpaste, {.i = 0} },
{ TERMMOD, XK_Num_Lock,numlock,{.i = 0} },
+ { ShiftMask,XK_Page_Up, kscrollup, {.i = 1} },
+ { ShiftMask,XK_Page_Down, kscrolldown,{.i = 1} },
};
/*
diff --git a/st.1 b/st.1
index e8d6059..d48d991 100644
--- a/st.1
+++ b/st.1
@@ -159,6 +159,15 @@ Copy the selected text to the clipboard selection.
.TP
.B Ctrl-Shift-v
Paste from the clipboard selection.
+.TP
+.B Shift-Page Up
+Scroll back.
+.TP
+.B Shift-Page Down
+Scroll forward
+.TP
+.B Shift-Mouse Wheel
+Scroll forward/backward
.SH CUSTOMIZATION
.B st
can be customized by creating a custom config.h and (re)compiling the source
diff --git a/st.c b/st.c
index 3e48410..7de1369 100644
--- a/st.c
+++ b/st.c
@@ -35,6 +35,7 @@
#define ESC_ARG_SIZ 16
#define STR_BUF_SIZ ESC_BUF_SIZ
#define STR_ARG_SIZ ESC_ARG_SIZ
+#define HISTSIZE 2000
/* macros */
#define IS_SET(flag) ((term.mode & (flag)) != 0)
@@ -42,6 +43,9 @@
#define ISCONTROLC1(c) (BETWEEN(c, 0x80, 0x9f))
#define ISCONTROL(c) (ISCONTROLC0(c) || ISCONTROLC1(c))
#define ISDELIM(u) (u && wcschr(worddelimiters, u))
+#define TLINE(y) ((y) < term.scr ? term.hist[((y) + term.histi - \
+term.scr + HISTSIZE + 1) % HISTSIZE] : \
+term.line[(y) - term.scr])
enum term_mode {
MODE_WRAP= 1 << 0,
@@ -117,6 +121,9 @@ typedef struct {
int col; /* nb col */
Line *line; /* screen */
Line *alt;/* alternate screen */
+ Line hist[HISTSIZE]; /* history buffer */
+ int histi;/* history index */
+ int scr; /* scroll back */
int *dirty; /* dirtyness of lines */
TCursor c;/* cursor */
int ocx; /* old cursor col */
@@ -185,8 +192,8 @@ static void tnewline(int);
static void tputtab(int);
static void tputc(Rune);
static void treset(void);
-static void tscrollup(int, int);
-static void tscrolldown(int, int);
+static void tscrollup(int, int, int);
+static void tscrolldown(int, int, int);
static void tsetattr(int *, int);
static void tsetchar(Rune, Glyph *, int, int);
static void tsetdirt(int, int);
@@ -414,10 +421,10 @@ tlinelen(int y)
{
int i = term.col;
- if (term.line[y][i - 1].mode & ATTR_WRAP)
+ if (TLINE(y)[i - 1].mode & ATTR_WRAP)
return i;
- while (i > 0 && term.line[y][i - 1].u == ' ')
+ while (i > 0 && TLINE(y)[i - 1].u == ' ')
--i;
return i;
@@ -526,7 +533,7 @@ selsnap(int *x, int *y, int direction)
* Snap around if the word wraps around at the end or
* beginning of a line.
*/
- prevgp = &term.line[*y][*x];
+ prevgp = &TLINE(*y)[*x];
prevdelim = ISDELIM(prevgp->u);
for (;;) {
newx = *x + direction;
@@ -541,14 +548,14 @@ selsnap(int *x, int *y, int direction)
yt = *y, xt = *x;
else
yt = newy, xt = newx;
-if (!(term.line[yt][xt].mode & ATTR_WRAP))
+if (!(TLINE(yt)[xt].mode & ATTR_WRAP))
break;
}
if (newx >= tlinelen(newy))
break;
- gp = &term.line[newy][newx];
+ gp = &TLINE(newy)[newx];
delim = ISDELIM(gp->u);
if (!(gp->mode & ATTR_WDUMMY)
Re: [dev] Scrollback utility for use with st
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 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
Re: [dev] Build system: redo
Hi Sergey, You might have overlooked, that jdebp not only did a documentation of redo, but also provides a C++ implementation: http://jdebp.eu/Softwares/redo/ Best Regards, Georg On 12/17/20 7:44 PM, Sergey Matveev wrote: Greetings! I see that redo subject was already there before: https://lists.suckless.org/dev/1207/11916.html but much time passed since that discussion! That year I tried redo and it was really life-changing. And no, Plan9 mk is not full-fledged replacement for (POSIX/BSD/whatever) Make, that solves all issues DJB noted. But redo leaves no place for mk too. Uriel wrote that it could be worth looking at until it will be written on C or Go. Now there are pure C https://github.com/leahneukirchen/redo-c and pure Go http://www.goredo.cypherpunks.ru/ implementations, not taking in advance various pure POSIX shell implementations. goredo was written as a replacement to Python apenwarr/redo's https://redo.readthedocs.io/en/latest/ already mentioned in that maillist before, because of performance, reliability (fsyncs) and simplicity reasons (no SQLite3 database, just plaintext recfiles) with nearly all convenient features apenwarr's implementation has. I love suckless principles, and support them in most of my software -- redo is clearly without any doubts for me is in the suckless category with its genuine simplicity, flexibility and power, deserving to "rock". And some links just for reminding: https://fzakaria.com/2020/06/08/my-love-letter-to-redo.html https://apenwarr.ca/log/20101214 https://redo.readthedocs.io/en/latest/ http://jdebp.eu/FGA/introduction-to-redo.html And for russian speaking people my hailing article to redo: https://m.habr.com/ru/post/517490/ with short full redo description and comparison: http://www.stargrave.org/redo-proscons.html
Re: [dev] Build system: redo
Just a heads up, I tampered around with redo-c. Find it at https://github.com/jorge-leon/redo-c It: - Captures stdout of do files in the target file. - Does not create an empty target if $3 is empty. This allows for "phony" targets and protects against silly mistakes. - Truncates targets explicitly if needed, - Creates the temporary output file $3 with the same permissions of an existing target, or with 0644 - subject to the umask. - Searches for |target.do| before |default.do| - also in parent directories. - Is modified for compilation with dietlibc (you might want to revert this). - Uses the shorter and faster SipHash-2-4-64 instead of sha256. - Has dependency cycle detection. - Writes its redo database into a per-directory .redo subdirectory. Caution: I'm not (yet) proud of it and it has rough edges. Best Regards, Georg On 12/18/20 11:33, Sergey Matveev wrote: *** Sergey Matveev [2020-12-17 21:44]: Now there are pure C https://github.com/leahneukirchen/redo-c And by the way, it is less than 1kLOC even with completely built-in SHA256 implementation and no dependencies. Supporint all necessary redo-ifchange/ifcreate/always commands, jobserver (parallel builds) and supporting both pure-shell .do files and executable ones, that can be written on any language.
Re: [dev] ii: how to process out in a pipeline and still page with less
Hello, Does nobuf(1) help? http://jdebp.uk/Softwares/djbwares/guide/nobuf.html Note: it tackles exactly the POSIX feature to line buffer output to tty's by providing one to the program in the pipeline, but without using any shared-object magic. Have not used it (yet) though. Best Regards, Georg On 5/30/22 08:29, Josuah Demangeon wrote: Rodrigo Martins wrote: What if instead of changing every program we changed the standard library? We could make stdio line buffered by setting an environment variable. I applaude this idea! Environment variables seems to be the right spot for any config a library could need: are unobstrusive, can be set by the program calling it, yet keep each program configurable by default. Markus Wichmann wrote: The problem you run into here is that there is more than one standard library. The problem was stated here for libc's stdio, but I still like the idea for new libraries: A call to getenv (which never fails), into xyz_init(). What about $DISPLAY, $MALLOC_OPTIONS (OpenBSD), or $LIBV4LCONTROL_FLAGS[1] or some LIBXYZ_DEFAULT_DEV_FILE=/dev/xyz3? Insane and breaking some important concept? To keep for debugging purposes only? Not to use for every kind of configuration? Better let the programmer control the entirety of the library? Although, if a library (or any program really) does not *require* any configuration or environment variable and always works without that, I like it even better. [1]: https://github.com/philips/libv4l/blob/cdfd29/libv4lconvert/control/libv4lcontrol.c#L369-L371
Re: [dev] Automatic C header dependency tracking for the redo build-system
Hi, The topic of header dependency tracking is already addressed since the inception of redo by DJB. The Appenwarr documentation offers a fairly simple answer in the form of an "implicit" .do file for object files. --- cat > default.o.do <2. build the object file and generate a make-style one-line include dependency on all header files with the compiler itself. 3. read the rule into the variable DEPS. 4. check the dependency on all header files. The second line and the fourth line are one of the special things about redo: *after* building the target you can check *again* if it needs to be rebuilt. Best Regards, Georg On 9/7/21 19:50, Thomas Oltmann wrote: Hi everybody! redo is a pretty well-designed family of build-systems that enjoys a certain popularity among people on this mailing list. Its recursive nature makes it well-suited to projects comprising a large amount of files. However, unlike comparable build-systems like make or tup, it lacks provisions to automatically track C #include dependencies, which is sorely needed for projects with many source files. To overcome this, I wrote a simple companion tool that integrates fairly seamlessly with redo. This tool is able to parse the dependency-only Makefiles that modern C compilers can produce during compilation, and feed these dependencies into redo (via 'redo-ifchange'). It should work with pretty much any redo implementation (other than maybe apenwarr's *minimal do*, because that one doesn't implement 'redo-ifchange' as a separate executable). You can find it here: https://github.com/tomolt/redo-depfile Any feedback is appreciated. Cheers, Thomas Oltmann P.S.: My sincere apologies if this post if considered off-topic, as redo is not under the suckless banner. I considered posting on the redo mailing-list instead, but that one seems very obscure and inactive, plus I recognize some of the posters there as being regulars on the suckless mailing lists as well.
Re: [dev] POSIX Monitoring tools
Hi LM, Monitoring always sucks 8-] I settled on collectd[1], which ".. has been reported as working on .. AIX". To "unsuck" it a little bit, I compile from sources and leave out every plugin I do not need. My sample "./configure" is below, you might want to leave out even more (chrony, sensors, md). ./configure \ --prefix=/usr/local \ --sysconfdir=/etc/collectd \ --localstatedir=/var \ --enable-all-plugins=no \ --enable-chrony \ --enable-cpu \ --enable-df \ --enable-entropy \ --enable-exec \ --enable-hddtemp \ --enable-interface \ --enable-load \ --enable-logfile \ --enable-md \ --enable-memory \ --enable-notify_email \ --enable-protocols \ --enable-rrdtool \ --enable-sensors \ --enable-swap \ --enable-tail \ --enable-tcpconns \ --enable-threshold \ --enable-unixsock Regards, Georg [1]: https://collectd.org/ On 11/12/21 13:13, LM wrote: Any recommendations for utilities to monitor AIX systems? Looking for something that follows the suckless.org philosophies preferably written in C. Thanks.
Re: [dev] [quark] a monty-pythonesque journey with SYSTEMd
Hello Spenser, You could just install e.g. runit and use it to run quark. With Debian it would be the 'runit-run' package. Best Regards, Georg On 5/30/23 04:37, Spenser Truex wrote: My $10/yr VPS host Racknerd ungraciously requires that I'd make a support ticket in order to get a custom ISO for my VPS. I think I'd rather suffer and die. Fun awaits? Maybe I can collect a pile of .service files for some suckless programs? Quark has a slightly complex set of behaviours that make systemd not boot it. I think systemd sockets and systemd chroot shenanegains are involved here. It "starts" but causes systemd to hang on the systemctl start quark command. The socket doesn't open -- quark seems to be blocked in some way. Unbound has a similar issue, and it too has a chroot startup which is explicitly defined in their systemD service file on debian, but the unbound official recommendation is to use whatever magic code the program can run to install itself. And they recommend deleting the socket-related bits in the systemd service files directory. Despite this, I tried just copying the unbound config but wasn't able to get it to work. SystemD doesn't tell you why it doesn't work (please pay redhat instead for help installing programs on your VPS!). I hope to succeed on my quest for the Holy Grail in this desolate land.
Re: [dev] reading an epub book with less: adventures in text processing
Hi Greg, On 2024-03-09 15:34, Greg Reagle wrote: I have an epub ebook. It is a novel, but when I get this process working, I want to repeat it for any epub ebook. I want to read it, with formatting (such as underline or italics), with less. I am happy to use any software that exists in the process, but I MUST use less in the end to read it. The terminal emulators that I use are usually st, xterm, and termux. All of them are capable of colored text and underlining and so forth, and I want to take advantage of this. Pandoc does a very good job converting epub to html, and it looks good with w3m, however when I use w3m in a pipe, the output is truly *plain* text, meaning there are no escape codes for formatting. Same story with elinks. Is it possible to get either of these programs, or some other program, to dump html to text *with* escape codes? Since I could not get HTML to work, I went with man format. Amazing. Pandoc automatically chooses man format for output based on the '.1' extension in the followingv pandoc --standalone -o City_of_Truth-Morrow.1 City_of_Truth-Morrow.epub Remember to use standalone option or it won't work. Then man --local-file --pager 'less -ir' City_of_Truth-Morrow.1 It looks great! (for text only on a terminal) It has bold and underlined text. From there I can use less 's' command to save the formatted text to a file. There might be a better or more direct way of achieving this goal, but this I what I figured out for now. And the rationale is this: I already know and love less. There is no good reason for me to learn the user interface of a different program like an epub reader or an html reader to read a book that does not have graphics, diagrams, pictures, and/or custom formatting. Just modify your workflow slightly and you are good: Option 1: use w3m pandoc -s -t html City_of_Truth-Morrow.epub | w3m -T text/html Option 2: use man/less pandoc -t man City_of_Truth-Morrow.epub | man -l - Option 3, save as html for future use: pandoc -s -o City_of_Truth-Morrow.html City_of_Truth-Morrow.epub Saves your epub to html. Whenever you want to view it, use your favorite browser, i.e. w3m, with all its features. Option 4: save as man: pandoc -s -t man -o City_of_Truth-Morrow.man City_of_Truth-Morrow.epub Whenever you view it, use: man -l City_of_Truth-Morrow.man - - - Some notes: The reason you loose formatting when saving from less(1) or w3m is, that these programs on purpose do not save the terminal control characters which are doing the markup. Line breaks and terminal control are created on demand, depending on the type and size of the terminal (window) and will display different (weird) when any of this is different from the terminal you (would have) saved them to a file. The -s option (--standalone) option for Pandoc is not required for man page output. For html (and other formats) pandoc outputs only the content, the -s options wraps this into a complete document. Best Regards, Georg
