cmd/acme: Alt button "sticks" sometimes after commit c1bd38a #3

qjcg · 2014-11-17T19:54:11Z

This was first reported on bitbucket (issue #128), and it is still an issue on a fresh INSTALL as of commit 08e7937.

Quoting from the original issue report:

After applying commit c1bd38a Acme sometimes has issues with Alt key "sticking". From my observations it often happens after returning to Acme from other windows. Clicking mouse B1 behaves as B2. Pushing and releasing Alt key while Acme window is active fixes the problem but it can return later after switching to another window and returning to Acme.

Applying the patch mentionned in the bitbucket issue comments does not fix the problem for me.

rsc · 2014-12-02T02:11:27Z

@rogpeppe Want to send a patch? See CONTRIBUTING.md.

Fixes 9fans#122. As reported in 9fans#122, file:1:1 moves to the end of the file, and file:1:2 fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches 2:3 using twocolonaddr (from plumb/fileaddr), then sets addr to `2-9fans#1+9fans#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: 1) find the range (q0, q1) that contains line 2 2) create the range (q2, q2) where q2 = q0 - 1 3) create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to _the end of the file_. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will _always_ be used. 1:1 is interpreted as 1-9fans#1+9fans#1 which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. 1:2 is interpretes as 1-9fans#1+9fans#2 which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. I can think of several ways to solve or work around this problem: 1) Let column numbers start from 0. Plumb/basic would use `-#0` when setting addr, which does not move the left side of the range and would not wrap around. This would require no changes to the code but could break compatibility with people’s setups. 2) Create a new address notation for this use case, like `line:column`. The problem is essentially that the plumbing rule transforms something that declares _intent_ into a sequence of operations that _should_ match that intent but which can run into unexpected conditions when interpreted. New notation would preserve the intention and could be interpreted accordingly. This would require changes to every program that interprets addr, so at least acme and sam, and to the plumbing rules. 3) Let forward character motion wrap around to the beginning of the file. The rule in plumb/basic assumes that moving backwards and then forwards by 1 character ends at the start of the previous selection. Letting forward motion wrap around restores this property when interpreting addresses. This would require changes to addr.c, but I’m not sure whether there are other pieces of software or people’s setups that assume that forward motion does _not_ wrap around. It also seems like it would blur the conceptual lines between the beginning and the end of a file, which seems undesirable. 4) Require empty ranges to enable wrapping, delay out of range errors. The wrapping currently occurs whenever the current range starts at position 0, although (what I imagine to be) the most common use case is negative motion starting from the initial empty range (0,0). If we restrict wrapping so it happens only when the range is (0,0), the motion sequence mentioned above would have an intermediate invalid state, a range (-1,-1), which would result in an out of range error. If we skip generating that error we will arrive at the correct position. Just skipping the error handling here would mean that textsetselect would handle those errors, and it currently adjusts ranges instead of generating error messages. If that is undesirable, we could add error handling at the end of address. Instead of wrapping from (0,0), wrapping could also require a flag to number that address initially sets to TRUE but sets to FALSE once it has left (0,0). This seems more explicit about when it would allow wrapping but it would prevent addresses like file:1-0-9fans#1 from wrapping to the end. This change implements 4).

@rsc

Fixes 9fans#122. As reported in 9fans#122, `file:1:1` moves to the end of the file, and `file:1:2` fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr), then sets addr to `2-9fans#1+9fans#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: find the range (q0, q1) that contains line 2 create the range (q2, q2) where q2 = q0 - 1 create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to the end of the file. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will always be used. `1:1` is interpreted as `1-9fans#1+9fans#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. `1:2` is interpretes as `1-9fans#1+9fans#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. @rsc proposed transforming `:X:Y` into `:X-#0+#Y-9fans#1` instead since that avoids wrapping around by not moving backwards at first. This change modifies `plumb/basic` to do that.

@rsc

Fixes 9fans#122. As reported in 9fans#122, `file:1:1` moves to the end of the file, and `file:1:2` fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr), then sets addr to `2-9fans#1+9fans#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: find the range (q0, q1) that contains line 2 create the range (q2, q2) where q2 = q0 - 1 create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to the end of the file. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will always be used. `1:1` is interpreted as `1-9fans#1+9fans#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. `1:2` is interpretes as `1-9fans#1+9fans#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. @rsc proposed transforming `:X:Y` into `:X-#0+#Y-9fans#1` instead since that avoids wrapping around by not moving backwards at first. This change modifies `plumb/basic` to do that.

@rsc

Fixes 9fans#122. As reported in 9fans#122, `file:1:1` moves to the end of the file, and `file:1:2` fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr), then sets addr to `2-9fans#1+9fans#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: find the range (q0, q1) that contains line 2 create the range (q2, q2) where q2 = q0 - 1 create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to the end of the file. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will always be used. `1:1` is interpreted as `1-9fans#1+9fans#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. `1:2` is interpretes as `1-9fans#1+9fans#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. @rsc proposed transforming `:X:Y` into `:X-#0+#Y-9fans#1` instead since that avoids wrapping around by not moving backwards at first. This change modifies `plumb/basic` to do that.

@rsc

Fixes 9fans#122, 9fans#140. As reported in 9fans#122, `file:1:1` moves to the end of the file, and `file:1:2` fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr), then sets addr to `2-9fans#1+9fans#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: 1. find the range (q0, q1) that contains line 2 2. create the range (q2, q2) where q2 = q0 - 1 3. create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to the end of the file. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will always be used. `1:1` is interpreted as `1-9fans#1+9fans#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. `1:2` is interpretes as `1-9fans#1+9fans#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. In 9fans#140 @rsc proposed transforming `:X:Y` into `:X-#0+#Y-9fans#1` instead since that avoids wrapping around by not moving backwards at first. This change modifies `plumb/basic` to do that.

@rsc

Fixes #122, #140. As reported in #122, `file:1:1` moves to the end of the file, and `file:1:2` fails with “address out of range”. I’ll use file:2:3 as an example so we can tell the line and column number apart. What’s happening is this: plumb/basic matches `2:3` using twocolonaddr (from plumb/fileaddr), then sets addr to `2-#1+#3` (the 1 is constant and was introduced because column numbers are 1-based). Acme interprets this in three steps: 1. find the range (q0, q1) that contains line 2 2. create the range (q2, q2) where q2 = q0 - 1 3. create the range (q3, q3) where q3 = q2 + 3 The second step has a branch where if q0 == 0 and 1 > 0 (remember that 1 is constant and comes form plumb/basic), q0 is set to the end of the file. This makes addressing things at the end of the file easier. The problem then is that if we select line 1, which starts at the beginning of the file, q0 is always 0 and the branch in step 2) will always be used. `1:1` is interpreted as `1-#1+#1` which starts at 0, wraps around to the end of the file, then moves 1 character backwards and then forwards again, ending at the end of the file. `1:2` is interpretes as `1-#1+#2` which starts at 0, wraps around to the end od the file, then moves 1 character backwards and tries moving 2 characters forwards beyond the end of the file, resulting in the out of range error. In #140 @rsc proposed transforming `:X:Y` into `:X-#0+#Y-#1` instead since that avoids wrapping around by not moving backwards at first. This change modifies `plumb/basic` to do that.

Report an "address out of order" error instead of crashing, e.g. when running 9 echo -n '9fans#3,9fans#2' | 9p write acme/$winid/addr 9 echo -n 'dot=addr' | 9p write acme/$winid/ctl or 9 echo -n '0/yyy/,0/xxx/' | 9p write acme/$winid/addr 9 echo -n 'dot=addr' | 9p write acme/$winid/ctl with `acme/$winid/body` set to xxx yyy

Report an "address out of order" error instead of crashing, e.g. when running 9 echo -n '9fans#3,9fans#2' | 9p write acme/$winid/addr 9 echo -n 'dot=addr' | 9p write acme/$winid/ctl or 9 echo -n '0/yyy/,0/xxx/' | 9p write acme/$winid/addr 9 echo -n 'dot=addr' | 9p write acme/$winid/ctl with `acme/$winid/body` xxx yyy

qjcg changed the title ~~Alt button "sticks" in Acme sometimes after commit c1bd38a~~ cmd/acme: Alt button "sticks" sometimes after commit c1bd38a Dec 5, 2014

detuma mentioned this issue Sep 29, 2018

Open programs in same window #184

Closed

rsc closed this as completed in 1d0d432 Jan 16, 2020

neosimsim mentioned this issue Apr 17, 2021

acme: validate address range, when writing to addr #382

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/acme: Alt button "sticks" sometimes after commit c1bd38a #3

cmd/acme: Alt button "sticks" sometimes after commit c1bd38a #3

qjcg commented Nov 17, 2014

rsc commented Dec 2, 2014

cmd/acme: Alt button "sticks" sometimes after commit c1bd38a #3

cmd/acme: Alt button "sticks" sometimes after commit c1bd38a #3

Comments

qjcg commented Nov 17, 2014

rsc commented Dec 2, 2014