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

Line wrapping results in blank first line #5118

Closed
mqudsi opened this issue Jul 29, 2018 · 15 comments
Closed

Line wrapping results in blank first line #5118

mqudsi opened this issue Jul 29, 2018 · 15 comments

Comments

@mqudsi
Copy link
Contributor

mqudsi commented Jul 29, 2018

Line wrapping seems to be broken for the first line of shell text, upon wrap the entire contents are shifted to a new line rather than at the end of the prompt.

I haven't had a chance to check it against 2.7.1 but I'm pretty sure this is a regression; this behavior feels different from what I'm used to.

This is probably best illustrated with a recording: https://asciinema.org/a/EoICnLy8zF9VRefsAf1LHJ1Yk

@ridiculousfish ridiculousfish added this to the fish-3.0 milestone Aug 4, 2018
@ridiculousfish
Copy link
Member

Can you try git bisecting it?

@faho
Copy link
Member

faho commented Sep 10, 2018

@mqudsi: Ping?

Does this still happen to you? I don't think anybody else has been able to reproduce it.

@mqudsi
Copy link
Contributor Author

mqudsi commented Sep 16, 2018

It still happens, and on multiple machines too. I need to get around to bisecting it, I didn't want to do that on my slower machine given configure and build times.

@mqudsi
Copy link
Contributor Author

mqudsi commented Sep 19, 2018

OK, this drove me nuts trying to pin it down! One minute it would bisect to something that makes no sense, such as @zanchey updating the changelog and the next it would reproduce with fish 2.0! To make matters worse, I tried on my MacBook thinking it could be a conemu glitch (though I knew that couldn't be the case, as it reproduces in the asciinema in my initial report, which means it's more or less interpretation of the shell output) and was able to reproduce it there, too.

It turns out this only happens if $COLUMNS is less than 77. At 76 columns wide or less, upon reaching the end of the terminal display the entire contents of the line are shifted down to the next row. And this behavior has been the case since at least version 2.0.

@mqudsi
Copy link
Contributor Author

mqudsi commented Sep 19, 2018

I imagine this is the code responsible: https://github.com/fish-shell/fish-shell/blob/master/src/screen.cpp#L988

@faho
Copy link
Member

faho commented Sep 19, 2018

That actually seems like it's intended to work that way. Would you like that to be changed, and if so how?

@mqudsi
Copy link
Contributor Author

mqudsi commented Sep 19, 2018

I don't think there's a need for that extra functionality at all? Given that this behavior was foreign to all of us and it only kicks in when the left prompt takes up 33% of the terminal width and a subsequent argument is entered that would softwrap, I think it's unnecessary and just makes the behavior of the shell confusing/unexpected.

Content either fits on the line or it doesn't. If the left prompt wants an entire line for itself, so be it. But for text that fit (and was followed by whitespace) to be wrapped around to the next line just because I entered another argument afterwards.. the behavior just doesn't add up.

How do you guys feel about that?

@faho
Copy link
Member

faho commented Sep 20, 2018

Have a look at #904, in which people asked for the prompt to either wrap or truncate if the terminal is too small.

Sounds like this is supposed to essentially do that, but doesn't do a good job of it.

@mqudsi
Copy link
Contributor Author

mqudsi commented Sep 20, 2018

I think that is different functionality because this doesn’t kick in until the command line reaches the terminal edge (and notably doesn’t affect the prompt at all, only the text). But thanks for linking that issue, I do think any resolution for this should take that into account.

@faho faho modified the milestones: fish-3.0, fish-future Oct 21, 2018
@faho
Copy link
Member

faho commented Oct 21, 2018

Okay, this doesn't have to be in 3.0.

@floam
Copy link
Member

floam commented Nov 7, 2018

Hm. I kinda like the current behavior - it's easier to read a long line if it's not broken up into two lines with a large prompt.

@mqudsi
Copy link
Contributor Author

mqudsi commented Nov 8, 2018

The entire premise is weird, though. "The terminal window is too narrow.. instead of trying to smush things up to save space, let's waste space instead!"

But all that aside, the problem is that it moves text that it has no business moving. The text is already written, it's disconcerting to see it all move around the screen to where you're not expecting it. The UX for reaching the end of a line is well-understood and this breaks with how fish handles this in all other cases. Look at how long it took us to figure out what was even going on - it's such a hard break (no pun intended) from the prevalent behavior everywhere else in fish when it comes to line wrapping. It's jarring and it's inconsistent (e.g. why should this behavior only happen at 77 columns and not 78 columns?).

@floam
Copy link
Member

floam commented Nov 9, 2018

I think the premise works a little better if you frame it as "the prompt has gotten too wide" versus "the terminal window is too narrow" - it's not based on the terminal window being under a certain size, depending on your prompt length, the cutoff could be over 80. The prompt can get really long if you're deep in some directory, every command you enter getting split up by word-wrapping early is kinda jarring.

@floam
Copy link
Member

floam commented Nov 9, 2018

It's not specifically 78 columns, but 33%. If your prompt is wider than 33% of the terminal width then it will start this wrapping behavior. Do you think you would be helped if we adjusted that? I mean, do you think that if there are only for example 10 characters left next to the prompt in the window, it's definitely nicer to wrap like this? At that length you wouldn't even be able to read many command names easily let alone the arguments. So what should the cutoff be?

@faho faho closed this as completed in 0f7e2ca Sep 27, 2020
@faho
Copy link
Member

faho commented Sep 27, 2020

Okay, I just removed the functionality since it's more confusing than helpful.

@faho faho modified the milestones: fish-future, fish 3.2.0 Sep 27, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants