Date: Fri, 12 Jun 2026 18:01:04 +0200
From: Egmont Koblinger <[email protected]>
Message-ID:
<cagwczkkq1c-jmpkjmtasvgwi7rpkeqq5hgybc2m3o6xtkww...@mail.gmail.com>
| Normally, yes. However, occasionally users of other terminals might
| also use this PS0 (if they launch another terminal from a vte-based
| one). Therefore, ideally, we'd look for a solution that robustly
| works in all terminals.
Sorry, but that makes no sense at all - you're already generating some
magic string that does something useful (I presume) for vte, and that's
fine - but you can't possibly be believing that that string will do the
same, or be ignored, on all other terminals.
Just create something that works for your terminal emulator, document
it as that, and tell users to set PS0 to your string (if they desire)
when using vte, not to export it, or expect it to work sanely if used
in any other environment.
| As per above, it's not necessarily just vte. And there's no escape
| sequence I'm aware of that is documentedly a no-op.
But since you can handle (I presume) UTF-8 output, there should be the
zero width space character (ZWSP, or $'\u0200'), which isn't an escape
sequence, nor a control char. Then if some other terminal that happens
to get it sent to it, does anything other than print zero width space
(ie: nothing) it is defective, but as above, you really should avoid
trying to be perfect, and just make something that works.
| We do remember it as a combining accent and carry it if the data is
| copy-pasted.
So?
| Similarly, searching the buffers for the sequence of the
| preceding and the subsequent character right next to each other
| (without that intermediate zero-width space) won't find that match.
It is to be inserted between your magic string (which I assume is entirely
terminal control sequences, and not saved that way) and the the start of
the user's output - ie: at the beginning of what is PS0's potentially
visible output, and before the actual command line which follows.
Who is going to be searching for something that includes that?
| One day if we'll have ligature support then it might even affect rendering.
Same thing.
| This made me realize that we indeed do already rely on promptvars
| elsewhere (in PS1's value). If vte's main dev agrees with me, we'll
| probably set it in stone to require 'promptvars'.
Seems sensible to me.
| Using Koichi's numbering, prompt strings were typically processed
| through steps (1) (2) (3), but sometimes only through (1) (2). We
| asked to unify the situation. Instead, the latter case was modified
| to process it through steps (1) (3) (2).
No, what (1) produced was modified, so (3) would not be required in the
situations it would not occur, and stray noise chars would not be produced.
It is still (1) and (2), which is all bash ever does, (3) is readline.
| We followed up with the request of turning the latter to the same
| sequence of (1) (2) (3), pointing out weird inconsistencies resulting
| from the wrong order. This followup request of ours was met with a
| resistance we absolutely do not understand.
Because it is simply the wrong thing to do. The shell shouldn't be
arbitrarily removing data from the user's prompt in situations not
documented to do that. That it might make your life simpler isn't
a good enough reason for that.
| The new order of (1) (3) (2) is not in any way better for us than the
| old order of (1) (2), in fact, in some aspect it's even worse. If you
| guys are reluctant to print the same prompt in the readline vs.
| noediting cases then you might even consider reverting the recent
| half-baked workaround, it's of no use for us, we'll need to find a
| different way of navigating through all the possible different
| behaviors of bash.
First, I'm not one of the "you guys", I have never even looked inside
bash's code - but no change was made for you - rather you reported a bug,
(which it really was) and the bug was fixed in the correct way. No-one
is going to re-introduce the bug because the solution wasn't what you
imagined it might be.
kre
