Talk:Keyboard Shortcut Reference

Ed 29Aug13: I have a number of problems with this page:
 * The custom-built table of contents at the top does not look like "links" to sections on the page (this goes for all the other pages where we have used this same idea of a custom-built TOC but is worse here); I think we should label the table to make it clear what it is there for.
 * Gale 30Aug13: It's worth considering. Please suggest a name for the label, but note I am considering breaking up each menu section - see my comments on the article page.
 * Logically, we should point out at the very beginning that these are the default keyboard assignments.
 * Peter 30Aug13: I am more than somewhat averse to stressing that these are default assignments. Changing the assignments is something that you do only when you are very sure of what you are doing and when you are a confident user - as it potentially renders advice in the Manual/Wiki and on the forum potentially confusing.  I don't think we should be actively encouraging users to consider changing the default assignments.
 * Gale 30Aug13: I mildly agree with Ed - it isn't totally clear that the mauve shortcuts are what Audacity ships with. Ed, if you want to, please make a copy of the intro here (after 2.0.4) and see if you can work that in.
 * In re. the duplicated items (which I believe to be a P1 bug) I agree with Peter's comment "a difficult read and almost totally incomprehensible" even with Gale's recent changes.
 * Peter 30Aug13: I am minded to agree that this could be viewed as a P1 bug. It was poor design right from the start to have such duplicated commands, it confuses users and it leads to us making a complicated explanation on the KSR page.
 * Gale 30Aug13: Not P1. Developers would not stand for it. Probably P3/P4. You could only insist on P1 in commercial software. And I don't think the answer is to clutter the Align and Move Cursor menu with extra words. If that even happens it should be temporary.
 * I believe that when putting an asterisk on an item to denote that it has a footnote that asterisk should trail the item not preceded.
 * Gale 30Aug13: Are you talking about my change or something else? If my change, the bullet is not a footnote, and I tried asterisk at the end and felt it did not stand out sufficiently.
 * This page needs to be mercilessly edited for grammar (post 2.0.4)
 * Gale 30Aug13: Please give an example of bad grammar. Most of the wording on that page will be a repeat or condensation of the text on the menu page.

JamesCrook 19:08, 28 November 2009 (UTC) Content on the talk page now fully taken account of on main page.

Bill 17 Feb 11: Co mments on what I see here so far.

CTRL + N and Ctrl + N seem the most readable to me. Ctrl N and Ctrl + n are tied for third. Ctrl n is the worst.

Gale 16 Feb 11:

Example of only capitalising first letter of modifiers:

Stale discussion archived from the page
Gale:
 * I found "Special commands with no keyboard shortcut" just wasn't working for me. They are too hidden and it's not really understandable why these are separated when they fall into the functional groupings plan we have. So I moved them into functional groupings. Also moved the "move track focus" shortcuts from the Edit commands to Tracks commands.
 * Saying "Play" and "Stop" are single commands with a pre-assigned shortcut is incorrect, so I don't think we can. As menu items with no pre-assigned shortcut, they should not be mentioned if we stick to our previous idea. We could make an exception for these two, and have a simple statement without description of the other menu items which can have a shortcut assigned (current idea here). Or since we now have user-assigned items (as I think is important for the "special commands with no shortcut"), just go the whole hog and list the unassigned ones that are in the menus. Complete the descriptions for these sometime, but not necessarily for 2.0. It does have the advantage if we do allocate more of these in future, we don't have to do the work again.

