Open ghost opened 7 years ago
Some commands only make sense in combination with specific parameters, so I think it makes sense that internal commands are not "automatically" exposed in the command palette. But there could be a case for the Default package including more commands in it's Default.sublime-commands
file. I guess this just moves the work from the contributors of the Missing Palette Commands package you mentioned to the ST devs, but it could make sense as only the ST devs know when they add or remove commands, and whether they should be exposed in the command palette.
Some commands only make sense in combination with specific parameters, so I think it makes sense that internal commands are not "automatically" exposed in the command palette.
Yes, I might be unaware of all internal ST's commands. Correcting myself, I actually meant all commands that are available to the user (through the menus and default keybindings file).
I guess this just moves the work from the contributors of the Missing Palette Commands package you mentioned to the ST devs, but it could make sense as only the ST devs know when they add or remove commands, and whether they should be exposed in the command palette.
Exactly, keeping it more up-to-date.
Furthermore, the Command Palette is a good cheatsheet to remind us of forgotten keybings.
Thanks @megadr01d for pointing to Missing Palette Commands .
I don't like the messy main menu, too, and love to do everything with keybindings or command pallet. Therefore I was looking for many missing commands in the past, but never found something like the Missing Commands package.
I'd really love to see all available commands as part of the command pallet, too.
But I agree with @keith-hall. All the commands should be added to the Default.sublime-commands
Maybe it should be automatic that every menu item be added to the command palette if not already there? For example, this would help when people want package settings available from the command palette, but the author only added menu entries.
Maybe it should be automatic that every menu item be added to the command palette if not already there? For example, this would help when people want package settings available from the command palette, but the author only added menu entries.
So, why the currently available Palette commands are cherry picked and not be made to automatically pick up all internal registered commands?
Exactly my request! If a command (ST's internal or package) is added/removed from the menu, the Command Palette would update accordingly. Even the Help > Documentation menu, just as an example.
Another example is View > Ruler> .... It's not even in Missing Palette Commands. I just had to add it as:
{ "command": "set_setting", "args": {"setting": "rulers", "value": []} , "caption": "Ruler: None" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [70]} , "caption": "Ruler: 70" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [72]} , "caption": "Ruler: 72" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [78]} , "caption": "Ruler: 78" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [80]} , "caption": "Ruler: 80" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [100]} , "caption": "Ruler: 100" },
{ "command": "set_setting", "args": {"setting": "rulers", "value": [120]} , "caption": "Ruler: 120" },
This shouldn't be needed. If it's in the menu, it's available to the user. If it's available to the user it should be accessible mouse-free.
BTW, if you're on macOS, there's a built-in feature to kind of workaround this. it's actually an accessibility feature and works, although it's a bit clunky.
Just set a key combo for System Preferences > Keyboard > Shortcuts > App Shortcuts > All Applications > Show Help menu.
Then, in any app, hit that combo and type any command which is available through the app menu (the menus will expand/collapse as requested, hence the clunky part).
But of course the Command Palette is much better and available in all platforms.
I agree that any command in the menu should automatically also be in the command palette. However, the names are usually a bit different. For instance, it's usually the case that plugins prefix their commands in the command palette with their name. e.g.
Package Control: Do This
Package Control: Do That
While in the menu it's only
Do This
Do That
How would you solve this? Note that a plugin may place its command in the menu literally anywhere, not just in a submenu with the plugin's name.
Just determine uniqueness based on the command and it's args rather than the caption of the command palette or menu entry.
this would help when people want package settings available from the command palette, but the author only added menu entries
I guess this is a separate issue, but I honestly find approaches like https://packagecontrol.io/packages/Side-by-Side%20Settings or https://packagecontrol.io/packages/ReadmePlease which provide a common method to gain access to all packages settings files and readme files best. The need for each package to create a menu item and/or command pallet entry to provide access to settings, readme, changelog, issues, etc. is quite ugly and doesn't help introducing common ways to handle all of that.
A package provides a *.sublime-settings which needs to be reachable by command pallet and main menu automatically or it does not have one. Same with readme.
Missing Packages seems to miss some recent/useful entries. Therefore I created a file with all commands from Default package, Missing Packages and some additions, which I placed into another "Default" package in my Packages folder to override everything.
see: https://github.com/deathaxe/sublime-commands
It does not provide any automatism but may be a source to pick some commands.
Remarks:
It does not provide any automatism but may be a source to pick some commands.
Thanks for the effort, I'm actually using it now. Anyway, I had to rename commands back to reflect the name that's in the menus, and that's why automatism would still be preferable.
I renamed some commands just because of my personal preferences and the fact I don't use menu at all if not required due to missing alternative.
Naming is a big deal. With "View" in mind it is a standard to be used for visual settings in windows main menus, while a view is also describes the text area. So the double usage may be misleading sometimes. As @wbond introduced "UI: " prefix for "Select Color Scheme" and "Select Theme" commands which apply globally, I had in mind to prefix all commands with global results like that.
But as I said, this might be personal taste.
Just a ping to direct the subscribers' attention to @deathaxe's effort. I've been using the menus less and less because of him.
For indexing GitHub search:
Sources:
Just a ping to direct the subscribers' attention to @deathaxe's effort. I've been using the menus less and less because of him.
I'd prefer a way to be able to completely disable it. Pressing Alt
key keeps displaying it, which is good to bring it up, but is annoying sometimes when working with key combos.
I'd prefer a way to be able to completely disable it. Pressing Alt key keeps displaying it, which is good to bring it up, but is annoying sometimes when working with key combos.
This is a Windows-only issue (accessibility feature, actually) which I gladly don't suffer from, since I'm on OS X. After a bit of research, tho, here are a couple of possible 3rd party solutions, most involving using AutoHotkey, the "Windows version" of Karabiner.
I have bound a key bind to show/hide the menu bar:
{ "keys": ["ctrl+k", "ctrl+m"], "command": "toggle_menu" },
And usually work with him hidden. May be I should add allow it to auto-hide itself.
but is annoying sometimes when working with key combos.
Yeah! Half the time I am trying to hit a Alt
keybind combo, but nothing happens because the menu is hooked with some empty Alt
key press.
Then, I just researched and found this script to work 100%. No Alt
key ever anymore.
Alt::
KeyWait, Alt
return
LAlt Up::
if (A_PriorKey = "Alt")
return
return
If you prefer too, you can also restrict this solution to Sublime Text only:
#IfWinActive ahk_exe sublime_text.exe
Alt::
KeyWait, Alt
return
LAlt Up::
if (A_PriorKey = "Alt")
return
return
#IfWinActive
Here's the current diff between the Default.sublime-commands
file of 4093 & 4094 (Since 4094 added a bunch more commands to the command palette).
@Ultra-Instinct-05 Do you mind re-rerunning the diff with --ignore-space-change
(-b
)? Hopefully that will skip the ones that have just been switched between single-line and multi-line.
I actually used window.run_command("diff_files")
for it. Using git for it never crossed my mind. I have updated it (though I don't see any difference in it by using git diff "path_to_4093_file" "path_to_4094_file" --ignore-space-change --output="output.txt"
)
Ah. There were commas added/removed as well. That probably throws off the space change. 😞 My mistake. Thanks anyway.
Using git for it never crossed my mind.
I do this everywhere. gdiff
is an alias to git diff --no-index
on pretty much every system I use.
I just went through the list of commands provided by the Missing Palette Commands package and removed all the commands that have since been added, which left me with the following:
Now, I don't think all of these should be added, but I would definitely appreciate some of them, such as:
reveal_in_side_bar
translate_tabs_to_spaces
I pretty much never want to use the menu and I don't need to have every command bound to a key, especially when I only use them rarely.
A couple of others would be nice to discover their key bindings, which I like using the palette for should I happen to forget a binding and helps discovery in general.
Summary
Automatically register all internal commands in the Command Palette.
Expected behavior
Call the Command Palette and be able to browse all available internal commands.
All ST's internal commands should be automatically registered and updated in the Command Palette. For example,
update_check
is registered in some part of ST's code. So, why the currently available Palette commands are cherry picked and not be made to automatically pick up all internal registered commands?Actual behavior
Call the Command Palette and only a subset of commands is available.
Missing Palette Commands is a workaround. It adds the missing commands manually but if ST removes or adds a new command in the future, this package will have to be manually updated.
ST already does the right thing on third-party packages which declare a
.sublime-commands
file, automatically registering it in the Command Palette. If I add/remove a command to a specific.sublime-commands
file, it will auto update in the Command Palette.Steps to reproduce
N/A
Environment