Hallo Ingo, i CC: the POSIX list since that is an interesting conclusion of yours!
Ingo Schwarze <[email protected]> wrote: |Ingo Schwarze wrote on Wed, Dec 23, 2015 at 07:44:05PM +0100: |>>> For example, colrm(1). |> So, remember this rule: |> |> +----------------------------------------------------------------+ |>| Backspace removes the previous character, no matter its width. | |> +--------++--------------------------------------------++--------+ ... POSIX says (p. 2773, l. 90953 ff.) In all known internationalized implementations, the utilities producing output for mixed column-width output assume that a <backspace> character backs up one column position and outputs enough <backspace> characters to return to the start of the character when <backspace> is used to provide local line motions to support underlining and emboldening operations. And your diff includes +.Pp +For compatibility with +.St -p1003.1-2008 +.Xr fold 1 , +if a double-width character is followed by two backspace characters +instead of the usual one, both are regarded as belonging to that +character, and the second one does not decrement the column count. Have you actually ever encountered anything that behaves like this in canonical mode? I have not, except that all tested terminals (a very restricted set, Thomas Dickey and Marc Lehmann, to name a few, would know much better than myself) do so in non-canonical mode. And that is weird enough given that they delete the glyph that makes up the double-width column and, in order to achieve that, place a space before the cursor. But i think POSIX text utilities behave in canonical mode, because beforehand the quote from above we read Although terminal input in canonical processing mode requires the erase character (frequently set to <backspace>) to erase the previous character (not byte or column position), terminal output is not buffered and is extremely difficult, if not impossible, to parse correctly; the interpretation depends entirely on the physical device that actually displays/prints/stores the output. So if this is true then i think this is even worth a POSIX issue? I repeat that i have not yet encountered any utility which behaves the way that POSIX describes and Ingo tries to address with special processing? --steffen