Bill: Ed 8 December 2009 I note that we are not consistent about the way we list shortcuts sometimes it is ALT + CTRL + SHIFT, other times it would be CTRL + ALT + SHIFT or other combinations. I would like to propose that in the manual and the program both we settle on a fixed order and stick with it. The order that I would prefer would be CTRL + ALT + SHIFT + KEY.
 * I'm fine with this arrangement. Two points:
 * Although  is not listed in the Transport menu as a shortcut for Play and Stop (nor is it listed in the Keyboard Preferences), it does work and is mentioned elsewhere. It might be worth making a note of that in the Transport section.
 * Gale: The single commands are listed in the Transport list, but I think you are wanting to say they default to SPACE anyway on account of the Play/Stop?
 * Bill: What's there now is fine with me.
 * The only choice remaining to be made seems to be whether the unassigned menu shortcuts are listed before the table (as in the Transport section) or in the last row of the table (as elsewhere, and as described in the intro div). I have no preference either way.
 * Gale: Maybe at the bottom is better. Are you still opposed to listing all of those in separate rows instead of grouped in one row? The length of some of the tables is the only thing that stops me doing it.
 * Bill: Exactly. This page is very long as it is.
 * For shorter tables, especially for the odd situation in Transport where we have to have an explicit row for the individual Play and Stop, it would be a perfect solution.
 * Bill: Yes, I think we can treat the Transport Menu as a special case.
 * Plus if people do use this page as a one-stop place for quick text about what any shortcut-assignable command does, we seem to be devaluing that idea by not listing the menu items without a pre-defined shortcut. Maybe we could trim the quick text in places to make the tables a bit more manageable?
 * Bill: My view is that this is the "Keyboard Shortcut Reference". If a menu command does not have a default shortcut, we don't list it separately (except for a few special cases). I think we do need to list the commands that are not associated with a menu item, otherwise people won't even know they exist. 

Key-modified clicks
Gale 03May12: As agreed, documented in Keyboard Shortcut Reference
 * holding (or  on a Mac) while playing then left-clicking in the waveform moves playback position
 * holding then clicking in the waveform draws a selection between the editing cursor and the click point.

