Option + Shift + Backspace/Delete - Not Working

[51n7]

Bare metal

Linux distro name: Neon 22.04
Distro version: X11
Desktop environment(s): KDE

Keyboard type (IBM, Chromebook, Windows, Apple): 
Apple

Default MacOS behaviour when navigating text lets the user hold shift + option (alt) + backspace or delete to remove a word in each direction, this is not currently working in Toshy.

shift + cmd + backspace/delete works the same way by using home/end to clear a line of text and this feature is working in Toshy.

Tested in:

• Sublime Text
• Visual Studio Code
• Kate
• Chromium and Firefox URL bar

[RedBearAK]

@51n7

Will have to look at this for a while, make sure that I understand what is supposed to happen and how it is different from the existing wordwise shortcuts, and then see if it can be remapped to something standard on Linux or will need individual remaps for different Linux apps.

I have a feeling it may need specific app-based remaps, but we'll see what we can figure out.

Probably should also see if it works in Terminal.app the same way.

[RedBearAK]

@51n7

This seems to have a slightly different effect in different macOS apps. This behavior may or may not be precisely replicatable, depending on the shortcuts available in the target Linux app.

In VSCode:

The Option+Backspace/Delete "delete word left/right" shortcuts will delete everything to the next word boundary, including any space(s) between the cursor and the word in the delete direction.

Shift+Opt+Backspace/Delete will instead delete the spaces separately, stop at the word boundary, then delete the next word in that direction the next time the shortcut is used. So it treats spaces as if they were also "words".

In TextEdit:

Both sets of shortcuts will delete to the next word boundary, along with any spaces between the cursor and the word being deleted.

--

Most likely punctuation is also included with spaces. I'll have to mess with this in different apps for a while.

[RedBearAK]

I noticed that the Cmd+Backspace/Delete shortcuts were not actually deleting to beginning or end of line in VSCodes like they should. They were just acting like Option+Backspace/Delete and deleting words. So I'll be fixing that with this change:

keymap("VSCodes", {
...
    # C("RC-Backspace"):          C("C-Backspace"),               # Delete Entire Line Left of Cursor
    C("RC-Backspace"):         [C("Shift-Home"), C("Delete")],  # Delete entire line left of cursor
    C("RC-Delete"):            [C("Shift-End"), C("Delete")],   # Delete entire line right of cursor
...
}, when = matchProps(clas=vscodeStr))

[RedBearAK]

@51n7

This is not going to behave exactly the same as what I saw in VSCode on a Big Sur machine, but I think it will do what you wanted. We'll have to look at other apps separately.

keymap("VSCodes", {
...
    C("Shift-Alt-Backspace"):   C("C-Backspace"),               # Delete word left of cursor
    C("Shift-Alt-Delete"):      C("C-Delete"),                  # Delete word right of cursor
    # C("RC-Backspace"):          C("C-Backspace"),               # Delete Entire Line Left of Cursor
    C("RC-Backspace"):         [C("Shift-Home"), C("Delete")],  # Delete entire line left of cursor
    C("RC-Delete"):            [C("Shift-End"), C("Delete")],   # Delete entire line right of cursor
...
}, when = matchProps(clas=vscodeStr))

[51n7]

Confirmed this change kinda works for VSCode. I hope these rules don't need to be added for every application though :frowning_face:

[RedBearAK]

Confirmed this change kinda works for VSCode. I hope these rules don't need to be added for every application though frowning_face

The limitation on Linux is that we can't be sure that the cursor is inside a text area, so any shortcut that involves selecting and/or deleting anything can potentially be very harmful in the wrong context. Unlike using AutoHotkey in Windows, where it has pretty fine-grained abilities to get the name of specific GUI elements. We only have access to the app class and window title in Linux, basically.

But, if nothing else this may be a candidate for a new keymap that could be easily applied to any number of individual apps as a group by just adding the app class to a list in the config. Shouldn't really be a big deal in the long run to get it to be active where it needs to be. But that's assuming the shortcuts it needs to remap onto are standard in Linux apps. Which I'm not sure of yet.

You can always throw caution to the wind and place the shortcuts in the "General GUI" keymap in your own config file, and then see what sort of negative consequences you encounter in apps outside of text editors or text fields. In particular I think file managers could be a problem if these were active in all GUI apps. You could wipe out a file or even a whole folder full of files by accidentally using those while the cursor is active in the file pane instead of an editable text field.

Reminder: If you edit your config file outside of the "slice marks" the changes you make won't be retained when re-installing. The installer tries to keep the changes you make inside the "slice marks" by copying them into the default config file, but will overwrite anything else with the contents of the new copy of the config file.

