On 15/8/26 11:47 pm, Stéphane ORTEGA wrote:
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.
Hey Stéphane! Sorry for the belated reply... studying for my first year
in uni and CCNA piled up a bit.
I think it'll be a bit until i have some free time i can properly
dedicate to this. Also,
just a nitpick posts to this mailing list should ideally be bottom-posts
(the quote first
then the text). Don't worry its just like something to be aware of (i
goofed up by
sending my openpgp signature and produced garbled output on the archive so
comparatively this is nothing). Your mailing client should have a
compose setting for
this. I'll try get around to it as soon as i can but it might be a bit
I'm aware its a
pain-point you face daily seeing as you use lf as your file manager.
I'll try expedite where possible,
Nick.
(P.S. thanks for the inspoStéphane, I now have a signature too haha)
--
Nick Borș IRC: nickbors@{libera,oftc}
https://nickbors.cc OpenPGP: 8644 95EF DB95 857C
