Ctrl-[ and Ctrl-] collapse select region

[DickN]

Using Vista SP2,
Audacity 2.2.0-alpha builds from 20-Mar through 09-May-2017

All Audacity revs are from the zip files, for my convenience when comparing them.

If I have a region selected and press Ctrl-[ or Ctrl-] to jump to the beginning or end of the select range, the select range collapses to the new cursor position.
I've isolated the initial appearance of this behavior to the 20-Mar build. I haven't tested every build since my previous "happy with it" 25-Feb version, just did a binary search to find the behavior change. So my current "happy with it" build is 18-Mar-2017 (unless I find a new glitch, in which case you'll be the next to know...).

- DickN

[Gale Andrews]

Thanks for testing. I don't see that in r85e984 of "Tue May 9 09:23:45 2017 -0400" on a mono or stereo track, so could you please add some more detail to your steps.

Alpha builds are not production releases, so don't forget to export WAV files frequently to prevent possible loss of your work.


Gale

[steve]

Yes, thanks for the report Dick. I'm not seeing this behaviour in a May build on Linux.
Have you tried resetting preferences? If you have preferences that you want to keep, you can just close Audacity, then (temporarily) rename the audacity.cfg file, then re-launch Audacity and test.

[DickN]

Could be the problem was I had Ctrl-] and Ctrl-[ assigned to both "Cursor to ..." and "Skip to ...". When I renamed audacity.cfg in portable settings (I've been copying that folder to each version when I test it), the keyboard shortcuts disappeared. So I tried to set these again to "Cursor to..." and got the error dialog that they were already assigned to "Skip to...". When I view the settings with the old audacity.cfg reinstated, I see that these shortcuts are assigned to both command types. That didn't seem to be a problem before 20-Mar.

18-Mar build won't be my "Happy with it" version. When I try to save project, I get "Audacity could not read file at .", and the autosave folder is empty.
There were three .tmp files with hex names in the folder (not the _data folder) containing the project, with time stamps around the time I tried to save. Out of curiosity, I tried renaming one of them to *.au and feeding it to SoX. It gave me an error message, although it does play .au files.

- DickN

[steve]

Could be the problem was I had Ctrl-] and Ctrl-[ assigned to both "Cursor to ..." and "Skip to ...".

That does explain the behaviour.

When I renamed audacity.cfg in portable settings (I've been copying that folder to each version when I test it), the keyboard shortcuts disappeared. So I tried to set these again to "Cursor to..." and got the error dialog that they were already assigned to "Skip to..."

It shouldn't be possible to set a key binding to more than one command (except the special case "Play / Stop") because doing so is not defined in the code. The code expects key bindings to be unique.

In my opinion, there is a bug here, but it is not the "Ctrl + [" / "Ctrl + ]" behaviour per se, but is that Audacity does not validate the keyboard preferences before loading them. I also think this is quite a serious bug because input should always be validated.

[Gale Andrews]

It shouldn't be possible to set a key binding to more than one command (except the special case "Play / Stop") because doing so is not defined in the code. The code expects key bindings to be unique.

Left and Right are special cases too that are each allocated to two commands.

If you try to set for example Save Project As... to Left, Audacity tells you Left is allocated to "Short seek left during playback". You can OK that dialogue to allocate Left to Save Project As... but this means that Left is now allocated to both Save Project As... and Cursor Left (both bindings are visible in the menus).

Input validation at next load of bindings would fix it but the confirmation dialogue when you changed bindings should have asked to clear Cursor Left as well. This would be a separate item for bug tracking, I think.


Gale

[DickN]

OK, I've resolved the conflict by clearing the assignments of Ctrl-[ and Ctrl-] from "Cursor to...", since I never consciously used the hotkeys for that anyway. If I had a region selected, I just used the left or right arrow key to jump to that end of the region and clear the selection.

Now using 2.2.0-Alpha-09-May-17 (with Vista SP2).

With this build, as with the 25-Feb version from which I copied the Portable Settings after making this change, the response to Ctrl-[ and Ctrl-] is as expected, at least when there is a selection. However, when there is no region selected and the cursor is off the screen, these shortcuts do nothing.

I remember a time before Audacity had (or at least before I knew about) this command, when I routinely hit Left-arrow, Right-arrow to get the cursor location on-screen. That still works but, now that I'm spoiled with the way that dual assignment of Ctrl-brackets used to work, I miss having a simple way to bring the selection on-screen regardless of whether it has nonzero size or null size. I therefore request that the "Go to Selection [start|end]" commands bring the cursor location on-screen when there is no select region.

- DickN

[Gale Andrews]

Now using 2.2.0-Alpha-09-May-17 (with Vista SP2).

With this build, as with the 25-Feb version from which I copied the Portable Settings after making this change, the response to Ctrl-[ and Ctrl-] is as expected, at least when there is a selection. However, when there is no region selected and the cursor is off the screen, these shortcuts do nothing.

I remember a time before Audacity had (or at least before I knew about) this command, when I routinely hit Left-arrow, Right-arrow to get the cursor location on-screen. That still works but, now that I'm spoiled with the way that dual assignment of Ctrl-brackets used to work, I miss having a simple way to bring the selection on-screen regardless of whether it has nonzero size or null size. I therefore request that the "Go to Selection [start|end]" commands bring the cursor location on-screen when there is no select region.

I agree, and I would vote for it. An advantage of these commands working on the cursor would be that you could centre the cursor even if it was still on screen.

So do you want to request your "vote" to be added for this?


Gale

[DickN]

An advantage of these commands working on the cursor would be that you could centre the cursor even if it was still on screen.

So do you want to request your "vote" to be added for this?


Gale

+1

-DickN

[Gale Andrews]

I added three votes (yours, mine and someone else who wrote to our feedback address). Note that by default (when "Select... entire project" autoselection is on) these commands would not do nothing but select all and so destroy the cursor position.


Gale

An advantage of these commands working on the cursor would be that you could centre the cursor even if it was still on screen.

So do you want to request your "vote" to be added for this?


Gale

+1

-DickN