thisisparker / cursewords

:pencil: Terminal-based crossword puzzle solving interface
GNU Affero General Public License v3.0
249 stars 30 forks source link

Backspace and Delete should behave differently #21

Closed thisisparker closed 3 years ago

thisisparker commented 5 years ago

Both keys should blank out the value currently under the cursor, but backspace should retreat the cursor and delete should advance it. There's some documented wacky behavior with these keys in blessed but I haven't been able to get to the bottom of it.

In preliminary testing, both keys (on my box) appear to send keystrokes with the name KEY_DELETE and the corresponding code. However, these two keystrokes do not evaluate as equal. (Consecutive presses of backspace evaluate as equal to each other, as do consecutive presses of delete.) I haven't been able to pin down the property that differentiates the two, and it's not name or code, but that inequality leads me to believe there might be a way to distinguish.

I would welcome tips from the likes of @jquast or @thomasballinger, but also I can try to figure this out on my own!

jquast commented 5 years ago

It’s just your terminal emulator’s or a bash_profile-like “stty” setting, look for “backspace sends delete” etc. if you have the right keyboard and emulator then blessed detects the difference, use contrl+h to manually generate one of them, and the integer input 127 to generate the other

Sent from my iPhone

On Mar 16, 2019, at 1:33 PM, Parker Higgins notifications@github.com wrote:

Both keys should blank out the value currently under the cursor, but backspace should retreat the cursor and delete should advance it. There's some documented wacky behavior with these keys in blessed but I haven't been able to get to the bottom of it.

In preliminary testing, both keys (on my box) appear to send keystrokes with the name KEY_DELETE and the corresponding code. However, these two keystrokes do not evaluate as equal. (Consecutive presses of backspace evaluate as equal to each other, as do consecutive presses of delete.) I haven't been able to pin down the property that differentiates the two, and it's not name or code, but that inequality leads me to believe there might be a way to distinguish.

I would welcome tips from the likes of @jquast or @thomasballinger, but also I can try to figure this out on my own!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

jquast commented 4 years ago

These keys may be better distinguished now, since 1.17.0, https://github.com/jquast/blessed/releases/tag/1.17.0

thisisparker commented 4 years ago

Oh nice! I'm planning a biggish update at some point, and I will definitely be bumping blessed versions. Looking forward to seeing if I can implement this with the newer version!

jquast commented 4 years ago

Sounds good, I’ve got a big release of wcwidth to put out the next few days but I’d really like to help with cursewords, it’s a fave of mine!

On Sat, May 30, 2020, at 5:49 PM, Parker Higgins wrote:

Oh nice! I'm planning a biggish update at some point, and I will definitely be bumping blessed versions. Looking forward to seeing if I can implement this with the newer version!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/thisisparker/cursewords/issues/21#issuecomment-636389582, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNOKGFDHSD4B2DDU2YP4DRUF5MZANCNFSM4G7ACADA.

thisisparker commented 3 years ago

Shipped an update today and bumped blessed but only to 1.16.2, because it looks like 1.17 and up have some breaking changes. That's okay! I'll be figuring out what I need to change to get that and will hopefully get the better delete behavior and a whole bunch of other stuff.

thisisparker commented 3 years ago

I believe this is fixed with 02ac94b76d767db349571a572a1cc70959edfb4c!