On 6/12/26 12:01 PM, Egmont Koblinger wrote:
The solution to that is trivial, since it is "your users" who will be using this thing, which I take to mean users of the vte terminal emulator.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.
Surely there is at least one character or character sequence that behaves the same across all `interesting' terminals.
Rather than having to send some internal marker to the terminal and rely on the terminal ignoring that, the proper approach would be to only send to the terminal what we actually want to send.
Sure. The recent patch does that for PS0.
If we're fine with a vte-only solution and we expect vte to ignore certain bytes then bytes 0x01 or 0x02 (which \[ and \] map to) were already fine before the recent change. Anything before vs. after these bytes were kept separated all along the process. However, the recent change broke this.
Then the recent change `broke' nothing and you can terminate your PS0 with 0x02.
By eliminating them too early, i.e. before the promptvars expansion rather than after, it's possible for data to spill over across this boundary. That is, the fresh new behavior is not in any aspect better for us, but in a certain aspect (if we relied on the terminal ignoring the 0x01 / 0x02 markers) it is actually worse, the use of \[ \] in PS0 (which would end up as 0x01 0x02 bytes ignored by the terminal) is no longer a possible workaround for us to consider.
OK. You can, of course, add those bytes yourself rather than relying on bash to do it for you.
Simply append some character that vte will do nothing with when it receives itAs per above, it's not necessarily just vte. And there's no escape sequence I'm aware of that is documentedly a no-op.
It doesn't have to be an escape sequence. Since PS0 is simply written to the terminal, it could be a space followed by a destructive backspace. If you want to be fancy, use the stty erase character. That should work across terminals and character sets.
what do you do with a received \6 (ascii ack) ?We (vte) don't do anything. Other terminals might, e.g. Zutty prints a replacement symbol (just as it does for \1 or \2). But even if it was a no-op in all the terminals, it wouldn't justify its semantical misuse.
This is more of a purity argument than a practical one.
if you want to be able to work without the promotvars option enabled, which I wouldn't bother with, then you need to also find a solution which requires no variable expansions (etc) at output time.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'.
Well, that will reduce the number of cases.
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).
That's a fundamental misunderstanding of what the patch does.
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.
You're requesting a new feature. It gets evaluated the same way as any
other new feature request, including implementation cost.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
