[BRLTTY] Explicit toggle change

[Mario Lang]

Stéphane Doyon <s.doyon at videotron.ca> writes:

> in r7287 you have "Indicate via a tune if an explicit toggle change is
> redundant."
>
> Can you explain the rationale?
>
> With the Alva BC640, Baum, and many others I think, we use separate
> bindings for explicit CSRTRK+on and CSRTRK+off. One reason we have
> this is so we don't have to remember the state. And one convenience is
> we can always use CSRTRK+on to both have the effect of HOME plus
> ensuring tracking is back on. With the new change, if I do CSRTRK+on
> while tracking is already on, I don't get my HOME effect. And I find
> the new beep really strongly conveys that I did something wrong, I
> find it realyl arresting. In short, I don't think I like the change at
> all :-). But perhaps you had a situation where it's beneficial? I
> suppose the side-effect of going back to the cursor on CSRTRK+on means
> it's not truly a toggle...

While I did not argue against it when it was developed, I have
to admit that I found tghis behaviour counterproductive a few days ago
as well.  If you know some keys are explicit toggles, you can "hear"
what they do if you forgot by simply pressing them.  However, if the
state they toggle is already on, this does not work anymore since you
hear the new "unable to toggle" sound, and need to switch to the other
state to figure out which is which.  In the worst case, the other state
is exactly what you didnt want, so you switch back again.

-- 
CYa,
  ⡍⠁⠗⠊⠕ | Debian Developer <URL:http://debian.org/>
  .''`. | Get my public key via finger mlang/key at db.debian.org
 : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
 `. `'
   `-      <URL:http://delysid.org/>  <URL:http://www.staff.tugraz.at/mlang/>