Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sat, Mar 30, 2024 at 01:59:28AM +0100, Storkman wrote: > On Fri, Mar 29, 2024 at 07:27:43PM +0100, Hiltjo Posthuma wrote: > > On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > > > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > > > Author: Quentin Rameau > > > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > > > Commit: Hiltjo Posthuma > > > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > > > > > Fix cursor move with wide glyphs > > > > > > > > st would always move back 1 column, > > > > even with wide glyhps (using more than a single column). > > > > > > This is apparently what GNU readline expects, so this change breaks > > > line editing, which worked fine before. > > > > > > -- > > > Storkman > > > > > > > Hi, > > > > Can anyone confirm? Preferably with a small example test-case? > > > > Thank you! > > > > -- > > Kind regards, > > Hiltjo > > > > For a specific example, copy text followed by a wide glyph into bash > or mksh, e.g. > A字 > and press backspace once. Both characters will be erased. > > In xterm, "\b" also moves the cursor by one column: > > $ printf "A字\bB\n" > A B > > st after this patch: > > $ printf "A字\bB\n" > AB > > -- > Storkman > Thank you, I've reverted the original patch (with some archived notes) for now. If anyone wants to work on improving the patch, feel free to do so :) -- Kind regards, Hiltjo
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On 24/03/30 01:59AM, Storkman wrote: > For a specific example, copy text followed by a wide glyph into bash > or mksh, e.g. > A字 > and press backspace once. Both characters will be erased. Or, when using tmux, split vertically, then in the right pane copy the above text and press left arrow twice, then right arrow twice. The text will move to the left, "spilling" into the left pane! Fun times. signature.asc Description: PGP signature
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Fri, Mar 29, 2024 at 07:27:43PM +0100, Hiltjo Posthuma wrote: > On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > > Author: Quentin Rameau > > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > > Commit: Hiltjo Posthuma > > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > > > Fix cursor move with wide glyphs > > > > > > st would always move back 1 column, > > > even with wide glyhps (using more than a single column). > > > > This is apparently what GNU readline expects, so this change breaks > > line editing, which worked fine before. > > > > -- > > Storkman > > > > Hi, > > Can anyone confirm? Preferably with a small example test-case? > > Thank you! > > -- > Kind regards, > Hiltjo > For a specific example, copy text followed by a wide glyph into bash or mksh, e.g. A字 and press backspace once. Both characters will be erased. In xterm, "\b" also moves the cursor by one column: $ printf "A字\bB\n" A B st after this patch: $ printf "A字\bB\n" AB -- Storkman
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Wed, Mar 27, 2024 at 04:11:27PM +0100, Storkman wrote: > On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > > Author: Quentin Rameau > > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > > Commit: Hiltjo Posthuma > > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > > > Fix cursor move with wide glyphs > > > > st would always move back 1 column, > > even with wide glyhps (using more than a single column). > > This is apparently what GNU readline expects, so this change breaks > line editing, which worked fine before. > > -- > Storkman > Hi, Can anyone confirm? Preferably with a small example test-case? Thank you! -- Kind regards, Hiltjo
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5 > Author: Quentin Rameau > AuthorDate: Sun Feb 25 01:31:31 2024 +0100 > Commit: Hiltjo Posthuma > CommitDate: Sun Feb 25 11:56:43 2024 +0100 > > Fix cursor move with wide glyphs > > st would always move back 1 column, > even with wide glyhps (using more than a single column). This is apparently what GNU readline expects, so this change breaks line editing, which worked fine before. -- Storkman
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
On Sun Feb 25, 2024 at 8:13 AM CST, Quentin Rameau wrote: > Would you have a suggestion about how to handle cursor absolute > position with text position, maybe we need some addition state? I would suggest that cursor position control sequences should always operate on a single-column basis. This is in line with every other terminal that handles wide characters. It is up to the application running in the emulator to know where it wants to position the cursor. For example, the command below should move the cursor into the emoji but the second `\e[D` should have not *visual* change, but the cursor is actually in the "first" column of the emoji printf " 😀" && sleep 2 && printf "\e[D" && sleep 2 && printf "\e[D" && sleep 2 Just my two cents. -- Tim
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
> Hi, Hola k0ga, > > st would always move back 1 column, > > even with wide glyhps (using more than a single column). > > > > The glyph rune is set on its first column, > > and the other ones are to 0, > > so loop until we detect the start of the previous glyph. > > Should this be done in every cursor addressing command? > What happens if we position the cursor in the middle of a glyph? That's a preliminary patch to encourage improving the matter, I suspect there might be some unhandled side-effects in some perticular cases, when using arbitrary cursor movement for example, though it's unclear if those should be handled separately or not. Would you have a suggestion about how to handle cursor absolute position with text position, maybe we need some addition state?
Re: [hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
Hi, On Sun, Feb 25, 2024 at 11:57:03AM +0100, g...@suckless.org wrote: > st would always move back 1 column, > even with wide glyhps (using more than a single column). > > The glyph rune is set on its first column, > and the other ones are to 0, > so loop until we detect the start of the previous glyph. Should this be done in every cursor addressing command? What happens if we position the cursor in the middle of a glyph? Kind regards,
[hackers] [st] Fix cursor move with wide glyphs || Quentin Rameau
commit 7473a8d1a57e5f9aba41b953f4e498c35e1c9dc5
Author: Quentin Rameau
AuthorDate: Sun Feb 25 01:31:31 2024 +0100
Commit: Hiltjo Posthuma
CommitDate: Sun Feb 25 11:56:43 2024 +0100
Fix cursor move with wide glyphs
st would always move back 1 column,
even with wide glyhps (using more than a single column).
The glyph rune is set on its first column,
and the other ones are to 0,
so loop until we detect the start of the previous glyph.
diff --git a/st.c b/st.c
index 034954d..77c3e8a 100644
--- a/st.c
+++ b/st.c
@@ -86,8 +86,8 @@ enum escape_state {
typedef struct {
Glyph attr; /* current char attributes */
- int x;
- int y;
+ int x; /* terminal column */
+ int y; /* terminal row */
char state;
} TCursor;
@@ -2175,12 +2175,16 @@ tstrsequence(uchar c)
void
tcontrolcode(uchar ascii)
{
+ size_t i;
+
switch (ascii) {
case '\t': /* HT */
tputtab(1);
return;
case '\b': /* BS */
- tmoveto(term.c.x-1, term.c.y);
+ for (i = 1; term.c.x && term.line[term.c.y][term.c.x - i].u ==
0; ++i)
+ ;
+ tmoveto(term.c.x - i, term.c.y);
return;
case '\r': /* CR */
tmoveto(0, term.c.y);