File commands with and without spaces

 * Bill 19Apr12: I'm not keen on switching to a monospace font in the middle of a line of text. I now agree that "Ctrl" looks too bunched up. Getting rid of the italic style doesn't help. I think the "expanded" letter spacing looks artificial and awkward. So +1 for maintaining all caps for shortcuts.
 * Peter 20Apr12:After pondering all the layouts on this page for quite a while - my preference is for the the third option in the box below. I could live with the fourth. Both of these options look, clean,crisp, modern and very readable to my eye. I really don't like the other typefaces on display here (I hate serifs by and large). For me what is important is that we have the mixed case for keys the Ctrl Alt etc and caps for single letter keys. I am becoming agnostic about spacing, though I really don't like large spacing and I really, really don't like a space before the plus sign and no space after as in "Ctrl +O" (the monospace looks really naff IMO and is the worst of the three basic options).
 * Gale: 20Apr12 I removed monospace except the first one and added more variants. Please re-vote or play with your own variants. To me, 1, 5 and 6 are just about acceptable of which I think 5 is best (though if we want to be "realistic" I don't know why we are considering italic). A stumbling block for me is any solution where there is a big gap between "C" and "t" of "Ctrl" - there is no such unreasonable gap in the app or a keyboard, but the point is that we can force the the font there, but without forcing load of a specific font stored on the server, you cannot force the exact font on a web browser.
 * Ed 20Apr12: #6 (prop, 1px, NOT italic) +1
 * Peter 21Apr12: ok, re-voting: I'm happy to settle for #6 +1, as Ed prefers it and it is one of Gale's acceptable options - and the more I look at it the more I like it.  I am persuaded aginst the italics; I don't like the induced gap either.  And absolutely -1 for #1 - I hate the serifs.
 * Steve 21Apr12: In order of preference: 5, 4, 6, 3, 7, 2, 8, 9, 1.
 * Bill 21Apr12: In order of preference: 4, 3, 6, 5, rest out of the running. I prefer 0.5px letter spacing over 1 px, and non-italic over italic. On my browser I see no difference between 7 and 8. I still have no objection to maintaining the current all caps italic bold (or simply removing the italic style from the template) with spaces around the "+" signs.
 * Peter 21Apr12: if it helps to break the deadlock I'll shift my principal vote to #4  with a preference order: 4,6,3
 * Gale 21Apr12: I made #4 0.7 px letter-spacing which is enough of an improvement for me to vote for #4 as first choice, #5 second. Note that while fractional px on letter-spacing works in current Firefox and IE9, it will probably render as 1px in older browsers; that might still argue for using #5 (1px, italic) instead which will appear to bunch it up a bit more. For me, #9 (tweaked a little) is clearest of all; I think the intuitive choice of "all caps" was the correct one all along.
 * Gale 26Apr12: Please confirm votes bearing in mind the new 0.7 px option. Also we want a serious volunteer to do all the work. If no real decision or consensus by the end of the month, it will stop as it is.
 * Bill 26Apr 12:
 * +1 for leave as is
 * +1 for spaces around the "+" sign
 * +0.5 for initial caps, 0.5 or 0.7 px letter spacing, no italic
 * -1 for monospace font
 * -1 for initial caps with no letter spacing
 * -1 for small caps
 * Peter 26Apr12: I confirm 4,6,3 as my preference order
 * +1 for initial caps, 0.7 or 0.5 px letter spacing
 * agnostic about italicising or not
 * agnostic about spacing around the plus sign (unless the space is large)
 * -1 for small caps
 * -1 for leaving it as-is
 * Gale 26Apr12: Here are the remaining contenders 3,4,5 and 6 with and without spaces between "+". I'm +0.5 on "5", +0.25 on "3+" and "6" and vetoing the rest (look naff or are too hard/uncomfortable to read).
 * Peter 27Apr: "5" or "6" would be fine by me - I definitely don't like "3+" (too spacey), so +1 on vetoing that and all the rest.
 * Gale 27Apr12: I added our votes into the table. Are you or Ed going to do the work?
 * Ed 29Apr12: #6+ has my vote; My understanding is that it would not require any editing of pages, just the span definition because it keeps the current <+>  and only changes by removing the italics (which I strongly support doing); I also like the tighter #4 and would be quite happy with .7 (probably anything .6 and up to 1.0)px spacing; bold is not necessary as we are already emphasizing with the highlight color. As for doing any potential grunt work, I would do it but be warned I am very busy until at least 5 May.
 * Gale 30Apr12: #6+ looks naff and hard to read IMHO so I assume you prefer #6 to #5 (the two candidates). How would we not edit pages when the shortcuts have been typed out in upper case? I tried "text-transform: capitalize" using an experimental "shtransform" span, but it does not make only the first letter of each word capitalised when the text is all caps, only if the text had been all lower case.
 * Ed30Apr12: my bad, all-caps seems ubiquitous throughout the manual; there are about 200 cases of CTRL, 250 of SHIFT (but many refer to "time shift" and would not need changing) and only 50 of ALT. Manually changing all of these would not be horrible using an external case-aware editor, I am willing to do so. My real "vote" is NO italics and at least .6px spacing
 * Bill 01May12:
 * +1 for #4 (no italic). Once you put in the letter spacing, the space around the "+" signs look awful. No space around the "+" will also prevent the span from breaking across lines.
 * +1 for no change, but if Ed or Peter is willing to do the work I have no objection.
 * Gale 01May12: My strong objection to #4 (frankly I still feel like vetoing it) is the space between "C" and "t" of "Ctrl" and the bunching of "f" and "t" in "Shift". This is mitigated with italic (#5) or 1px letter-spacing (#6). And given some browsers won't support lower than 1px letter-spacing anyway, that makes me think #6 is the best answer if we don't like italic. I still like the emphasis of italic using the shortcut in the middle of text. Also I'm not going to block it if Ed or Peter do all the work, I just feel in the end it won't be so readable as now.
 * Ed 1May12 I suspect that Gale and I are actually arguing for the same thing but our browser's fonts put us on opposite sides of the fence. I just made my browser (Chrome) display this page in 100% (i.e. zero) magnification, did a screen grab of the samples and looked at the kerning. On my system italics makes the kerning so messed up the text is unreadable. Gale's complaint about the "C" and "t" having too much space (#4) is not apparent here--in fact, with anti-aliasing the left-most pixel of the "t" is actually inside the "C"; however, performing the same test with IE9 I see the kerning between the "C" and "t" is one pixel wider. The same comparison of the two "f" and "t" samples show the kerning to be identical there. I will admit Bill's point that "no space" causes no line breaks which seems good.

File commands
Bill 17 Feb 11: And three more permutations: lower case letter, lc no plus sign, UC and no plus sign.