Add "string shorten" command to shorten strings with an ellipsis #9156
Conversation
|
Oh, also it removes the ellipsis from a shortened SHA. I think it's obvious that a sha of 8 characters isn't complete, and so saving one column is actually the better idea. (plus that code never checked that the codepoint was usable) |
|
Wow, Fabian adding the things I didn't know I wanted, but now do 😄 One thing I'd like to see is an option that truncates the beginning instead of the end. I.e Also, I'd go with a more generic name like
|
Done. This is kind of tricky because we need to skip escapes and need to be careful to not hack combiners into pieces, so actually going from the end is hard. So I just went front to back and stopped once the width to the end fits. This does a bunch more checks than is needed, but tbh that can be done later.
Oh, it is actually used! You have:
On the other hand you have python with textwrap.shorten in the stdlib, and an example for how to "Truncate String with Ellipsis" in CSS. My issue with "truncate" is that, to me, it only speaks to the "cutting off" part and is still not the easiest term? "shorten" might be okay, but there we need to explain that we add an ellipsis (which python's textwrap calls a "placeholder" which I don't like?)
Just as a sidenote: "ellipsis" comes from a greek term. That means in a bunch of western languages it will also be used - I know "ellipse" is a thing in german. So how "difficult" a term seems for native speakers doesn't always match how it seems for non-native speakers, because it might also be in their language. In this specific case that's because it's a loan word, but e.g. non-native speakers might have a harder time with everyday kitchen terminology than grammar terminology. |
|
It's easy to forget @faho is German, considering his perfect use of English. |
|
I like it. I initially had some thoughts that |
|
I'm not sure how fancy you want to get, but another option that people sometimes like is truncating the middle, |
|
My gut instinct on reading the title was "why not just |
|
It's probably a small subset of the population that knows what the word means, and then us turning it into a verb-command because we happen to be ultra-familiar with the jargon - I agree. Probably The counterargument is that people inevitably learn what an ellipsis is when they realize they need to use a command called |
|
In terms of prior art... Back in another life, I used to use the terribly named https://docs.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathcompactpathw |
|
Alright, I renamed it to "shorten". It's shorter and simpler, and we don't need to be 100% accurate - people will figure out that it adds an ellipsis once they use it. |
faho
changed the title
|
One more yak-shaving question: I've named the option to keep text from the end "--right".
Should this be "--left" instead? My intuition was that I think of shortening as "go from the left/right, keep until you can't keep any more and then stop", while I think of padding as "add to the left/right until it's full". |
|
I'm torn, but I'd say |
This is essentially the inverse of `string pad`.
Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and `length --visible`, it goes by visible width,
skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
This checked the locale, but did so in a way that's fundamentally broken: 1. $LANG isn't the only variable ($LC_ALL and $LC_CTYPE) 2. Even if $LANG is set that doesn't mean it's actually working We could add a `status is-multibyte` here to figure out if we have a multibyte locale? But instead, since this is dealing with adding an ellipsis, let's just add it to `string ellipsize`. One slight difference is that shortening the branch now counts the ellipsis width. I.e. assuming the branch is "long-branch-name" ```fish set -g __fish_git_prompt_shorten_branch_len 8 ``` might now print "long-br…" instead of "long-bra…". This is nicer because we can now give the actual maximum width. The alternative is to add a "--exclusive" option to "string ellipsize" that doesn't count the ellipsis width. So `string ellipsize --char "..." --max 8" long-branch-name` might result in "long-bra...", which is 11 wide.
|
Okay, renamed to "--left" - the idea is that we name it after where we change the string, like in And with that, I'm merging this. |
Description
This is essentially the inverse of
string pad.Where that adds characters to get up to the specified width,
this adds an ellipsis to a string if it goes over a specific maximum width.
The char can be given, but defaults to our ellipsis string.
("…" if the locale can handle it and "..." otherwise)
If the ellipsis string is empty, it just truncates.
For arguments given via argv, it goes line-by-line,
because otherwise visible length makes no sense.
If "--no-newline" is given, it adds an ellipsis instead and removes all subsequent lines.
Like pad and
length --visible, it goes by visible width,skipping recognized escape sequences, as those have no influence on width.
The default target width is the shortest of the given widths that is non-zero.
If the ellipsis is already wider than the target width,
we truncate instead. This is safer overall, so we don't e.g. move into a new line.
This is especially important given our default ellipsis might be width 3.
We use this in numerous places including fish_job_summary and the git prompt and completions, but we do that in a fundamentally broken way, and it's already a bit complicated:
This already adopts it in those places. It mostly behaves the same, except for one difference in the git prompt when shortening the branch. The original code took $len chars and then added the ellipsis, so a length of 8 could end up printing a length of 10 (and a width of potentially 8*2 + 2 = 18). This takes as many chars as we can so that we can add the ellipsis and keep under the target width. So people will potentially see their git branch names shortened more - typically 1 char so the unicode ellipsis fits.
It also uses "..." as the ellipsis string on singlebyte systems instead of "..". I'd argue that we should probably change our default fallback ellipsis string to "..", but that's a separate change.
TODOs:
Potential questions:
--charactually takes a string (unlikestring pad, which really just allows a single codepoint)string pad.