(There will still be a full backup of the previous contents of your entire Toshy config folder, including your previous config file, in another folder.)

Can you be more specific about "kinda works"? The shortcuts involve the Alt key code so it's likely that I'll have to add the special bypass trick that some of the other VSCode shortcuts use, like this:

    C("Shift-Alt-Backspace"):  [C("Alt-F19"),C("C-Backspace")], # Delete word left of cursor
    C("Shift-Alt-Delete"):     [C("Alt-F19"),C("C-Delete")],    # Delete word right of cursor
    # C("RC-Backspace"):          C("C-Backspace"),               # Delete Entire Line Left of Cursor
    C("RC-Backspace"):         [C("Shift-Home"), C("Delete")],  # Delete entire line left of cursor
    C("RC-Delete"):            [C("Shift-End"), C("Delete")],   # Delete entire line right of cursor

But that would only make a difference if you haven't implemented the customization in your settings.json file to disable the accidental focusing of the menu bar when the app sees the Alt key code.

[51n7]

ah sorry, by "kinda" I was just referring to the inaccuracy you mentioned before in comparison to Big Sur and capturing punctuation and spaces.

[RedBearAK]

ah sorry, by "kinda" I was just referring to the inaccuracy you mentioned before in comparison to Big Sur and capturing punctuation and spaces.

Gotcha.

Actually it looks like there are a number of different deleteWord* shortcuts in VSCode, they just aren't all active on the Linux Flatpak versions of VSCode and VSCodium where I'm testing the shortcut remap. This explains why the shortcut is able to work differently in VSCode versus TextEdit.

So maybe we can mimic the behavior precisely, but it would require the user in Linux to manually enable the appropriate shortcuts in their user shortcuts JSON file.

deleteWordLeft
deleteWordRight

deleteInsideWord

deleteWordEndLeft
deleteWordEndRight
deleteWordPartLeft
deleteWordPartRight
deleteWordStartLeft
deleteWordStartRight

I'll have to play with these or look at the shortcuts settings in the macOS version to see which are active and responsible for deleting spaces/punctuation separately.

[RedBearAK]

I think the most correct way to handle this for VSCode(s) is not to have a remap in the Toshy config, because all we could do from there is use the usual "delete word" shortcuts. Instead, I think the user will have to activate the shortcuts that are active on the macOS version of VSCode:

deleteWordPartLeft
deleteWordPartRight

Unfortunately, even when those shortcuts are activated I still see slightly different behavior between macOS and the Linux VSCode(s). In Linux this shortcut will treat "camelCase" capitals as word boundaries, but in macOS that doesn't seem to be the case, it will delete the whole contiguous word. In both platforms, the "Part" shortcuts will delete contiguous spaces and contiguous punctuation separate from "words".

I'm still a bit confused about whether these shortcuts generally behave any differently in other macOS apps than the existing Option+Backspace/Delete shortcuts. They did not seem to do anything different in TextEdit. So maybe for all apps in Linux where there is no special behavior to map onto, these can be general "wordwise" shortcuts defined in the same place as the existing "delete word" shortcuts, and remapping onto the same shortcuts. But I'm not sure if that's quite what you were looking for.

[RedBearAK]

@51n7

If you want to go ahead and test this out, I think I might update the whole tail end of the config file like this. This is the lower half of the "General GUI" keymap at the end of the config file:

...
    # This is better done with a native custom shortcut in each DE
    # C("Alt-RC-Space"):          C(""),                          # Open Finder - Placeholder not-deepin

    # Wordwise
    C("RC-Left"):               C("Home"),                      # Beginning of Line
    C("Shift-RC-Left"):         C("Shift-Home"),                # Select all to Beginning of Line
    C("RC-Right"):              C("End"),                       # End of Line
    C("Shift-RC-Right"):        C("Shift-End"),                 # Select all to End of Line
    C("RC-Up"):                 C("C-Home"),                    # Beginning of File
    C("Shift-RC-Up"):           C("C-Shift-Home"),              # Select all to Beginning of File
    C("RC-Down"):               C("C-End"),                     # End of File
    C("Shift-RC-Down"):         C("C-Shift-End"),               # Select all to End of File
    C("Super-Backspace"):       C("C-Backspace"),               # Delete Left Word of Cursor
    C("Super-Delete"):          C("C-Delete"),                  # Delete Right Word of Cursor
    C("RC-Backspace"):          C("C-Shift-Backspace"),         # Delete Entire Line Left of Cursor
    C("Alt-Delete"):            C("C-Delete"),                  # Delete Right Word of Cursor
    C("Shift-Alt-Backspace"):   C("C-Backspace"),               # Delete word left of cursor
    C("Shift-Alt-Delete"):      C("C-Delete"),                  # Delete word right of cursor

    # C("RC-Left"):               C("C-LEFT_BRACE"),              # Firefox-nw - Back
    # C("RC-Right"):              C("C-RIGHT_BRACE"),             # Firefox-nw - Forward
    # C("RC-Left"):               C("Alt-LEFT"),                  # Chrome-nw - Back
    # C("RC-Right"):              C("Alt-RIGHT"),                 # Chrome-nw - Forward
    # C(""):                      ignore_combo,                   # cancel
    # C(""):                      C(""),                          #

# }, when = lambda ctx: ctx.wm_class.casefold() not in remotes) # original conditional
# }, when = matchProps(not_clas=remoteStr))                      # matchProps with regex string
}, when = matchProps(not_lst=remotes_lod))                      # matchProps with list-of-dicts

keymap("Diagnostics", {
    C("RC-Shift-Alt-i"):        isDoubleTap(notify_context),
    C("RC-Shift-Alt-t"):        isDoubleTap(macro_tester),
}, when = lambda ctx: ctx is ctx )

For general usage this will simply treat Shift+Option+Backspace/Delete as being the same as Option+Backspace/Delete. They will remap onto the same native shortcuts for all apps, which have not been harmful as far as I know. So URL bars, any editors or text fields, etc.

I took a look at Kate, and in the copy that was installed in a Fedora 38 KDE virtual machine, it had no extra shortcuts available for anything but the usual "delete word left/right" shortcuts. Nothing special like VSCodes. So the modification above should make it work in Kate and all sorts of other apps.

If you do this modification, and you activated the special "deleteWordPart" shortcuts in VSCodes and want those to continue to work, you'll need to stop this general shortcut from working in VSCodes with an "override" in the VSCodes keymap, like this:

keymap("VSCodes", {
...
    C("Shift-Alt-Backspace"):   C("Shift-Alt-Backspace"),        # Delete word left of cursor (override GenGUI)
    C("Shift-Alt-Delete"):      C("Shift-Alt-Delete"),           # Delete word right of cursor (override GenGUI)
    # C("RC-Backspace"):          C("C-Backspace"),               # Delete Entire Line Left of Cursor
    C("RC-Backspace"):         [C("Shift-Home"), C("Delete")],  # Delete entire line left of cursor
    C("RC-Delete"):            [C("Shift-End"), C("Delete")],   # Delete entire line right of cursor
...
}, when = matchProps(clas=vscodeStr))

This will remap Shift+Option+Backspace/Delete back onto themselves, negating the general remap just for the VSCodes. I don't think the Alt+F19 trick should be necessary.

Let me know how this works out.

I should also take a look at whether these are valid shortcuts in Terminal.app, as wordwise stuff needs to map onto different shortcuts for terminals in Linux.

[51n7]

Thanks for the investigation into this, the config modification works for me as expected with a minor bug in Kate but that might just be an issue with Kate and it's very edge case, plus I dont use Kate myself so for me it's not a big deal but FYI:

In this example I attempt the 4 methods:

• Shift+Option+Backspace
• Shift+Option+Backspace and include the trailing space
• Shift+Option+Delete
• Shift+Option+Delete and include the previous space

As you can see when I use Shift+Option+Delete and include the space it does not delete the word.

As for Terminal.app this is not the default behaviour so I wouldnt expect this in toshy, however it would be nice but that's MacOS's fault as we're just trying to simulate their environment. Other terminal shell apps (like hyper) do offer natural text control so it's not a huge deal.

[51n7]

Randomly Sublime Text has stopped being able to cmd + up/down to travel to the start/end of the page, did I break something while updating the config? Everything else works fine.

[RedBearAK]

Huh. If I understand your demo, the Option+Delete should exhibit the same behavior, since it is remapping to the same shortcuts in the apps as the original wordwise "delete word" shortcuts. That would mean this is a choice by Kate to avoid deleting the word in that direction if a space is included.

I'll have to see if I see the same thing. There could even be a setting for that in Kate. I wouldn't be surprised. KDE apps in general have tons of settings.

Randomly Sublime Text has stopped being able to cmd + up/down to travel to the start/end of the page, did I break something while updating the config? Everything else works fine.

