ruby R53 writes: > i actually have contacted the author of the application-sync patch > to suggest this update, i noticed i was getting those error > messages when using btop, which did rely on those escape codes, > and so he instead figured we could open an issue on btop's GitHub > repository to suggest btop's author to add a configuration option > for whether the user wants that feature or not, so that's how it > ended up ¯\_(ツ)_/¯
Oh if only there was some standard or convention by which applications could be informed of the features that terminals and the emulators thereof support and how to activate them! A thousand novel curses on the myriad developers in 50 or 60 years (wait, when did Baudot invent his bits?) who never thought about coming up with some sort of standard code which can be used to perform information interchange! The message informs you that a control has not been implemented, apparently a control which will ultimately have no effect on the visual display (but which, if implemented poorly, could cause the display to stop updating permanently). You can simply ignore that note, exactly as the standards dictating how to interpret unknown codes have decreed since the very first days of using teletypes. Matthew > On Tuesday, August 11th, 2026 at 9:02 PM, Stéphane ORTEGA > <[email protected]> > wrote: > > > Hello, > > > > I would like to ask about support for DEC private mode 2026 (Synchronized O > utput) in st. > > > > I am running NetBSD 11.0 amd64 with the current st master (commit 04ce0d6, > 2026-06-29), built locally against NetBSD's X11R7. I use st as my terminal em > ulator and lf as my terminal file manager. > > > > While investigating a large number of error messages printed by st, I found > that lf emits the following sequences when drawing its interface: > > > > CSI ? 2026 h > > .. > > CSI ? 2026 l > > > > A minimal reproduction is: > > > > printf '\033[?2026hHELLO\033[?2026l\n' > > > > This works correctly in xterm, but st reports: > > > > erresc: unknown private set/reset mode 2026 > > > > The same messages are produced continuously when navigating in lf. > > > > I initially had the NetBSD/pkgsrc version of lf installed. I then removed i > t and built the latest upstream lf from GitHub with Go 1.26.5. The behaviour > was unchanged, so this does not appear to be specific to the packaged version > of lf. > > > > I also tested lf with an empty configuration, with the same result. > > > > I checked the existing synchronized-rendering support on the st website Th > e "sync" patch is described as having two parts: > > > > auto-sync, which has already been merged upstream; > > > > application-sync, which is available as the historical st-appsync patch > . > > > > However, the application-sync patch appears to implement the older DCS prot > ocol: > > > > ESC P = 1 s ESC \ > > ESC P = 2 s ESC \ > > > > rather than the DECSET/DECRST 2026 sequences: > > > > CSI ? 2026 h > > CSI ? 2026 l > > > > The existing st application-sync patch therefore does not solve this partic > ular case. > > > > I also confirmed that the current st master does not handle private mode 20 > 26: it reaches the "unknown private set/reset mode" error path in tsetmode(). > > > > My questions are: > > > > Is there currently any work or patch for supporting DECSET/DECRST 2026 > in st? > > > > Is the older application-sync implementation intentionally considered s > ufficient, or is support for the newer CSI ?2026h/l mechanism desirable? > > > > If support for DEC mode 2026 is considered appropriate for st, would a > patch implementing synchronized output at the rendering level be acceptable? > > > > I am particularly interested in the distinction between merely accepting mo > de 2026 (and suppressing the error) and actually implementing its semantics: > while synchronized output is active, terminal input should still be processed > , but screen updates should not be presented until the corresponding 2026l is > received, with an appropriate timeout as a safeguard. > > > > For reference, my minimal reproduction is simply: > > > > printf '\033[?2026hHELLO\033[?2026l\n' > > > > With xterm, this produces "HELLO" without an error. With current st master, > it produces the "unknown private set/reset mode 2026" diagnostic. > > > > I would appreciate any pointers to existing work, design considerations, or > objections before attempting an implementation for st. > > > > Thanks. > > > > -- > > Stéphane ORTEGA https://stephaneortega.fr/ +33 (0)684.041.350 > > GPG Key ID: 0x56F6CF155AB3B3BF/2048R IRC: Well@{libera,oftc} > > > > > >
