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

Let string handle displayed width #8182

Merged
merged 7 commits into from
Aug 4, 2021
Merged

Conversation

faho
Copy link
Member

@faho faho commented Jul 29, 2021

Description

This makes string pad pad to the effective width without escape sequences we recognize, and it adds an option --visible to string length that makes it show the visible length in terminal cells (or width, if you prefer).

This is, of course, necessarily imperfect. We're not the terminal, we don't know which escape codes it recognizes exactly. But we do handle the most common ones like colors and such.

This also changes in response to $TERM, $fish_emoji_width and $fish_ambiguous_width.

Importantly: string length --visible handles carriage return and line feed in what I hope is a sensible manner. Because counting a string like

abcdef\r123

as anything other than a width of 6 seems useless to me. The line feed handling may be surprising because it might print multiple lines of output in response to a single argument, but I also don't see how anything else would help.

It would also be possible to make string length --visible a separate command instead, but given how similar these operations are I'm not sure that helps. Or we could change the option to --width, but that doesn't include that it also removes escape sequences.

Fixes issue #7784.

TODOs:

  • Changes to fish usage are reflected in user documentation/manpages.
  • Tests have been added for regressions fixed
  • User-visible changes noted in CHANGELOG.rst

@faho faho added this to the fish 3.4.0 milestone Jul 29, 2021
@IlanCosman
Copy link
Contributor

Also: closes #4012 I believe.

@faho
Copy link
Member Author

faho commented Jul 30, 2021

Do we want string pad to require --visible as well?

@IlanCosman
Copy link
Contributor

I'd say it should probably be on by default for string pad, because that command is used for formatting things nicely in the terminal. I can't imagine a reason you'd want to account for non-visible characters with it.

@faho
Copy link
Member Author

faho commented Aug 1, 2021

Okay, this still needs adjustment in pad, for CR runs.

E.g.

string pad -w 4 ab\rfoo

has a maximum width of 3, but we would pad from the beginning, so we influence a run with a width of 2. So we need to add 2 spaces. If we padded to the right, we would need 1 space.

Uncached, but we don't want to keep this globally, I think?

This is useful for doing string pad/length without escapes.
This just changes it so it subtracts escape sequences, according to
the current terminal.
Without escapes.

The new option is a bit cheesy, but "width" isn't as expressive and
requires an argument.

Maybe we want "pad" to also require --visible?
Because we are, ultimately, interested in how many cells a string
occupies, we *have* to handle carriage return (`\r`) and line
feed (`\n`).

A carriage return sets the current tally to 0, and only the longest
tally is kept. The idea here is that the last position is the same as
the last position of the longest string. So:

abcdef\r123

ends up looking like

123def

which is the same width as abcdef, 6.

A line feed meanwhile means we flush the current tally and start a new
one. Every line is printed separately, even if it's given as one.

That's because, well, counting the width over multiple lines
doesn't *help*.

As a sidenote: This is necessarily imperfect, because, while we may
know the width of the terminal ($COLUMNS), we don't know the current
cursor position. So we can only give the width, and the user can then
figure something out on their own.

But for the common case of figuring out how wide the prompt is, this
should do.
@faho faho merged commit 3ed4930 into fish-shell:master Aug 4, 2021
@faho
Copy link
Member Author

faho commented Aug 4, 2021

Alright, let's do the additional pad stuff later. It's probably overly completionist anyway. Merged.

@IlanCosman
Copy link
Contributor

It's probably overly completionist anyway. Merged.

Good call 👍 Thanks for working on this Fabian 😄

@faho faho deleted the string-pad-escapes branch September 23, 2021 09:36
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 26, 2022
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants