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

Non consuming escapes #23

Open
blaggacao opened this issue Sep 29, 2020 · 3 comments
Open

Non consuming escapes #23

blaggacao opened this issue Sep 29, 2020 · 3 comments

Comments

@blaggacao
Copy link

For manipulating prompts, it is necessary to mark characters as non-greedy (not consuming a space in the column calculation of the tty).

Here is an example how this is done for bash and zsh. Maybe this is in scope for the ultimate color library?

https://github.com/jonmosco/kube-ps1/blob/master/kube-ps1.sh#L57-L73

@logrusorgru
Copy link
Owner

Sorry, what is it?

@blaggacao
Copy link
Author

blaggacao commented Oct 10, 2020

With non-greedy, a word I borrowed lacking a better term from the regex world, i refer to control characters that at the same time do not consume a column. By consume, I mean that any specfic shell does not count such caracters as occupying a column space in the total available columns of a line.

A control character which "consumes" a column sabotages a specifix shell's calculation towards the remaining available columns.

This is relevant for colorizing prompts, since if control characters add up towards the column count the coursor is offset too much, which eigher leads additional white spaces if the offending control chars are on the left or a cursor that overlays the left side prompt if the offending control characters are on the right, such as in zsh's RPROMPT.

The gist of it is that the actual implementation of escaping the control chars appropriately is shell specific.

For zsh, for example, anything between %{ & %} does not count towards column count.
For bash it appears to be $'\001' & $'\002'.

I am best guessing that this behaviour is only relevant when colorizing prompts, so it might be necesary to implement some notion of a "prompt mode". But I could be wrong on this and generally escaping control chars would do no harm.

The shell probably would need to be deduced from well known environment variables.

Alternative wording:

put all special codes inside %{...%} brackets to treat code literally and prevent unwanted moving of the cursor position

https://stackoverflow.com/a/30581694

@logrusorgru
Copy link
Owner

logrusorgru commented Oct 8, 2022

I'm keeping one eye on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants