Is highest fidelity or least effort the primary goal? (Sublime Text 4)

[joshgoebel]

Context: I've just installed Sublime Text 4 on my system and nothing was working right... this led to me finding a few issues:

• I'd copied over the Mac keymap myself long ago
• The regex in Kinto.sh is wrong, on my system the WM_CLASS is simply Subl

But since I was staring at a broken keymap that begged the question:

For serious apps that allow redefining all their keys completely wouldn't the highest fidelity experience be using their own native keymapping functionality and then telling Kinto's key mapping to just ignore that app completely?

This leads to the question... because it does seem the best fidelity experience would be to remove the extra layer of keymapping and use the Mac native keymap for Sublime itself (if possible)... but this might require a little more effort from users (or from Kinto's setup to do this for the user).

I'm imagining something like:

define_conditional_modmap(re.compile("Subl", re.IGNORECASE),{
    # no map, use normal keys
})

define_keymap(re.compile("Subl", re.IGNORECASE),{
    # no map, use normal keys
    # i don't think this will work currently
},"Sublime Text")

Since modmaps are exclusive this works already - place this modmap early and it will match first and prevent any of the keys going to Sublime from being modmapped. Now we just have global DE navigation... these could be added directly to the Sublime keymap itself and they might even be easier to write.

Now for the keymap though we have the small issue that keymaps are additive... while Sublime Text is active many other keymaps will be active as well (that could mess with Sublime's nonmapped keys... I see two solutions here:

• You program any conflicting keys as "passthru" or "literal" (this seems like it might be hard to maintain since every time you add a global keymap item you risk potentially breaking any apps - unless you're going back and checking all the time)
• We add the idea of an exclusive keymap that once the condition matches other keymaps in the stack are not consulted
• MAYBE: we add the concept of global and exclusive... so we'd declare like "General GUI" a global keymap and MOST apps as exclusive keymaps...

Lets examine the last option a little more... so when Sublime is focused we might have:

• modmap (empty for sublime 3, we want to pass all keys straight)
• modmap (General system wide remapping)
• keymap (Sublime 3, exclusive)
• keymap (Generual GUI, global)

The problem I immediately see is how do you apply the general system wide modmap (which is likely needed for the General GUI keymap) while having a non-modmap for Sublime Text?

Anyways - the real issue here (we'll see if I find more) is how do you have the keymapper leave an app alone while also still allowing global (DE, etc) keymaps to be active?

---

I'll be going to attempt going this route and using this thread to report/explore issues and start this discussion... I'm keeping in mind that this may require adding functionality to the keymapper and if it's easy to reason about I'm totally fine with the need to do so.

I assume the reason we haven't done this in the past are the problems I've mentioned above that would need to first be solved - OR does Kinto.sh place more value on least effort? Is the existing remapping for Sublime (it would need to be fixed) sufficient if it's only 95% fidelity - if having 100% fidelity by just using one file to change the app's entire keymap was within easy reach?

(note: I'm not saying the current system is less fidelity for sure - but I'm betting it is since it doesn't seem to recognize my Sublime at all and these things tend to age over time - so even if it was 100% up-to-date once... have to manually maintain it across releases is going to likely result in breakage with time).

[rbreaves]

The problem I immediately see is how do you apply the general system wide modmap (which is likely needed for the General GUI keymap) while having a non-modmap for Sublime Text?

There's a lot here, but let me start with this. I do not understand the thought of why anyone would want to completely exclude any given app from the basic modifier key remaps that simulate the Cmd key for any specific app. So in this sense the "least effort" approach does indeed kick into gear.

Maybe you can convince me that it makes sense for some apps to have a different modifier key layout but as far as I can tell all apps on macOS follow this general GUI app vs Terminal apps approach which I implement here. (not exactly of course as every app is designed specifically against those keys so of course no specially remapping occurs)

The regex in Kinto.sh is wrong, on my system the WM_CLASS is simply Subl

My 2 main editors are Sublime Text 4 & VSCode, my distro and afaik every distro I have tested against does not call it Subl in the WM_Class - maybe something has changed or a distro packages it that way.. I cannot say, although I do not think Sublime is prepackaged on any distro. I am fine with adding Subl into it.. although not happy that it might match with more apps than it should, be better to just group it the way I do for vscodium and vscode imho.

Is highest fidelity or least effort the primary goal? (Sublime Text 4)

For specific apps I am absolutely interested in high fidelity, if someone has taken the time to meticulous craft a remapping that is accurate then I will merge it. As far as the general GUI vs Terminal approach that is the least effort half of the app to cover everything I and others cannot realistically cover. Maybe that won't make everyone happy, but generally speaking it is a more consistent experience then not attempting anything at all.

---

Other notes I actually comment out my vscode block and use its grouping, I add sublime_text to it as a 3rd editor and then update the sublime_text code block to use the vscode grouping because I actually manually update VSCode to line up with vscode manually via a plugin and some personal documentation I use, which is floating around in a thread here. Not yet implemented - but it is a perfect 1:1 key mapping of VSCode to use the same sublime text keymaps.

[rbreaves]

There is also a line that I draw in general with all apps atm which is "If Kinto cannot remap it from within its own python based configuration file then it will not be remapped by Kinto."

Aka - my manual keyboard shortcut keys file that has to be imported into VSCode is not part of Kinto whether it is a file that aligns it more fully with macOS's version of VSCode or my own hybrid VSCode w/ Sublime Text keymappings. If it can be ported into Kinto's python config file then it'll be merged, but until then those changes stay out. Part of the appeal of Kinto ought to be how simple it is to turn on, off, edit, remove, etc. The moment anyone has to keep track of files and configs outside of kinto itself then I think it becomes a nightmare to manage as there will be no consistent config files and layouts on how to remap anything at all, some will be json, yaml, xml, or custom format.. who knows.. on top of figuring out each individual path.

[rbreaves]

have to manually maintain it across releases is going to likely result in breakage with time)

Part of the reason and joys of me open sourcing it. I don't use every hot key in any given app.. the more people that use it then the more people can contribute their changes that make it work for them. No one particular individual needs to make it 100%. That is what I have been striving for in every app I took the time to generate these remappings for, but regardless of whether I have been successful or not others can make the few changes that impact them or comb through it and update it, where it needs updating.

I am really not certain of how much breakage Sublime could cause btwn updates, if anything they add a new feature that isn't covered, but I doubt they'd break existing keymaps that often. Most of the time they'll probably pick a remap that works across all 3 if possible.

Adobe does a surprisingly good job at keeping all their hotkeys btwn Windows and macOS consistent despite the Cmd vs Ctrl issue. I do ZERO work to keep that one in sync because the lazy effort - none at all - is already 100% aligned for me 😂. Sadly there's no adobe on Linux of course.

[rbreaves]

The problem I immediately see is how do you apply the general system wide modmap (which is likely needed for the General GUI keymap) while having a non-modmap for Sublime Text?

Are you saying that you see conflicts in how the General GUI code section is written vs how Sublime is to behave?

define_keymap(lambda wm_class: wm_class.casefold() not in remotes,{

If there's an issue with that code block or how it is layered then I am not sure that I have seen it personally. General GUI is general in the sense that it exists to handle System OS based shortcuts that tend to be global on the entire OS, and to give it wordwise logic to manipulate your blinking cursor while typing. It really does not do much else and I do not see it conflicting with any particular app(s), not that it hasn't ever and hasn't had changes made to it ever. We work out and tend to prioritize the fix within the code block specific to the app in the right location so that the app takes precedence.

The thing I am most confused about though is why you think Sublime Text needs to have the ability to remap the modifiers keys in general and not just the combo keys (which it of course already does, except in your distro). I am really curious how you got your Subl wm_class though lol.

Aka this part here is confusing to me. I don't understand how defining another modmap makes any sense unless someone wanted to jump btwn macOS style keys and Windows/Linux ones. Maybe there is someone out there that wants that but I don't see adding anything to my config to do anything like that.

define_conditional_modmap(re.compile("Subl", re.IGNORECASE),{
    # no map, use normal keys
})

[joshgoebel]

It sounds like the short answer is no, but I'll address some of your questions. :-)

I do not understand the thought of why anyone would want to completely exclude any given app from the basic modifier key remaps that simulate the Cmd key for any specific app.

Right, it doesn't make sense UNLESS a single individual app ships a 100% high fidelity keymap of it's own that already has everything remapped perfectly... so who knows better how to make Sublime Text Mac-like than the official Sublime Text Mac keybindinding... and if you're using those then the "basic mod key remaps" that Kinto does only break things.

Maybe you can convince me that it makes sense for some apps to have a different modifier key layout

I wasn't suggesting that, only that is Sublime has already bound all the keys correctly itself - then those bindings are necessary - and actually start doing harm.

and afaik every distro I have tested against does not call it Subl in the WM_Class

I'm installing it on Arch from AUR... and it's just copying the binaries from the download (from a quick glance at the PKGBUILD)... could it be because I'm running it using subl not some fancy desktop launcher thingy?

I am fine with adding Subl into it.. although not happy that it might match with more apps than it should,

Is there any reason you can't just bind the regex to the start and end? ^Subl$, done... no excessive matches. The PKGBUILD here (I looked again) installs a subl link to sublime_text in /usr/bin... the actual binary software (because it's binary I presume) is installed in /opt... so I assume perhaps the WM_CLASS is coming from the name of the link? But this seems a pretty desirable thing to do to me (a subl shortcut for terminal use).

Is this setup handled differently on other setups? Perhaps a wrapper script or something? If there is a much better approach I could try to upstream it - otherwise I think match ^Subl$ would be pretty safe?

The moment anyone has to keep track of files and configs outside of kinto itself then I think it becomes a nightmare to manage as there will be no consistent config files and layouts on how to remap anything at all,

I mostly take your point here but I wonder if you aren't imagining a scary world where all the keybinding across apps potentially interfere with each other... I'm imagining a world more like "turn off Kinto for this app B, I'm doing my own thing"... So yes one would have to keep in their head/setup that they are using Kinto + App B with it's own entirely separate bindings - but the two wouldn't be stepping on each others toes.

That would need to be a condition I think - to keep us all sane. If one needed a severely hacked Kinto AND a severely hacked Sublime config and they only work together than that starts to sound terrible indeed.

I am really not certain of how much breakage Sublime could cause btwn updates,

That's true I think I was taking a lot away from the fact that it wasn't working out of the box to suggest that this piece might not be the most maintained. But seeing how you use ST4 that seems unlikely now. 😄

[joshgoebel]

The thing I am most confused about though is why you think Sublime Text needs to have the ability to remap the modifiers keys in general and not just the combo keys (which it of course already does, except in your distro).

I think we lost each other here. I'm just using the binary download, but packaged for Arch (where it copies the files, etc)... I no doubt have the same Linux keystrokes everyone else has (by default) but previously (years ago) I copied the "Mac OS X.keymap" over top of the linux keys...

So (without any Kinto.sh) all the Mac keys "just work" - because I copied the OFFICIAL mac 100% complete default keymap.

• every modifier works
• every combo works

To me this seems preferable and I'd prefer to let Kinto "take a break" (if I could). Of course none of this works anymore when Kinto steps in the middle. :-)

I really worry about Kinto leaking into all my configs, but that's a sep topic and I'll create it as such.

[rbreaves]

Right, it doesn't make sense UNLESS a single individual app ships a 100% high fidelity keymap of it's own that already has everything remapped perfectly... so who knows better how to make Sublime Text Mac-like than the official Sublime Text Mac keybindinding... and if you're using those then the "basic mod key remaps" that Kinto does only break things.

I see now - but this is where I completely disagree with you. Compare my macOS remap of JetBrains to JetBrains version and tell me which is more accurate and faithful to the actual macOS bindings. I will tell you though - mine is and for one simple reason - I have done something which they can't and won't do - I have literally re-arranged the OS level shortcut keys to make room for the type of hotkeys that would normally create a conflict on either Windows or Linux but since I moved those to align with macOS it then gives me the unique ability to have higher fidelity than even the original app authors that created their app for macOS.

Additionally it is easier for me to suggest that every user of Kinto simply not worry about having some apps remapped in Kinto and others remapped to be mac like from within individual apps, unless absolutely necessary, because that just makes things much more complicated for the user to maintain imo. Of course users can do whatever they want, fork and modify and kinto, but generally if it isn't impossible to map in Kinto then I am of the opinion that all rebindings go into Kinto.

[joshgoebel]

Compare my macOS remap of JetBrains ... tell me which is more accurate ... mine is

I'll take your word for it and so I'll accept your point here. You have more information/experience than me since I haven't gone down this road very far - although I do recall the setup working pretty well 2 years ago. So we may not disagree so much as my assumptions about who can do the remapping in high fidelity might be all wrong.

You're definitely approaching the problem from a much higher altitude for sure.

OK - let me go back and fix the regex, revert my Mac bindings and see what happens.

[rbreaves]

Of course none of this works anymore when Kinto steps in the middle. :-)

I suppose making it easier in the Kinto app to exclude the current app would be ideal for users that yes, have already made their own remappings. In general that goes against the simplicity I am trying to obtain here, but I get you spent time porting your mappings over and would like to retain them.

[joshgoebel]

I suppose making it easier in the Kinto app to exclude the current app would be ideal for users that yes, have already made their own remappings.

I'm still interested in that discussion if there is some logical way to make that easier to do (at the mapper level) - because it's not right now. :-)

but I get you spent time porting your mappings over and would like to retain them.

No, I just copied a text file from one place to another... well and I spent some time hacking kinto.py just a bit... but no huge loss... I'll rewind and try it your way. 👍🏼

[joshgoebel]

Thanks for the detailed answers. I'll close this since I already broke out the Subl not working out of the box into it's own issue.