[Python-mode] more speech driven how twos

Andreas Röhler 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
>>> programming.
>>
>> [ ... ]
>>
>> 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
> vocola.

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
- message-buffer
- tool-tip
- 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[1]
>
> 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
> routine.
>
> 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.

Cheers,

Andreas




More information about the Python-mode mailing list