Hi Nicholas, Thank you very much for your reply and for your interest in working on this.
I should clarify that I am only a regular st user, rather than a developer. My investigations led me to these observations about DECSET 2026 and the existing application-sync patch, but unfortunately I don't have the skills or experience to implement the necessary changes myself. That said, I would be very interested in following any work on this, and I would be happy to help with testing if that could be useful. In particular, I can test on my NetBSD system with st and lf and report any issues or differences in behaviour. If a patch or project takes shape, I would also appreciate being kept informed of its progress, especially if it eventually results in a solution that could address the issue on my system. Thanks again for taking the time to look into this. Best regards, Stéphane Le Fri, Aug 14, 2026 at 03:02:32AM +0300, Nicholas Bors-Sterian a écrit : > On 12/8/26 2:25 am, Stéphane ORTEGA wrote: > > > Hello, > > > > I would like to ask about support for DEC private mode 2026 (Synchronized > > Output) 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 > > emulator 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 > > it 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. > > The "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 > > protocol: > > > > 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 > > particular case. > > > > I also confirmed that the current st master does not handle private mode > > 2026: 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 > > sufficient, 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 > > mode 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. > Hey Stéphane, > > I would be interested in working on this -- please send me a patch if you > have already started work on one. > > I think this is something that st should support by default, however the > existing application-sync patch you mention being a community patch that's > not seeing inclusion in the mainline leads me to believe that the > maintainers want to avoid supporting too many 'niche' escape code sequences. > Perhaps an update to (or derivative of) the existing sync patch would be > most suitable? > > As for your second question, I think that a good implementation should > implement the expected semantics (with the safeguard timeout as you > mentioned) as opposed to silently ignoring the sequence would be best. > > Thanks for looking into this, I'll be happy to look at any code you post. -- Stéphane ORTEGA https://stephaneortega.fr/ +33 (0)684.041.350 GPG Key ID: 0x56F6CF155AB3B3BF/2048R IRC: Well@{libera,oftc}
signature.asc
Description: PGP signature
