Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default Keymap Not Extracting #20

Open
mvastola opened this issue May 2, 2017 · 10 comments
Open

Default Keymap Not Extracting #20

mvastola opened this issue May 2, 2017 · 10 comments

Comments

@mvastola
Copy link

mvastola commented May 2, 2017

Hi @kairyou,
Thanks for this plugin. Really tiny bug, but in sublime-tmpl.py the file_list array is missing your default keymap file. This is causing it to never be extracted from the package.

Is there any way you could fix this? (BTW, I suspect this is actually the source of the problem the user in #11 reported experiencing.)

Also, two other related things I'm noticing, having just installed this plugin:

  • When I try to open the default keymap file (which currently doesn't exist) the path that the latest ST3 opens is ~/.config/sublime-text-3/Packages/SublimeTmpl/Default (Linux).sublime-keymap. Particularly, your keymap file doesn't have the (Linux) in it.
    I'm not 100% sure if this matters or if Sublime would automagically fall back to the other path if it existed (I should probably check) and I know this should be a cross-platform plugin, but it's worth mentioning in case these files are all supposed to have the OS in them now.

  • Along the same lines -- though a slightly different quirk -- is that when choosing to open the user keymap file, the path ~/.config/sublime-text-3/Packages/User/Default (Linux).sublime-keymap is opened for me.
    I mention this because I can only assume that you need to create at least a blank file custom to SublimeTmpl to prevent it from falling back to the global. (Interestingly, for some reason this fallback doesn't occur with the user settings file, which opens as ~/.config/sublime-text-3/Packages/User/SublimeTmpl.sublime-settings, but I'm guessing that's because I don't have a file named ~/.config/sublime-text-3/Packages/User/Default (Linux).sublime-settings.)

@kairyou
Copy link
Owner

kairyou commented May 9, 2017

Hi mvastola,
I have added a new version 1.1.5.
Please reinstall the SublimeTmpl and restart sublime.
Thanks

@mvastola
Copy link
Author

@kairyou, so that fixed the issue with the default keybindings not installing, (FWIW, I have ST3 and I'm pretty sure all plugins update automatically. Or at least this one did.) but not the issue with the paths I identified in the second bullet.

Choosing Preferences => Package Settings => SublimeTmpl => Key Bindings - User still opens ~/.config/sublime-text-3/Packages/User/Default (Linux).sublime-keymap when it would seem it should really be ~/.config/sublime-text-3/Packages/User/SublimeTmpl/Default (Linux).sublime-keymap.

This is because, according to the documentation, Sublime collects all Default (<platform>).sublime-keymap files from installed packages and across various configuration directories and merges them in a specified order and applies the results. The exception is that for like-named files that override lower-priority defaults, where a higher-precedence file will cause a lower-ranking file to be totally ignored rather than just be merged over.

The current setup is problematic because it would tend to have the user put all their custom keymaps in a global keymap file. It would seem the correct place to put the keymaps for a plugin is in a plugin-specific file.

One large reason for this is because there's no way easily disable all the keymaps for a given plugin. If I wanted to disable all of the default keymaps for this plugin so as to allow all the default keymaps for another plugin work normally (assume there were some conflicts might conflict), there's no real way to do that without re-declaring all the default keymaps for the latter plugin in my personal custom keymap file. It's far cleaner though to just edit Packages/User/SublimeTmpl/Default (Linux).sublime-keymap, because -- as long as this file exists, according to the docs, the default keymap for the package (Packages/SublimeTmpl/Default (Linux).sublime-keymap) is not read at all.

I would have to check this, but while this plugin has an option to disable its keymaps, it would seem that it wouldn't work as intended. Yes, the key combos should stop triggering actions in this plugin when that option is set, but neither will they be able to trigger actions in other plugins because in Sublime's thinking, they are still assigned to this one.

@mvastola
Copy link
Author

That was a really long comment, so here's a shorter version containing just my suggested resolution:

  • Update sublime-tmpl.py to:
    • Remove the disable_keymap_actions setting
    • Cause Preferences => Package Settings => SublimeTmpl => Key Bindings - User to open Packages/User/SublimeTmpl/Default (Linux).sublime-keymap
    • Any time this plugin is installed/updated, read the value of disable_keymap_actions (factoring in the default value if it is not set).
    • If the value of disable_keymap_actions above is true and if Packages/User/SublimeTmpl/Default (Linux).sublime-keymap does not exist, copy Packages/SublimeTmpl/Default (Linux).sublime-keymap to Packages/User/SublimeTmpl/Default (Linux).sublime-keymap and comment out the contents of the latter file. This will disable all the default key-mappings but allow users to enable them quickly on an ad-hoc basis and also allow other plugins to use the key combos easily.

@mvastola
Copy link
Author

Also, feel free to, before releasing this publicly, let me know when you've done this (or something similar) as I'd be happy to test.

@kairyou
Copy link
Owner

kairyou commented May 19, 2017

That is a good idea :)
But comment the contents of Packages/User/SublimeTmpl/Default (Linux).sublime-keymap can't disable the default key-mappings, unless remove or comment the Packages/SublimeTmpl/Default (Linux).sublime-keymap.
Comment the default *.sublime-keymap by default maybe a solution, but I'm not sure it'is better for the user experience.

@mvastola
Copy link
Author

mvastola commented May 19, 2017

Have you tried this? See the third link I cited (each word in "according to the documentation" above was a different link): http://docs.sublimetext.info/en/latest/extensibility/packages.html#customizing-or-overriding-packages. Especially the warning box. The entire purpose of the defaults file is to not be editable, so I wouldn't comment anything out there.

At first I misunderstood your comment and I thought you were talking about keymaps that might be set in Packages/User/Default (Linux).sublime-keymap. I had forgotten about those. So I would amend my previous advice to (in the migration function) also either remove any keymappings for this plugin from that file and move them into Packages/User/SublimeTmpl/Default (Linux).sublime-keymap, or show a popup instructing the user to do so manually.

@kairyou
Copy link
Owner

kairyou commented May 22, 2017

Sublime's override is actually extend, change the value of user file(Packages/User/SublimeTmpl/Default (Linux).sublime-keymap) can override the value of default file(Packages/SublimeTmpl/Default (Linux).sublime-keymap), but comment the lines of Packages/User/SublimeTmpl/Default (Linux).sublime-keymap cannot disable the default keymaps.

@mvastola
Copy link
Author

That link says "Files in override packages override entire files." That doesn't describe extend. It describes override.

@kairyou
Copy link
Owner

kairyou commented May 22, 2017

You can creat the file Packages/User/SublimeTmpl/Default (Linux).sublime-keymap, and paste the content of Packages/SublimeTmpl/Default (Linux).sublime-keymap. Then toggle comment of the user keymaps(Packages/User/SublimeTmpl/Default (Linux).sublime-keymap) and test it is override or extend.

@mvastola
Copy link
Author

I'll play with this a bit and see what I can figure out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants