Junk before prompt at FreeBSD vty with sc driver

[mqudsi]

This has bugged me for a while but I've never filed it. On the "physical" vty under FreeBSD, fish emits some invalid/unrecognized character codes that appear as garbled letters before each fish_prompt call.

Here's a screenshot (clean fish install from master):

If using the new vt (aka newcons) console driver (used by KMS drivers and the UEFI framebuffer), the problem goes away:

It's not a huge deal since vt is the default on FreeBSD 11 and up, but sc is still supported (and required if you want to use a driver without KMS support).

However, it bugs me because there's nothing funky in the default prompt that should result in this behavior in the first place, as it's all ascii and standard color escapes (which seem to be working fine). The default $TERM at the console is xterm for both drivers, and the problem persists under tmux where $TERM defaults to screen instead.

[floam]

I think that's the omitted newline character.

[mqudsi]

Why would that be triggered in the default prompt, though? Unless it's the "always emit then try to hide it" problem showing up.

[faho]

The default $TERM at the console is xterm for both drivers

Yeah, but they don't act like xterm.

Honestly, this just seems like a bad terminal to me. Which is why there's a replacement.

If you really want, figure out a way to detect this thing, and then we can hardcode it where we print the omitted newline char.

[floam]

@mqudsi It wouldn't be coming from the prompt. I don't think you'll see it before the first printed prompt. It will happen after things are executed. The way the character works is that it's always emitted but yes, hidden, unless the last thing printed did not have a newline after it.

[floam]

And so there are two issues you're seeing with the old console driver: it can't render the glyph, and also it is always shown.

In the newer console if you do a printf foo, do you see those two incorrect characters or something that actually renders? Possibly you'd want a fallback to a simpler symbol that the FreeBSD console can render no problem, like the paragraph symbol perhaps.

[mqudsi]

The character doesn't print correctly (renders as a single question mark) on the vt console, but otherwise does not normally appear:

I already changed the only two non-ansi characters fish has hardcoded when compiled under WSL, the pilcrow (paragraph marker) is actually what I'm using there and IMHO it is a better choice overall as it is supported by most vts, pretty much required to be found in all fonts (which is the problem under Windows), and conveys the right semantics. As for the second symbol, there's absolutely no reason for us to use the funky bullet we use when 0x2022 does the job perfectly and is again supported pretty much everywhere.

Anyway, as for the problem under sc: there's another discussion about this, I think @krader1961 dug into it at the time (but for a different terminal). The finding was that ZFS changed from the way we do it to some other approach and no longer runs into this problem. If I remember correctly, this has something to do with where the cursor is past the last column and some terminals keep it in column 80/81 and others move it to the next line or something.

[floam]

I agree on the read obfuscation character - \u2022 renders just as nicely here and is more likely to be supported by various fonts. I think that can be changed across the board.

I agree that the pilcrow is ideal for a lot of situations due to how many kernel's consoles always have the glyph, however our current glyph I like more on terminal emulators with basically any fonts available. We've used it for a long, long time with not many complaints of missing glyphs. Maybe we could guess based on if it seems we're in a vt or not (by looking for a lack of fancy terminfo attributes?).

[mqudsi]

The related issues are #789 and #3672. In particular, the discussion in #789 contains valuable information that may possibly be used to better improve the detection of end-of-line behavior or else to force it.