Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Junk before prompt at FreeBSD vty with sc driver #5552

Closed
mqudsi opened this issue Jan 19, 2019 · 8 comments
Closed

Junk before prompt at FreeBSD vty with sc driver #5552

mqudsi opened this issue Jan 19, 2019 · 8 comments
Labels
bug
Milestone

Comments

@mqudsi
Copy link
Contributor

@mqudsi mqudsi commented Jan 19, 2019

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):

image

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

easyre deployment freebsd 12 -2019-01-18-18-26-44

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
Copy link
Member

@floam floam commented Jan 19, 2019

I think that's the omitted newline character.

@mqudsi
Copy link
Contributor Author

@mqudsi mqudsi commented Jan 19, 2019

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
Copy link
Member

@faho faho commented Jan 19, 2019

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.

@zanchey zanchey added this to the fish-future milestone Jan 19, 2019
@zanchey zanchey added the bug label Jan 19, 2019
@floam
Copy link
Member

@floam floam commented Jan 19, 2019

@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
Copy link
Member

@floam floam commented Jan 19, 2019

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
Copy link
Contributor Author

@mqudsi mqudsi commented Jan 23, 2019

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

image

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
Copy link
Member

@floam floam commented Jan 24, 2019

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
Copy link
Contributor Author

@mqudsi mqudsi commented Jan 27, 2019

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.

@faho faho removed this from the fish-future milestone Mar 26, 2019
@faho faho added this to the fish 3.1.0 milestone Mar 26, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug
Projects
None yet
Development

No branches or pull requests

4 participants