Key Sequences - not working as intended with Shift key

Bug Reports
,
1

Describe the bug
I want to have text expanders for common punctuation pairs like (), [], {}, '', "", `` which is quite handy when interacting with various apps. So, my aim is that if I type the starting punctuation, BTT will auto-close it. So far it works with these:

  • ()
  • []
  • ''
  • ``

But doesn't work with these:

  • {}
  • ""

Apparently, what happens:

  • {} is being closed as {] instead
    • it closes using the rule for [ instead of the rule for Shift+[ which is the {
  • "" is being closed as "' instead
    • it closes using the rule for ' instead of the rule for Shift+' which is the "

Affected input device

  • MacBook Keyboard

Screenshots

Device information:

  • Type of Mac: MacBook Pro
  • macOS version: Mojave
  • BetterTouchTool version: (3.553)

Additional information

  • Similar issue involving Shift keys for Capitalization (August 2018)
  • Couldn't figure out a workaround, tried the various settings, and re-ordering the key sequences rules.
  • Maybe the triggers ordering should dictate the expansion priority so that we could reorder them and put those rules with Shift keys on top and be evaluated first?
2

Thanks for reporting I'll have a look!

3

Thanks, to replicate it, I think you'll need to define the rule for [ also in order for BTT to confuse it with the Shift+[ rule (i.e. the { rule), since if I disable the [ rule, the { rule/completion works ok:

Screen Shot 2021-02-24 at 4.24.49 PM
Screen Shot 2021-02-24 at 4.24.49 PM1916×1500 271 KB

4

Ah I see.

I think the problem is e.g. the single [ sequence because that's also part of shift + [ sequence

To make something like this possible BTT would probably need a way to configure which keys are NOT allowed to come before a specific key sequence. However this is quite complicated to add. I'll think about it.

Or maybe something like "wait x seconds for other key sequence before triggering"

5

Yup, that's my understanding also, and l'm a programmer myself and tinkered heavily with Karabiner Elements which you could define the keys/sequences behaviors depending if they are in pressed combo or in isolation. Maybe the quick fix is to put weights on the rules ordering in the UI for evaluation priority? Not sure of the performance impact though. Also, maybe we could leverage the Required and Order is Relevant column here? Since the [ and { rules differ mainly also with these values:

Screen Shot 2021-02-24 at 4.40.58 PM
Screen Shot 2021-02-24 at 4.40.58 PM1266×238 34.3 KB

The [ and { rules are just samples here, but it affects lots of characters sequences (capitalization, punctuations, etc). So, I think this should really be fixed or have some workaround at least. And would be really happy if you could fix it. Thanks a lot. :slight_smile:

6

I think the order in the UI wouldn't matter because in any case the [ key will be pressed before completing the sequence, thus triggering the other sequence. So at the moment of the "trigger" the order in the UI would not help because the other sequence has not been finished yet.

Complicated :slight_smile: I think it would be most flexible if I added two options: keys that can not be pressed during the sequence, and keys that must not have been pressed right before the sequence starts.

7

Yup, adding new options will be good idea. Will let you have some thoughts on it. Let me know once you fixed it. Will really appreciate. :slight_smile:

8

Maybe BTT could automatically scan the configured sequences and check whether "subset" sequences are there - and if so do the configuration automatically.

I think that might be the easiest solution because everything else would make the UI really complicated.

9

I agree also with that simple/non-UI solutions.