> 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.
Of course we can't 100.00% guarantee this, there will always be non-conformant / buggy terminals. But we're emitting escape sequences that have a well-defined overall syntax (OSC .. ST) supposedly supported by all terminals, and supposedly ignored if the particular sub-number is unrecognized. Some of these numbers (e.g. 133 for shell integration) is shared between lots and lots of terminals. It is magnitudes more reliably supported, or at least silently ignored by terminals than those low-byte ASCII characters that do have some irrelevant historical (and nowadays unused) functionality assigned to them that we totally don't want to misuse. > Just create something that works for your terminal emulator, document > it as that, [...] That's what we want to do. We know exactly what we want to print. It happens to end in a backslash (unless the user appends something, which they should be able to do). Bash really doesn't make it easy for us. > 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 Again: First, it's not a no-op, I showed you side effects that are undesired in this context; and second, we can't use it if the user picked some non-UTF-8 charset. > you really should avoid > trying to be perfect, and just make something that works. If it's not perfect, there _will_ be users for whom it misbehaves. That's exactly what happened in the vte bugreport that in turn lead to this request here. We thought we had something that "works", turns out we were wrong, it ditn't work for some users. > | We do remember it as a combining accent and carry it if the data is > | copy-pasted. > > So? You said you'd be surprised if vte did anything but ignore the zero-width space. I showed that you were wrong. > 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. Koichi clearly used (3) to denote the step of eliminating these markers, and so did I. Now, with this notation, maybe what bash does now is not (1) (3) (2) as three consecutive steps, but rather (1&3) (2) as two consecutive steps, the functionality of (1) and (3) done by the same piece of code. This really doesn't matter and doesn't change the point. A certain prompt string might now end up vastly differently (like: variable expanded or not) depending on whether line editing is enabled or not. Sign of a pretty bad design in my book. > 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 documentation says that \[ and \] mark printable vs. non-printable characters in the prompt. Regardless of PS0 vs. PS1, regardless of readlne vs. noediting mode. (Surely, \[ \] are necessary helpers for the readline case, while unnecessary (but surely supposed to be harmless, right?) for the noediting case.) Only the implementation order (1) (2) (3) would match this. It's documented which quoted character does what. Not a single word about them behaving differently in PS0 vs. PS1, or differently in the readline vs. noediting mode. Yet the behavior does indeed differ. I cannot set up the prompt in a way that would end up appearing as the same string in all these contexts. And I'm supposed to accept it as intended by design... e.
