mirror of
https://github.com/fish-shell/fish-shell.git
synced 2026-04-19 06:31:13 -03:00
829709c9c4
Old versions of ConHost and Putty can't parse DCS sequences. For this reason, we briefly switch to the alternate screen buffer while sending DCS-format (e.g. XTGETTCAP) queries. For extra paranoia, we wrapped this procedure in a synchronized update. This doesn't seem to be needed; neither ConHost nor Putty show glitches when the synchronized update is omitted. As of today, every terminal that implements XTGETTCAP also implements synchronized updates but that might change. Let's remove it, to reduce surprise for users and terminal developers. As a bonus, this also fixes a glitch on Terminal.app which fails to parse the synchronized-update query (`printf '\x1b[?2026$p'`) and echoes the "p" (bug report ID FB17141059). Else we could work around this with another alternate screen buffer. Unfortunately, this change surfaces two issues with GNU screen. For one, they don't allow apps to use the alternate screen features (the user may allow it with "altscreen on"). Second, screen unconditionally echoes the payload of DCS commands. A possible fix has been suggested at https://lists.gnu.org/archive/html/screen-devel/2025-04/msg00010.html I think this combination of behaviors is unique among terminals. I'm sure there are more terminals that don't parse DCS commands yet, but I think almost all terminals implement alternate screen buffer. Probably only terminal multiplexers are prone to this issue. AFAICT very few multiplexers exists, so we can work around those until they are fixed. Disable XTGETTCAP queries for GNU screen specifically. Unfortunately screen does not implement XTVERSION, so I don't know how to reliably identify it. Instead, check STY and some commonly-used values TERM values. This has false negatives in some edge cases. But the worst thing that happens is that "+q696e646e" will be echoed once at startup, which is easy to ignore, or work around with something like function workaround --on-event fish_prompt commandline -f repaint functions --erase workaround end which I don't think we should apply by default, because it can mask other issues. We should give screen more time to respond. I guess I'll open an issue so we don't forget. In doubt, we can always go back to the previous approach (but implement it in fish script). Alternative workaround: instead of the alternative screen buffer, we could try something like clr_eol/clr_bol to erase the spuriously echoed text. I tried to do this in various ways but (surprisingly) failed.