Hard to say. I had a problem with Unicode character entry in ST3, but I don't use ST3 much at all. Is the window being recognized properly? Try the diagnostic shortcut Shift+Opt+Cmd+I,I (double-tap the "I"), and/or the verbose logging.

[RedBearAK]

Are you sure this just started in ST3? The main ST3 keymap has been like this for a long time. It has "ignore_combo" as the remap for several things, including Ctrl+Up/Dn.

keymap("Sublime Text", {
    # C("Super-c"):               C("LC-c"),                      # Default - Terminal - Sigint
    # C("Super-x"):               C("LC-x"),                      # Default - Terminal - Exit nano
    # C("Alt-c"):                 C("LC-c"),                      #  Chromebook/IBM - Terminal - Sigint
    # C("Alt-x"):                 C("LC-x"),                      #  Chromebook/IBM - Terminal - Exit nano
    # C("Super-Space"):           C("C-Space"),                   # Basic code completion (conflicts with input switching)
    C("C-Super-up"):            C("Alt-o"),                     # Switch file
    C("Super-RC-f"):            C("f11"),                       # toggle_full_screen
    C("C-Alt-v"):              [C("C-k"), C("C-v")],            # paste_from_history
    C("C-up"):                  ignore_combo,                   # cancel scroll_lines up
    C("C-Alt-up"):              C("C-up"),                      # scroll_lines up
    C("C-down"):                ignore_combo,                   # cancel scroll_lines down
...

This would naturally block usage of either Ctrl key and Up/Down keys in ST3. The physical Cmd key position becomes "RC" (RIGHT_CTRL) throughout the config, so it would be covered by "C-" in an input combo.

I don't see how the BOF/EOF shortcuts could have ever worked in ST3, even with Kinto's original config file.

[RedBearAK]

If you don't need whatever those lines are supposed to do (I've never actually understood their purpose or what "scroll_lines up" is referring to), you can of course comment them out and the BOF/EOF wordwise shortcuts should work in ST3 just like they do everywhere else.

Just keep in mind that is the sort of change that would need to be merged back in from the backup that the Toshy installer makes, every time you update. It's outside the "slices".

Oh, I think I get it now, those lines are just blocking the shortcuts that would move selected lines up and down. It's not "canceling" any other action. But... Hmm. Again, that should have always been overriding the wordwise shortcuts in "General GUI" that apply to all apps. I feel like maybe this is a remnant of something. I'm going to see what happens when I disable those lines.

[RedBearAK]

Yep, I'm pretty confused why those lines were still active, and how you got the impression that the BOF/EOF Mac shortcuts ever worked in ST3, unless...

Oh, maybe it's because the original ignore_key did NOT actually work the way anyone expected... And ignore_combo is just an alias to the original ignore_key, so that the name makes slightly more sense. But that issue was fixed by the keyszer dev when he forked xkeysnail. So now it does work, and it was breaking the BOF/EOF shortcuts in ST3.

It remains true that I don't see how those shortcuts could possibly have ever worked during the time you've been using Toshy. Maybe you're remembering doing the same thing while using Kinto? It would have demonstrated different behavior due to still using xkeysnail.

I think I will either remove those lines or at least comment them out for now. Which should solve that issue. Go ahead and comment them out.

Maybe I better look at some of the other instances of that too.

[RedBearAK]

@51n7

I merged that change along with quite a few other things into the main branch. If you reinstall from a new zip file everything in this issue thread should be taken care of in the default Toshy config, unless I messed something up.

As always the Toshy installer should retain the database of settings and any modifications made within the marked "slices" in the config file. And it makes backups in a separate folder in ~/.config to avoid losing the previous config file. So it should be pretty safe to reinstall from a new zip or clone of the main branch of the Toshy repo.

Let me know if you're still having any issues.

[51n7]

Oh, maybe it's because the original ignore_key did NOT actually work the way anyone expected... And ignore_combo is just an alias to the original ignore_key, so that the name makes slightly more sense. But that issue was fixed by the keyszer dev when he forked xkeysnail. So now it does work, and it was breaking the BOF/EOF shortcuts in ST3.

You lost me there annnnd it could be that I imagined ST3 working a certain way but after pulling the latest changes it's working as expected. Still not sure if it was something you changed or me restoring my config but everything is looking great and the original Shift+Opt+Backspace/Delete is definitely working now. I'd call this issue resolved.

Thanks again for all the great support!

[RedBearAK]

Sounds good. Go ahead and close the issue if you think it’s taken care of satisfactorily. If you close it yourself you will be able to reopen it if needed.