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 -- http://mail.python.org/mailman/listinfo/python-list
