BBEdit 12 Changes Spacebar Mapping in Save Sheet Prompt

[Scott in Pollock]

Good morning all...

In previous versions, when you closed an unsaved document (or one with unsaved changes), and you had "Full Keyboard Access" in System Prefs turned on, there were three single-key mappings available:

1.) Return to Save

2.) esc to Cancel

3.) SpaceBar to Don't Save

In v12, the SpaceBar has been hard-coded against standard OS behavior to 'SAVE' instead of 'Don't Save' due to a number of complaints by users who have dismissed their unsaved changes by hitting the SpaceBar at this Save sheet prompt. Those users could have simply turned off Full Keyboard Access in System Preferences or used the global keyboard shortcut CNTRL-F7 to toggle the setting.

Am I the only one unhappy with this? Almost every app I use behaves this way, and I am quite used to the workflow. I often open files/send text to BBEdit to woof up some text (like composing this message) or try something out and do not save a doc or changes, and simply hitting the SpaceBar after closing is what I have been trained to do since MacOS 10.5.

Now, the SpaceBar SAVES changes (along with the ENTER and RETURN keys), so if I hit that from years of muscle memory, I have to reopen the document and go through the process of locating all changes I was testing and back them out (or restore from a TM backup). So now, one of my most often used apps behaves differently than all the rest of them.

I am curious if I am the only one really bugged about this behavior change, especially since there was a perfectly workable solution in the System Prefs for those users who were losing unsaved changes by accidentally hitting the SpaceBar when closing their doc without saving their work.

Thoughts?

[Brian L. Matthews]

On 10/14/17 5:04 AM, Scott in Pollock wrote:
> In previous versions, when you closed an unsaved document (or one with
> unsaved changes), and you had "Full Keyboard Access" in System Prefs
> turned on, there were three single-key mappings available:
>
> 1.) Return to Save
>
> 2.) esc to Cancel
>
> 3.) SpaceBar to Don't Save
>

> [...]

>
> Am I the only one unhappy with this?

Nope. This is driving me nuts. I have two primary workflows with BBEdit.
One is the standard file editing. The other is when I'm composing
something online or editing some text in an application that has minimal
text editing capabilities. I compose in BBEdit, copy it, then close the
BBEdit window, hitting space to discard it in the resulting dialog.

I'm sure given time I'll relearn, except I'll have to remember to do it
just in BBEdit, and it seems kind of odd, given three buttons, to have
two keys mapped to one, one to another, and none to the third.

Brian

[Rich Siegel]

On Saturday, October 14, 2017, Scott in Pollock

<scottin...@gmail.com> wrote:

>Those users could have simply turned off Full Keyboard Access in
>System Preferences or used the global keyboard shortcut CNTRL-F7 to
>toggle the setting.

>[...]

>I am curious if I am the only one really bugged about this
>behavior change, especially since there was a perfectly
>workable solution in the System Prefs for those users who were

>losing unsaved changes by *accidentally* hitting the SpaceBar

>when closing their doc without saving their work.

To reprise and amplify on the answer you received when you wrote
in to Tech Support:

The "Full Keyboard Access" setting is an accessibility feature
of the OS, designed primarily to serve the needs of users with disabilities.

We received feedback from customers who use that accessibility
feature, indicating that data loss was occuring with the
previous default setting, which encouraged us to reconsider the default.

While we understand the power of muscle memory and the
importance of convenience, we believe that a customer who
*needs* Full Keyboard Access in order to use our software should
not be exposed to a greater risk of data loss than someone who
uses the feature for convenience.

People who need an assistive feature can't "just turn it off",
so while we're sensitive to the fact that you will need to adapt
to using a different keystroke, on balance, we've had to make
the decision that potential data loss is a more pressing concern.

In this case, it's not a question that yields to an "argumentum
ad numerum."

There are functioning solutions that have worked in BBEdit since time
out of mind:

- Command-Delete (backspace) is a system-standard shortcut for
"discard changes", and works in this confirmation panel as an
equivalent for "Don't Save".

- Command-D still works as a keyboard equivalent for "Don't
Save" in this confirmation panel.

- With Full Keyboard Access turned on, you can use the Tab key
to navigate between accessible buttons in any window, and that
works here as well. One press of the Tab key will move keyboard
focus to the "Don't Save" button. (I know it's an extra
keystroke; if your Tab key wears out I will buy you a new one.)

As mentioned above, we realize that any of these will require
you to adjust your keyboarding habits in this particular case,
and I'm sorry about that. But in this case we've decided that
it's better to not put users who *need* the assistive feature at
greater risk of data loss.

(If there's going to be any change made, it will likely be to
default keyboard focus to "Cancel" rather than "Save", since you
make a good point about unintentionally saving a document. But
you'll still need to practice your Command-D or Command-Delete.)

R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>

Someday I'll look back on all this and laugh... until they
sedate me.

[Bruce Van Allen]

Looks like something to be addressed in the next point update.

> This is the BBEdit Talk public discussion group. If you have a feature
> request or would like to report a problem, please email
> "sup...@barebones.com" rather than posting to the group.

On 10/14/17 5:04 AM, Scott in Pollock wrote:

>In previous versions, when you closed an unsaved document (or ...

On 10/14/17 at 8:26 AM, blmat...@gmail.com (Brian L. Matthews) wrote:
> >Am I the only one unhappy with this?
>
> Nope. This is driving me nuts.

--

- Bruce

_bruce__van_allen__santa_cruz__ca_

[Scott in Pollock]

On Saturday, October 14, 2017 at 8:59:47 AM UTC-7, Rich Siegel wrote:

To reprise and amplify on the answer you received when you wrote 
in to Tech Support: 
The "Full Keyboard Access" setting is an accessibility feature 

of the OS, designed primarily to serve the needs of users with disabilities…

Hi Rich,

Thank you for your reply. TBC, the email I received from Patrick made no mention that those with disabilities were among the users asking for this behavior to be changed so it did not correlate with me.

But since the change is obviously hard-coded in, how about simply the ability to flip those bits off via a pref. Make the new behavior the default and give us an Expert Preference so those could restore the behavior they have come to expect over the years (and use in other apps)? Being an Expert Pref, it won't get accidentally set, and everyone wins, right?

[Rich Siegel]

On Saturday, October 14, 2017, Scott in Pollock
<scottin...@gmail.com> wrote:

>But since the change is obviously hard-coded in, how about
>simply the ability to flip those bits off via a pref.

We'll put it on the whiteboard for consideration.

[Bob Kennedy]

Excellent discussion and great explanations here, guys.  Thanks so much. 

That design decision was bugging me too, until I found this post.  I'm so glad to learn of Command-D, since it may work even better than space bar in 'not saving', at least for those times when the prompt appears just after I used Command-W to close the window.

On Saturday, October 14, 2017 at 12:45:59 PM UTC-4, Rich Siegel wrote:

On Saturday, October 14, 2017, Scott in Pollock
<scottin...@gmail.com> wrote:

...

[Jim Danner]

I'd like to "+1" the request to make this an expert preference. After more than a year, I still have to remind myself to hit Tab twice when closing to discard changes.