TextMate has a feature that if a keyboard shortcut maps to multiple commands (I'm mostly thinking of bundle commands) a context menu will open to allow the user to disambiguate the command. It's possible to use the numbers on the keyboard to select the correct command.
Would it be possible to use letters in addition/instead of the numbers to disambiguate the commands?
For example, in the Git bundle there are a lot of commands that map to the same same keyboard shortcut (⌘Y). Because they're so many only around a third of the commands have a number to disambiguate using the keyboard.
BTW, I tried to disable the keyboard shortcut for a couple of commands I'm not using but the "Key Equivalent" field is blank for all the Git commands. Does the Git bundle has some kind of special treatment?
I'm running TextMate version 2.0-beta.8.1 on OS X 10.10.3.
On 24 Oct 2015, at 18:37, Jacob Carlborg wrote:
TextMate has a feature that if a keyboard shortcut maps to multiple commands (I'm mostly thinking of bundle commands) a context menu will open to allow the user to disambiguate the command. It's possible to use the numbers on the keyboard to select the correct command.
Would it be possible to use letters in addition/instead of the numbers to disambiguate the commands?
Pressing A-Z already works to select the first item in the menu starting with that letter.
For example, in the Git bundle there are a lot of commands that map to the same same keyboard shortcut (⌘Y). Because they're so many only around a third of the commands have a number to disambiguate using the keyboard.
For Subversion we spent some time naming the items so that the most commonly used items would work with letters, e.g. [C]ommit, [D]iff With Base, [S]tatus, [B]lame, etc.
The Git bundle was developed a little different, and I think the goal there was to put the most commonly used items near the top, so that these would be reachable with the number keys.
Personally I wouldn’t be against re-arranging the Git menu so that it would work better with letter keys, but I fear it would upset a lot of people who are e.g. used to ⌘Y + 2 for commit, etc.
BTW, I tried to disable the keyboard shortcut for a couple of commands I'm not using but the "Key Equivalent" field is blank for all the Git commands. Does the Git bundle has some kind of special treatment?
The way it works is that the SCM bundle has a proxy item bound to ⌘Y (not the Git bundle!).
A proxy item is simply a proxy for one or more other items. As its content it has a “query” which queries on the semantic class (of all items that would apply in current scope).
For the SCM bundle the query is `action.scm`, i.e. all SCM actions. The respective SCM bundles (Git, Subversion, etc.) are scoped to `attr.scm.XYZ` so the proxy item will only find items that are scoped to the version control system currently in use.
Currently the “query language” used in proxy items is just prefix match, otherwise you could change the query so you would only get the actions you’re interested in.
Lacking the ability to do more sophisticated queries, you can remove the scm.action semantic class from the items you do not want in the menu.
It’s not an ideal solution, as the semantic class is intended for more than just this menu, e.g. we might do a “commit” toolbar button, and this would then query the semantic class, but right now, we do not have this functionality, so you’re not (yet) losing out on anything by editing the semantic classes.
On 2015-10-25 15:16, Allan Odgaard wrote:
Pressing A-Z already works to select the first item in the menu starting with that letter.
That does not seem to work properly. Pressing ⌘Y and then B will select "Branches" instead of "Browse Annotated File". For P it will select "Pop Stash" instead of "Pull".
One minor disadvantage of the current way that the letters work is that it will only select the command, not execute it.
The Git bundle was developed a little different, and I think the goal there was to put the most commonly used items near the top, so that these would be reachable with the number keys.
Understandable. It just happens that I use a couple of commands that do not have an associated number more often a couple of the commands that do have numbers.
Personally I wouldn’t be against re-arranging the Git menu so that it would work better with letter keys, but I fear it would upset a lot of people who are e.g. used to ⌘Y + 2 for commit, etc.
If it would be possible to add keyboard shortcuts for the menu that is not dependent on the order, the existing order could be preserved for backwards compatibility. That is, it would be possible to use both numbers and letters.
The way it works is that the SCM bundle has a proxy item bound to ⌘Y (not the Git bundle!).
Aha, that's were it's hiding :)
One minor disadvantage of the current way that the letters work is that
it will only select the command, not execute it.
This is probably because the letters are not “unique”, so immediatly executing the command could lead to unexpected results.
Koen
On Sun, Oct 25, 2015 at 7:16 PM, Jacob Carlborg doob@me.com wrote:
On 2015-10-25 15:16, Allan Odgaard wrote:
Pressing A-Z already works to select the first item in the menu starting with that letter.
That does not seem to work properly. Pressing ⌘Y and then B will select "Branches" instead of "Browse Annotated File". For P it will select "Pop Stash" instead of "Pull". One minor disadvantage of the current way that the letters work is that it will only select the command, not execute it.
The Git bundle was developed a little different, and I think the goal there was to put the most commonly used items near the top, so that these would be reachable with the number keys.
Understandable. It just happens that I use a couple of commands that do not have an associated number more often a couple of the commands that do have numbers.
Personally I wouldn’t be against re-arranging the Git menu so that it would work better with letter keys, but I fear it would upset a lot of people who are e.g. used to ⌘Y + 2 for commit, etc.
If it would be possible to add keyboard shortcuts for the menu that is not dependent on the order, the existing order could be preserved for backwards compatibility. That is, it would be possible to use both numbers and letters.
The way it works is that the SCM bundle has a proxy item bound to ⌘Y (not the Git bundle!).
Aha, that's were it's hiding :)
/Jacob Carlborg _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 26 Oct 2015, at 1:16, Jacob Carlborg wrote:
On 2015-10-25 15:16, Allan Odgaard wrote:
Pressing A-Z already works to select the first item in the menu starting with that letter.
That does not seem to work properly. Pressing ⌘Y and then B will select "Branches" instead of "Browse Annotated File". For P it will select "Pop Stash" instead of "Pull".
To clarify, with first item I mean the first item in a lexicographically sorted list of all the items.
I.e. here “Bra…” comes before “Bro…” and that is why “Branches” gets selected.
One minor disadvantage of the current way that the letters work is that it will only select the command, not execute it.
Or advantage, if you would like to verify that you jumped down to the correct item.
FYI this keyboard support is standard menu behavior and not specific to TextMate.
Personally I wouldn’t be against re-arranging the Git menu so that it would work better with letter keys, but I fear it would upset a lot of people who are e.g. used to ⌘Y + 2 for commit, etc.
If it would be possible to add keyboard shortcuts for the menu that is not dependent on the order, the existing order could be preserved for backwards compatibility. That is, it would be possible to use both numbers and letters.
In the Subversion bundle we prefix items that we want to “skip” with a hair space (U+200A).
It does give the item a slight indent, but hardly noticable. The problem with the zero-width characters are, that they seem to be ignored by the “type to select” algorithm.
If you add hairspace to the Branches… menu item then please submit a PR as I also occasionally use Browse but never Branches.
FWIW; I do use "Branches.." and actually never used browse..
Koen
On Mon, Oct 26, 2015 at 4:12 AM, Allan Odgaard mailinglist@textmate.org wrote:
On 26 Oct 2015, at 1:16, Jacob Carlborg wrote:
On 2015-10-25 15:16, Allan Odgaard wrote:
Pressing A-Z already works to select the first item in the menu starting with that letter.
That does not seem to work properly. Pressing ⌘Y and then B will select "Branches" instead of "Browse Annotated File". For P it will select "Pop Stash" instead of "Pull".
To clarify, with first item I mean the first item in a lexicographically sorted list of all the items. I.e. here “Bra…” comes before “Bro…” and that is why “Branches” gets selected.
One minor disadvantage of the current way that the letters work is that it will only select the command, not execute it.
Or advantage, if you would like to verify that you jumped down to the correct item. FYI this keyboard support is standard menu behavior and not specific to TextMate.
Personally I wouldn’t be against re-arranging the Git menu so that it would work better with letter keys, but I fear it would upset a lot of people who are e.g. used to ⌘Y + 2 for commit, etc.
If it would be possible to add keyboard shortcuts for the menu that is not dependent on the order, the existing order could be preserved for backwards compatibility. That is, it would be possible to use both numbers and letters.
In the Subversion bundle we prefix items that we want to “skip” with a hair space (U+200A). It does give the item a slight indent, but hardly noticable. The problem with the zero-width characters are, that they seem to be ignored by the “type to select” algorithm. If you add hairspace to the Branches… menu item then please submit a PR as I also occasionally use Browse but never Branches. _______________________________________________ textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On Sunday, October 25, 2015, Allan Odgaard mailinglist@textmate.org wrote:
If you add hairspace to the Branches… menu item then please submit a PR as I also occasionally use Browse but never Branches.
Instead of adding a hair space, can we change the name of Browse Annonated File (Blame)… to just Blame…? I occasionally use it and I always seem to have a hard time finding it. I never use SVN where the command was initially "annotate".
On 26 Oct 2015, at 15:56, Ronald Wampler wrote:
On Sunday, October 25, 2015, Allan Odgaard mailinglist@textmate.org wrote:
If you add hairspace to the Branches… menu item then please submit a PR as I also occasionally use Browse but never Branches.
Instead of adding a hair space, can we change the name of Browse Annonated File (Blame)… to just Blame…? I occasionally use it and I always seem to have a hard time finding it. I never use SVN where the command was initially "annotate".
I agree. By now, I have gotten used to it being “Browse (something)…” but it took a while to get used to.
And then we’re improving both discoverability and key shortcut, so I guess that trumps Koen’s preference for Branches :)
On 2015-10-26 04:12, Allan Odgaard wrote:
To clarify, with first item I mean the first item in a lexicographically sorted list of all the items.
I.e. here “Bra…” comes before “Bro…” and that is why “Branches” gets selected.
Ok, I see.
Or advantage, if you would like to verify that you jumped down to the correct item.
You don't get that with the numbers
FYI this keyboard support is standard menu behavior and not specific to TextMate.
Yeah, I suspected that.
In the Subversion bundle we prefix items that we want to “skip” with a hair space (U+200A).
It does give the item a slight indent, but hardly noticable. The problem with the zero-width characters are, that they seem to be ignored by the “type to select” algorithm.
If you add hairspace to the Branches… menu item then please submit a PR as I also occasionally use Browse but never Branches.
I'll give it a try and see how it works.
Totally agree on the Blame thing, it’s so annoying for me that I have renamed it locally.
Two other things on my list:
- Fuzzy selection of branch names in the branches dialog – I just wish I knew enough to be able to fix this myself. - Fixing the issues with / in branch names.
-
Allan Odgaard -
George McGinley Smith -
Jacob Carlborg -
Koen Punt -
Ronald Wampler