pep 8 constants

[Eric S. Johansson]

Tim Chase wrote:
> Eric S. Johansson wrote:
>

np. I get this confusion often.
> 
> While I have used SR in some testing, I've found that while it's
> passable for prose (and even that, proclamations of "95% accuracy" sound
> good until you realize how many words comprise 5%  of your daily typing
> :), it's not so good for code unless you have a very specific
> programming-language+SR designed editing environment...as you've been
> griping.  However, the problem seems not to be PEP-8, but rather the
> inabilities of your SR combined with the failings of your editor.

I've been working with speech recognition for 15 years. I've written something
on the order of 10,000 lines of Python code both as open source and private
projects. I've tried it least two dozen editors and they all fail miserably
because they're focused on keyboard use (but understandable) I get good
recognition accuracy because I train the system and then I let it train me.
> 
> For coding, you might want to investigate a tool like Dasher[1] which
> offers an alternate form of input.  It allows for custom
> vocabularies/keymaps if you need, as well as more precise specification
> of a full keyboard (caps vs. mixed-case, specific punctuation
> characters, etc).  The predictive entry should be smart enough to pick
> up previously entered constants/terms saving you entry speed.  It can
> also be driven by a wide variety of pointing devices (mouse, trackball,
> touchpad, head-tracker, gyro-input, etc).

I've tried it, it's quite promising but my hands term are sufficiently that I
can't target accurately. This is a problem for me with mice as well. Maybe these
tiny little spit dot icons and webpages drive me insane because it takes me two
or three tries to put the right spot.

 but still, you would have the basic problem of getting the information about
the code into language model of dasher so it could predict what might be chosen
based on the previous context. It' 80% the same work and, doesn't help those of
us with really bad hands.
> 
> You might also experiment with other editors that allow for more
> efficient editing.

I've tried a whole bunch, like I said at least a dozen. They all fail for first
reasons such as inability to access all functionality through keystrokes
(easiest interface method from speech recognition) to virtually no
autoformatting or worse yet, inconsistent autoformatting. The classic example is
auto indentation based on previous lines. Emacs does a relatively right.

I know this is also counter to the Python way but having something marking and
outdent would be really useful so that a vocal driven command to indent or
outdent a block would be practical. Oh, another failure point. Have you ever
tried to selected beach and by voice. I mean I should say have you ever tried to
select a region by voice. Doesn't work very well. Nuance has something called
selective  and say but it only works in very special Windows edit controls. Or,
if you're doing toolkit supports the right signals/events. Nobody does in the
the linux world and it doesn't look like they support them in the Windows world
either.
> 
> Hope these give you another option to consider, if SR plus your current
> editor aren't cutting it for you,

maybe we should have a conversation off list about different editors if you
don't mind. I'm certainly open to alternatives but, I do have fairly high
standards and one of them is that ^X^S doesn't crash the editor. :-) I have been
using Emacs for too many years and it is such a reflex.

Another alternative would be to help fix the NaturallySpeaking Emacs gateway
vr-mode.  While it doesn't truly improve the problem, it makes it a little more
manageable.

thank you for your time