[Python-mode] more speech driven how twos
andreas.roehler at online.de
Sat Jun 18 13:41:57 CEST 2011
Am 17.06.2011 19:41, schrieb Eric S. Johansson:
> On 6/17/2011 12:18 PM, Andreas Röhler wrote:
>> Am 17.06.2011 16:02, schrieb Eric S. Johansson:
>>> making more progress on some of the tools I need for speech or
>> [ ... ]
>> Hi Eric,
>> thanks reminding at that. Seeing you introduced a blueprint. Your
>> previous text went into the `second-level-commands'.
> Yeah that was probably a speech recognition error. Speech and browsers
> do not get along well
IIRC that's me who put it into some times ago :)
[ ... ]
> use Dragon NaturallySpeaking for speech recognition system. Runs on
> Windows I use a community built extension called vocola to generate
> macros and some degree of smart user interface with Python extensions to
Thanks, see it.
BTW what are suitable returns from Emacs report functions for you.
As choices coming into my mind for the moment are:
- simple get it returned
- display in mode-line
- so-called speed-bar
Instead of a simple return it might be send so a program...
> My currently preferred Emacs is Xemacs for political reasons
> I'm not sure what you need in a technical description. Normally in a
> speech recognition environment you use either fixed grammars or
> contiguous dictation. I am building a hybrid where you use a fixed
> grammar with contextually dependent elements and interact with GUI
> elements to make an unspeakable process speakable.
> the process of making the unspeakable speakable involves identifying and
> extracting information from the application and transforming it into a
> speakable form before displaying it in a second application which can be
> manipulated. See blog.esjworks.com for more complete examples.
> I expect that most of the action routines for a complete grammar will
> just be Emacs keystrokes invoking Emacs methods via keyboard input. It
> would be nice to do a direct injection of commands to eliminate problems
> with errors in command execution caused by too fast a rate of injecting
> characters. A direct access channel would also allows to query the
> buffer for state information which could be used to influence the action
> The commands I asked for it which have no need to export information to
> any external program would help me get a better feel for if I'm on the
> right track or not. If there's something I use regularly and they "feel"
> right" is a vocal damage through excessive use, then I'm on the right
> path. If not, I need to look at the problem again they come up with a
> better solution.
> An example of a more complicated spoken command is the "get method"
> command. The first thing the command does is search to the right for the
> next method. An alias for it would be get next method. Going in the
> other direction would be get previous method. Once the method was
> identified, it would be placed in the region, mark on the left, point on
> the right. The action routine for the grammar would then invoke a GUI
> helper program to manipulate symbol names that pass the existing name
> along to it. The resulting change method would be returned via a
> different grammar and action routine, "use < transformation type>", and
> the result would be placed back into the buffer replacing what was in
> the region.
> Making any sense?
It does. However, it's a new and vast matter for me. So let's proceed
step by step and see how it goes.
Let's start with the report-function, telling where you are in code.
Agreed? So I will dig a little bit into the question, how the results
from Emacs are taken up in your environment.
More information about the Python-mode