Chafa leaves echo on

[veltza]

The commit 87676ab leaves echo on, so terminals like st and xterm that echo keystrokes to the screen are unusable after Chafa:

If Ghostty requires special treatment, detect Ghostty and apply the treatment only to that terminal.

[AnonymouX47]

I have wanted to test the changes in that commit since but I've been procrastinating. I had been highly skeptical about the change since and kept it on my notifications list just so I don't forget.

So, I got to it after seeing this issue and it turns out the sequences on

https://github.com/hpjansson/chafa/blob/master/chafa%2Fchafa-term-db.c#L188-L189

don't actually enable/disable echo on any TE I tested (I was unable to test on the latest version of Ghostty though). Hence, breaking the existing behavior of chafa. I guess most TEs simply don't implement the sequences and those that do (like xterm and st as described by @veltza ) interpret it as not involving the PTY device.

That said, I agree with @veltza 's workaround. If that wouldn't work, then I feel leaving Ghostty users to --polite off is the best that can be done on chafa's end. By the way, there's a neater (on chafa's end, at least) workaround (see below) but I don't know how it'll be on the user's end.

Finally, I had actually put the blame for #236 on Ghostty in the first place. I'm not an expert but I can't seem to find any other TE that behaves as such, though I don't have access to iTerm2 (from which Ghostty got the inspiration) to test on. The underlying heuristic itself is rather questionable as there are applications that only disable echo (via termios) and have nothing to do with password or credential input.

Interestingly, Wezterm also has a similar feature but its heuristics seem to be better as its lock indicator doesn't come up for chafa.

---

While testing out this feature of Ghostty, I noticed the lock indicator isn't displayed whenever canonical input is also disabled i.e when the ICANON flag is also cleared. In other terms, stty -echo -icanon. So, maybe chafa can do this but like I said earlier, I don't know how it could affect things on the user's end.

[hpjansson]

Yeah, I found the same issue when testing with mlterm -- my initial fix is obviously wrong, but it was masked by VTE not enabling local echo when I tested it there.

Relevant snippets from ghostty:

.canonical = (attrs.c_lflag & c.ICANON) != 0,
.echo = (attrs.c_lflag & c.ECHO) != 0,

// We assume we're in some sort of password input if we're
// in canonical mode and not echoing. This is a heuristic.
const password_input = mode.canonical and !mode.echo;

So like you also discovered, we can fool it by disabling canonical mode too.

[hpjansson]

@veltza Sorry about the issue - it'll be fixed asap. In the meantime you can use --polite on to work around it.

[AnonymouX47]

@veltza Sorry about the issue - it'll be fixed asap. In the meantime you can use --polite on to work around it.

--polite off, you mean? 🤔

[hpjansson]

--polite off, you mean? 🤔

No, --polite on. It's polite to interfere as little as possible with terminal modes :-)

[veltza]

Thank you for your quick action!