special editor support for indentation needed.
Eric S. Johansson
(specifically mobility impaired speech recognition users), and hitting a bit of
a wall. The wall (for today) is indentation. I need a method of getting the
"right indentation" without having to speak a bunch of unnecessary commands.
For example, depth specified by the previous line. But, frequently you need to
go to a more arbitrary indentation for example the right level of indentation
for a method definition or class definition. This indentation should be
something you could get by typing/speaking the right command with your eyes closed.
For example if I was to give the command "new method", I should be able to spit
out a template (contained within the speech recognition environment) and through
a command embedded in the template, force indentation to the right level for
"def" and then the editor would control indentation for the rest of the text
injection.
I prefer are working in Emacs because that's where I have a lot of my speech
grammars set up but I'm not averse to trying another editor. The only condition
is that the editor must run a Windows and have remote editing mode (like tramp)
so I can edit on remote machines.
ideas?
Almar Klein
First of all, I like your initiative.
I'm not sure if I undestand you correctly, but can't you just
increase indentation after each line that ends with a colon?
That's how I do it in my editor. The user would then only need
to specify when to decrease indentation.
Cheers,
Almar
2008/11/14 Eric S. Johansson <e...@harvee.org>:
Matimus
You could make use of something like 'pindent.py' (comes with python
in windows under the \Python2x\Tools\Scripts folder). Which allows you
to put in block delimiters as comments, and then fixes the code to
align itself correctly to those blocks:
def foobar(a, b):
if a == b:
a = a+1
elif a < b:
b = b-1
if b > a: a = a-1
# end if
else:
print 'oops!'
# end if
# end def foobar
Funny though. I always saw this tool as a sort of joke response to
people who missed their block delimiters. "You want block delimiters?
Use this." And see how long before they decide it is silly.
Matt
Eric S. Johansson
> Hi Eric,
>
> First of all, I like your initiative.
there's nothing like self interest to drive one's initiative. :-) 14 years with
speech recognition and counting. I'm so looking to my 15th anniversary of being
injured next year....
another initiative is exporting the speech recognition environment to the Linux
context. In a nutshell, he dictated to application on Windows, it tunnels over
the network to a Linux machine, and will allow you to cut and paste to and from
that Linux application. I could definitely use some high quality volunteer
talent for this effort. it would make a huge quality of life difference to
disabled developers. This work would also be usable by the folks in the wine
project who are supporting NaturallySpeaking.
> I'm not sure if I undestand you correctly, but can't you just
> increase indentation after each line that ends with a colon?
> That's how I do it in my editor. The user would then only need
> to specify when to decrease indentation.
here's an example of the problem:
class foo( object):
def cat(self)
self.x=1
def dog
self.x=2
this is legal Python but it's not what you need 99% of the time. There is no
cue to the editor to tell it to outdent to give me what I really want which is:
class foo( object):
def cat(self)
self.x=1
def dog
self.x=2
so there should be a mechanism for saying "indent the level of the previous
definition". For what it's worth, this would translate in speech recognition of
arm in vocola pseudocode to
new method = <def indent>def ^(self):{enter}"""{enter}"""{enter}<srch backwards
and delete ^>
which would allow me to create a method definition and put me back at a place
where I can speak the method name. There's other stuff in these be done like
allowing you to modify various features by names such as adding/deleting
arguments, modifying array indices etc. If you are not careful, I'll talk about
command disambiguation through scope reduction and the related visual elements
in the working environment.
I really need a job doing this UI stuff. :-)
drob...@gmail.com
The backspace key in emacs does exactly what you want. Have you tried
it?
For python.el, distributed with Gnu Emacs:
DEL (translated from <backspace>) runs the command python-backspace,
which is an interactive compiled List function in `python.el`
For python-mode.e, distributed with XEmacs (but usable with Gnu
Emacs):
DEL (translated from <backspace>) runs the command py-electric-
backspace, which
is an interactive compiled Lisp function in `python-mode.el'.
Eric S. Johansson
yes and it doesn't work right. Type this in:
class pet (object):
"""
"""
def cat(self):
"""
"""
if food in bowl:
self.empty = True
def dog(self):
"""
"""
if food in bowl:
self.empty = True
else:
self.bark_nonstop()
at the end of the method cat, a newline puts you at the left-hand margin and a
subsequent tab lines you up with self.empty. Pressing backspace at that point,
terminates the if. It's reasonable behavior and should be useful when assigned
to the "close block" utterance. But remember, my goal is to have a variety of
options for selecting the correct level of indentation with my eyes closed.
Speaking a lot to get a little effect is dangerous to the health of one's vocal
cords and, a text-to-speech output doesn't let you know what lines up with what.
for what it's worth, in thinking about this problem, try to figure out what you
would say to someone who is slightly deaf and a poor typist to get them to
generate the code you want. Then figure out what you want to say in the same
situation if you had a bad sore throat.
---eric
drob...@gmail.com
you hit backspace? What is it that you would like to have happen?
Eric S. Johansson
> I don't understand. If you don't want to terminate the "if", why do
> you hit backspace? What is it that you would like to have happen?
the goal is to make some aspects of indentation behave the same without context
dependency. this goal exists for many features of programming assistance
because it's a prerequisite for lowering the vocal load for this aspect of
programming by voice
I want three indentation adjustment tools. Indent to where a class should be,
indent to where a method should be, and outdent n levels (close block
(once|twice|thrice)). This is probably best shown by example although, I'm not
guaranteeing my example will make it any clearer. :-)
the current outdent capability conflates multiple outdent events. The outdent
events are, at a minimum,:
Close block
close method
close class
Another way to look at these events are start method, start class and close
block. Now using these events, let's compare a use case against the outdent
mechanism.
starting with an example of a previous message,
class pet (object):
"""
"""
def cat(self):
"""
"""
if food in bowl:
self.empty = True
def dog(self):
to start the dog method, after ending the Method, I would need to say something
like:
newline tab key Close block close block delta echo foxtrot dog left paren self
close paren colon...
But if the method ended like:
...
def cat(self):
"""
"""
self.empty = True
def dog(self):
I would only want to use a single "close block" to outdent. unfortunately, this
context dependent behavior is frustratingly wrong when it comes to creating
speech driven macros to enter templates. it requires user intervention to tell
you how may times to outdent and that's counterproductive at best and physically
damaging at worst for a disabled user.
any clearer?
Aaron Brady
Greetings, Eric, great to read your posts.
You'll acknowledge that there is no deterministic way to add newlines
to a string of Python code. That is, the following are all equivalent
up to whitespace, syntactically correct, and distinct.
def cat(self):
""
if food in bowl:
self.empty = True
def dog(self):
...
def cat(self):
""
if food in bowl:
self.empty = True
def dog(self):
...
def cat(self):
""
if food in bowl:
self.empty = True
def dog(self):
...
def cat(self):
""
if food in bowl:
self.empty = True
def dog(self):
...
def cat(self):
""
if food in bowl:
self.empty = True
def dog(self):
...
You noticed that the second-to-last one uses a variable that isn't
guaranteed to be defined.
You instructed the audience to imagine reading with its eyes closed.
I imagined concluding the "self.empty= True" line, saying 'close
block' aloud, and hearing a verbal prompt in response.
'Close block def or block if?'
Uttering 'if' in response, results in a dedent by one level, and 'def'
causes a dedent by two levels. If these statements are occurring in a
class statement, you could expect a prompt:
'Close block class, block def, or block if?'
A more elaborate program structure might require this prompt:
'Close block class, first block def, second block def, or block if?'
As your examples suggest, you'd have to omit doc strings when scanning
blocks, so that you don't get caught on something that might only be a
comment, and not executed.
Eric S. Johansson
you meant indentation instead of newlines?
you are right all of those examples are syntactically correct and distinct.
This is why shifting the target of that to instead of specifying an outdent as
the mechanism for achieving proper indentation, instead naming the type of
indentation and using that as the cue for how far to indent.
examples:
Class indent: indent as far as the previous (non-commented, not in string) class
definition. If there is no previous class definition, indentation is set to zero.
Method indent: indent as far as the previous (non-commented, not in string)
method. If there is no previous method definition, search for the previous
class definition and indent by the number of spaces as determined by the editing
environment. if there is no previous class definition, indentation is set to zero
nested indent: bad name but, it's midnight. Indent according to the previous
line. Alias for normal indentation (automatic, not bound to any particular
grammar).
function indent: indent set to zero.
using these definitions, most of the time indentation will be deterministic and
achieved using a single utterance.
> def cat(self):
> ""
> if food in bowl:
> self.empty = True
method indent
> def dog(self):
> ...
>
> def cat(self):
> ""
> if food in bowl:
> self.empty = True
end block
> def dog(self):
> ...
>
> def cat(self):
> ""
> if food in bowl:
> self.empty = True
nested indent
> def dog(self):
> ...
>
> def cat(self):
> ""
> if food in bowl:
> self.empty = True
function indent
> def dog(self):
> ...
>
> def cat(self):
> ""
> if food in bowl:
> self.empty = True
nested indent
> def dog(self):
> ...
>
> You noticed that the second-to-last one uses a variable that isn't
> guaranteed to be defined.
yes, I've seen at least a couple exceptions from that type of situation.
>
> You instructed the audience to imagine reading with its eyes closed.
> I imagined concluding the "self.empty= True" line, saying 'close
> block' aloud, and hearing a verbal prompt in response.
>
> 'Close block def or block if?'
that's a good catch. If the system has to ask me something to clarify, it's
telling me that I screwed up. It's also forcing me to think about something
other than the task at hand and say something I shouldn't have to say. Another
thing to think about is the cognitive overload a developer experiences when
using speech recognition. Normally, you're thinking about the context within
the project, the code, the IDE/editor and now add to that, saying the right
command while thinking about how to correct your code when the inevitable
misrecognition happens and triggers a sequence of IDE operations that you can't
reproduce.
So, if you make the assumption that "close block" does exactly 1 thing (i.e.
close the most recently opened block), you reduce the load on the user and allow
them to spend those cycles on what's important i.e. writing/editing/debugging
the code
> Uttering 'if' in response, results in a dedent by one level, and 'def'
> causes a dedent by two levels. If these statements are occurring in a
> class statement, you could expect a prompt:
>
> 'Close block class, block def, or block if?'
>
> A more elaborate program structure might require this prompt:
>
> 'Close block class, first block def, second block def, or block if?'
Think about being asked that question every time you close a block. I can
almost guarantee it would drive you mad which is why I advocate for the one
utterance, one result, no decisions type of interaction. I mean, I have a bit
of a time dealing with misrecognize commands coming out as plaintext. Think
about what happened if the sentence I'm dictating now was injected into VI in
command mode? if not VI, how about mutt or any other application with single
letter commands? horrifying, isn't it?
Aaron Brady
> Aaron Brady wrote:
> > On Nov 14, 8:01 pm, "Eric S. Johansson" <e...@harvee.org> wrote:
> >> drobi...@gmail.com wrote:
> >>> I don't understand. If you don't want to terminate the "if", why do
> >>> you hit backspace? What is it that you would like to have happen?
> >> the goal is to make some aspects of indentation behave the same without context
> >> dependency. this goal exists for many features of programming assistance
> >> because it's a prerequisite for lowering the vocal load for this aspect of
> >> programming by voice
>
> >> I want three indentation adjustment tools. Indent to where a class should be,
> >> indent to where a method should be, and outdent n levels (close block
> >> (once|twice|thrice)). This is probably best shown by example although, I'm not
> >> guaranteeing my example will make it any clearer. :-)
>
You see examples here from time to time that don't follow the rigid C+
+ formatting. Some examples:
def classmaker( ):
class X:
something
return X
class X:
class Y:
something
if something:
class X:
pass
else:
def X( ):
pass
Some of these are tricky not dirty; some are both, but you don't want
to tie your hands prematurely, which is one of my favorite features of
Python. Long story short, it can get hairy.
Why aren't you favoring, 'dedent once/twice', 'dedent' repeated,
'close class, close function, close if, close for'? I don't imagine
that saying 'close' three times in a row would be a strain.
If the program is clever, it can learn that 'function' and 'method'
are synonyms, and you can start to think in terms of both.
You don't need to write 'start method, start class', except as a
shortcut for spelling the statements out by hand; what type of block
statement (suite) you are starting is determined by syntax.
I understand that you don't want to rewrite the entire Python
interpreter to make sense of input. Perhaps some of the utilities in
'code' module, such as 'compile_command', could do some of the work.
That module is able to make sense of partially complete statements.
I retract my suggestion that the system prompt you for information.
Academically speaking, context can partially eliminate redundancy.
That is, 'close' can stand alone, regardless of what block you are
closing. If you aren't maintaining a tyrant's grip on the tool, that
is, allowing it to think for itself a little or anticipating, a
miscommunication is inevitable, and it will need to corroborate the
element of the context that has fallen out of sync. Some people
bother to maintain a model of the speaker's knowledge state, and even
maintain multiple (non-unique) branches between the time an ambiguity
is recognized, and the time it's resolved.
Single-line blocks can follow their overture on the same line, such
as:
if x: x()
> you meant indentation instead of newlines?
I guess I meant whitespace generally, though newlines are the less
common case.
> It's also forcing me to think about something
> other than the task at hand and say something I shouldn't have to say.
Some languages require that, some allow it. BASIC, for example,
permits 'end if' and 'end for' statements at the end of the respective
control structures. It could be intrusive to require that, though it
could be a sanity check to permit it.
> Think about being asked that question every time you close a block.
Some people do it. 'What are you doing?', 'Where are you going?',
'Are you leaving?', 'Where were you?', 'I thought you left,' etc.
> I can
> almost guarantee it would drive you mad
Perhaps it does. Honest curiosity and vicious curiosity are only
distinguishable after time.
John Yeung
out of lurker mode.
Eric, I would like to say I also admire your initiative, but even more
so your patience. You seem to handle comments of all types
gracefully.
Perhaps it comes from working with speech recognition so much. I
imagine that if you are using a speech-based programming environment
and get frustrated with how stupid it is, and tell it off, you only
manage to create more of a mess for yourself to clean up. I think
most of us who rely on our vision and typing lose our cool more
easily, partly because the penalty for us is not as great.
Anyway, sorry for being a bit off-topic. I'm afraid I don't have a
lot to offer on the topic. My thoughts as I was reading the earlier
comments is that Python, by its nature, is extremely flexible and thus
inherently tough to map to a speech-only interface. "Flatter"
languages would seem better suited, but then they tend to be lower-
level, thus more verbose, thus what you gain in lack of ambiguity
might be lost in having to produce more code.
If it is to be Python after all, it seems the strategy you have in
mind is to make the typical patterns as easy as possible, and either
not allow for the more exotic ones or settle for making them much more
complicated to achieve. You also seem to have a pretty clear idea of
the behaviors you want already.
I think your best bet is to stick with Emacs. It's the only editor I
know of which is almost fully programmable without recompiling, and
it's available for Windows. (I am not clear on whether you already
use Emacs for Windows, or whether you remotely use Emacs on Linux,
from Windows.)
It does sound like you have to do a bit of Emacs Lisp programming to
get what you want, but I'd guess that's easier than modifying some
other editor to do what you want, or modifying the way you issue
instructions to fit a more visually oriented style.
John
drob...@gmail.com
"END_CLASS" to end the current class.
"END_DEF" to end the current function
"END_BLOCK" to end anything else.
This is possible with some emacs lisp but I don't see what this gains
you over
"BACK" "BACK" "BACK"
where "BACK" sends a backspace to emacs.
(Actually I'd define an "END" command which you could give at the
end of the last line of a block. That would relieve you of the need to
enter the newline and tab.)
Yes, it requires a few extra utterances on occasion, but you don't
have to worry about three new (multi-syllabic) verbs to recognize.
Am I understanding your requirement correctly?
Eric S. Johansson
> You see examples here from time to time that don't follow the rigid C+
> + formatting. Some examples:
>
> def classmaker( ):
> class X:
> something
> return X
>
> class X:
> class Y:
> something
>
> if something:
> class X:
> pass
> else:
> def X( ):
> pass
>
> Some of these are tricky not dirty; some are both, but you don't want
> to tie your hands prematurely, which is one of my favorite features of
> Python. Long story short, it can get hairy.
somebody should be called a sick bastard. :-)
I have never seen these forms and I can see how they are syntactically correct,
possibly useful, and mind bogglingly confusing. <gack>, having said that
though, my gut reaction would be to try to satisfy the usual case first and
suggest that these forms are a "sucks to be you moment, use your hands because
we saved them from damage elsewhere". case. Given enough time I think I could
come up with a fairly regular grammar to express both the ordinary and
exceptional cases. I'd probably use something somewhat more verbose for the
sick and twisted examples you've given me.
>
> Why aren't you favoring, 'dedent once/twice', 'dedent' repeated,
> 'close class, close function, close if, close for'? I don't imagine
> that saying 'close' three times in a row would be a strain.
>
> If the program is clever, it can learn that 'function' and 'method'
> are synonyms, and you can start to think in terms of both.
>
> You don't need to write 'start method, start class', except as a
> shortcut for spelling the statements out by hand; what type of block
> statement (suite) you are starting is determined by syntax.
I was hoping to avoid this but this is a brain dump on speech or the user
interfaces. It's evolved over some 15 years of living with speech recognition
and having to take time off because my voice hurts too much to speak in my hands
hurt too much to type.
Hands are robust. It takes decades of use to make them go bad. Vocal systems
are fragile. It takes only one bad day to make them break for weeks. Once
damaged, neither one fully recovers.
The major problem with using speech recognition with programming is that
keyboards are great at doing fine grained small detail work and lousy at doing
coarse-grained work. Speech recognition is lousy at doing fine grain detail
work and really good at doing coarse-grained work such as creating large blocks
of text. This difference in usability is only visible once you have lived in
both worlds.
rule number one: never try to speak the keyboard.
don't ever force a user to control capitalization, concatenation, spelling by
speaking one letter at a time. Even simple things like Alpha (cap alpha) can
get rather tiring if used a lot. One of the cruelest things from software
development is mixed case, fractured spelling words such as mixInCntr which I'm
not even going to try to pronounce or spell out.
a more positive way of expressing rule one is allow the user to get what they
want by speaking words in their native language.
Rule number two: never speak small stuff or why use two or more utterances
when a single one can do
one step up from speaking the keyboard is forcing the user to say the same
command multiple times to achieve a single effect. For example, if you want to
move to the beginning of the line for the end of the line, you can say "move
word left" as many times as it takes to get to where you want to be or you can
just say "move to start of line". In the context of the indent outdent control,
I don't really want moving to the right level of indentation for class, method,
function etc.. I want a component to put in the method "new class" which would
put a class definition at the right place with the right indentation in all the
right components so that I don't have to speak the object hierarchy or triple
quotes (in pairs). It's all done for me. But a macro like that won't work
right unless I can put the cursor at the right level of indentation.
another reason for this rule is that you want to really minimize load on the
voice. Remember, the voice is fragile. If I can say a small sentence and get a
big effect or something that saves me a lot of work, then that's a win.
Otherwise I might as well burn some hand time and hit the backspace key twice,
speak my macro to do whatever I want, and then clean up the macro from its wrong
indentation. Yes, it saves my throat and my hands but not as much for either as
a good speech macro would.
Rule number three: be careful with your grammar
Speech user interfaces are broad shallow hierarchies. GUI interfaces are narrow
and deep. Speech user interfaces do not readily lend themselves to discovery in
the same way that GUI interfaces do.
Be aware of grammar traps such as similar starting points and homonym arguments.
Usually it's not too bad but, some words just won't be recognized correctly so
there should be an alternative. For example, Lennox is how NaturallySpeaking
recognizes linux. I've been training it for months and it just won't get it right.
Rule number four: think about disambiguation
This is related to being careful with your grammar. Depending on your context,
disambiguation can be difficult or easy. If you're operating in a large
environment such as editing a file, disambiguation means having fairly wordy
commands. But if you can narrow the scope, disambiguation happens automatically
because you have reduced choice through reducing the amount of text you're
operating on. Frequently disambiguation through reducing scope also aids in
focus and cognitive load because you've eliminated distractions for the user.
> I retract my suggestion that the system prompt you for information.
> Academically speaking, context can partially eliminate redundancy.
> That is, 'close' can stand alone, regardless of what block you are
> closing. If you aren't maintaining a tyrant's grip on the tool, that
> is, allowing it to think for itself a little or anticipating, a
> miscommunication is inevitable, and it will need to corroborate the
> element of the context that has fallen out of sync. Some people
> bother to maintain a model of the speaker's knowledge state, and even
> maintain multiple (non-unique) branches between the time an ambiguity
> is recognized, and the time it's resolved.
good insight. We are using something like that in the voice coder project to
deal with symbol creation. I'm looking for something a little different. My
end goal is to have an editing environment that lets me navigate by and operate
on implicit and explicit features. I'm afraid I've gone on a bit long about
this but, maybe we can start up a separate thread about editors using features.
These 32nd description is a features any visible component of the language that
a user can specify by name. Predicates, array indices, arguments, last block,
next block, beginning block are all examples of implicit features. I should be
able to select any one of those and replace/edit etc. etc. This is where you
can use disambiguation through scope reduction to enhance the editing experience.
>
> Single-line blocks can follow their overture on the same line, such
> as:
>
> if x: x()
good example of where "edit block" followed by subsequent scope reduction to
just the block would be a powerful tool. Same thing is true of "edit predicate".
>
>> Think about being asked that question every time you close a block.
>
> Some people do it. 'What are you doing?', 'Where are you going?',
> 'Are you leaving?', 'Where were you?', 'I thought you left,' etc.
to which I would reply, "no need to be jealous. She wants to spend some private
time with you too." But that really has nothing to do with editing by voice. :-)
>
>> I can
>> almost guarantee it would drive you mad
>
> Perhaps it does. Honest curiosity and vicious curiosity are only
> distinguishable after time.
true. You know, if you live anywhere near Boston MA, I would like to spend a
few hours with you, have you train up a voice model and try editing by voice.
It would be interesting to watch you learn the environment. (If others are
interested in this offer, e-mail me privately)
---eric
Eric S. Johansson
> This is such a fascinating and compelling thread that it has pulled me
> out of lurker mode.
>
> Eric, I would like to say I also admire your initiative, but even more
> so your patience. You seem to handle comments of all types
> gracefully.
Should have seen me 20 years ago. lets just say there are few posts I deeply
regret.
> Perhaps it comes from working with speech recognition so much. I
> imagine that if you are using a speech-based programming environment
> and get frustrated with how stupid it is, and tell it off, you only
> manage to create more of a mess for yourself to clean up. I think
> most of us who rely on our vision and typing lose our cool more
> easily, partly because the penalty for us is not as great.
Well, if I lose my temper and yell, I lose the ability to work for a day or two.
Being self-employed, I can't afford that. This is not to say I don't get
extremely frustrated. I just rant off keyboard much to my wife's dismay.
Fortunately, my clients mostly see the calm, cool, only slightly rattled at
times consultant that I am.
> Anyway, sorry for being a bit off-topic. I'm afraid I don't have a
> lot to offer on the topic. My thoughts as I was reading the earlier
> comments is that Python, by its nature, is extremely flexible and thus
> inherently tough to map to a speech-only interface. "Flatter"
> languages would seem better suited, but then they tend to be lower-
> level, thus more verbose, thus what you gain in lack of ambiguity
> might be lost in having to produce more code.
You have hit one of the challenges directly square on the head. for Chile, one
of the benefits of an extremely flexible language like Python is you can use a
regimented form full of consistent idioms and get your job done. obviously
these idioms would be the result of whatever tools you use to create code.
>
> If it is to be Python after all, it seems the strategy you have in
> mind is to make the typical patterns as easy as possible, and either
> not allow for the more exotic ones or settle for making them much more
> complicated to achieve. You also seem to have a pretty clear idea of
> the behaviors you want already.
Yes. That was one of the rules I should've put into another post. Make the
common path simple let the unusual path be complex.
>
> I think your best bet is to stick with Emacs. It's the only editor I
> know of which is almost fully programmable without recompiling, and
> it's available for Windows. (I am not clear on whether you already
> use Emacs for Windows, or whether you remotely use Emacs on Linux,
> from Windows.)
>
> It does sound like you have to do a bit of Emacs Lisp programming to
> get what you want, but I'd guess that's easier than modifying some
> other editor to do what you want, or modifying the way you issue
> instructions to fit a more visually oriented style.
well, therein lies the rub. I don't know lisp, I don't know Emacs internals let
alone python mode. solving the user interface problem by itself is pretty
difficult. If the universe was granting the wishes, I would hope for a
development partner helping me build these interfaces and integrating them with
vr-mode (Emacs speech recognition mode that has some challenges)
Eric S. Johansson
> I still don't understand.
I elaborated on some of these points in a post to Aaron Brady. If you missed it
on the list, let me know and I will forward you a copy.
It seems that you want to be able to do:
> "END_CLASS" to end the current class.
>
> "END_DEF" to end the current function
>
> "END_BLOCK" to end anything else.
>
> This is possible with some emacs lisp but I don't see what this gains
> you over
> "BACK" "BACK" "BACK"
> where "BACK" sends a backspace to emacs.
> (Actually I'd define an "END" command which you could give at the
> end of the last line of a block. That would relieve you of the need to
> enter the newline and tab.)
> Yes, it requires a few extra utterances on occasion, but you don't
> have to worry about three new (multi-syllabic) verbs to recognize.
>
> Am I understanding your requirement correctly?
no but it's not your fault. I have a bad habit of asking for the component that
I need (i.e. gimme a six-inch 8-32 screw) without telling you what I need it for
because it is extremely clear in my mind what I need the screw for (i.e. barn
door mount for astrophotography).
All of this navigation stuff was driven by the need to embedded inside of a
larger command invoked through speech recognition. I have no conditionals
about the environment so I can't tell whether I need to indent once or twice or
three times to make it go to the right place. Remember, this is a component in
a blind macro (i.e. one that is not aware of its environment) and therefore must
operate correctly with no knowledge of its environment.
Many of the features speech recognition users need from editors are these smart
navigation commands so that one can perform more complex operations without
worrying about indentation or position or things of that nature.
my voice is wearing out. More later
---eric
Steve Holden
> Aaron Brady wrote:
[...]
> one step up from speaking the keyboard is forcing the user to say the same
> command multiple times to achieve a single effect. For example, if you want to
> move to the beginning of the line for the end of the line, you can say "move
> word left" as many times as it takes to get to where you want to be or you can
> just say "move to start of line". In the context of the indent outdent control,
> I don't really want moving to the right level of indentation for class, method,
> function etc.. I want a component to put in the method "new class" which would
> put a class definition at the right place with the right indentation in all the
> right components so that I don't have to speak the object hierarchy or triple
> quotes (in pairs). It's all done for me. But a macro like that won't work
> right unless I can put the cursor at the right level of indentation.
>
the majority cases: one day you will want to define a class inside the
method of some other class, so you'll need special-casing for that rare
occurrence in whihc going back to the outermost level is "wrong".
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Aahz
>class foo( object):
> def cat(self)
> self.x=1
> def dog
> self.x=2
>
>this is legal Python but it's not what you need 99% of the time. There is no
>cue to the editor to tell it to outdent to give me what I really want which is:
>
>class foo( object):
> def cat(self)
> self.x=1
> def dog
> self.x=2
>
>so there should be a mechanism for saying "indent the level of the previous
>definition".
The command word you want is "dedent".
signed, deaf person with cochlear implant
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan
John Yeung
> well, therein lies the rub. I don't know lisp,
> I don't know Emacs internals let alone python mode.
Unfortunately, neither do I. Actually, I haven't touched Emacs since
my college days, and barely remember any of it. I figured from your
preference for Emacs that you already did some customization for
yourself.
Is vr-mode a "major" mode? If so, I suppose it can't be active at the
same time as python-mode, which is also a major mode. I grabbed a
copy of the code for python-mode (revision 4.75) and while I frankly
don't understand it, it looks like it has provisions for things like
finding the beginning of a class or def, which might be usable in
building the types of commands you want.
Perhaps you should try asking for help from the Emacs community. To
someone versed in Emacs Lisp, what you want might be fairly easy.
Another possibility, that I mention mainly because I find it
interesting, and not so much because I expect it to be the best path
for you, is Pymacs. It purports to let you customize Emacs using
Python instead of Emacs Lisp.
Good luck! I'm sorry I can't be of more help.
John
Eric S. Johansson
> Eric, I don't have a good readily available solution to what you're
> trying to do, but it seems to me that it would be worth your time to get
> comfortable with elisp, and how it's used in emacs. The emacs
> documentation is pretty good, even if you don't know lisp, and I think
> it would be one of the easiest languages to integrate well with voice
> recognition. I don't think you would need to touch what is commonly
> referred to as emacs internals to do what you want. There's a good
> chance that you'd be able to greatly improve emacs voice-recognition
> support pretty easily in a month or twos time.
for reasons too long to go into, trying to modify Emacs extensively is not a
long-term win. My requests here were trying to make Emacs somewhat better as a
speech recognition driven editor to get to my final goal, namely building a
bridge between Windows and Linux for speech recognition. The time or take
modify Emacs to do what I want would be better spent burning my hands and going
directly for the end goal because I believe it would take me less time to get to
where I want. what I have to learn by myself is how to make a Windows edit
control work from Python, verify speech recognition works with that
configuration, then create a mirror window on linux so what ever is placed into
one window via speech recognition, cut and paste, or even typing shows up in the
other window. Then, I need to layer a grammar on top of that to enable the
linux side to do application specific cut and paste. this tool would allow us
to use anything for an editor and not just the one we have just tweaked.
simple heh. I may just be better off trying to make enough money so I can pay
somebody to do that.
As I was writing this, it just occurred to me one way to implement the
indentation control. it would be something like "moved to beginning of line,
leave mark, move to end of line, kill region, insert < action specific number of
spaces>.
I still think it would be a better solution to determine the indentation of the
previous item that should art hold the right indentation and reuse that amount
but, I will settle for with brute force, bloody ignorance
Yes, that probably will work
Eric S. Johansson
> On Nov 15, 8:50 pm, "Eric S. Johansson" <e...@harvee.org> wrote:
>> well, therein lies the rub. I don't know lisp,
>> I don't know Emacs internals let alone python mode.
>
> Unfortunately, neither do I. Actually, I haven't touched Emacs since
> my college days, and barely remember any of it. I figured from your
> preference for Emacs that you already did some customization for
> yourself.
Like the vast majority of Emacs users, I cut, paste, and swear.
>
> Is vr-mode a "major" mode? If so, I suppose it can't be active at the
> same time as python-mode, which is also a major mode. I grabbed a
> copy of the code for python-mode (revision 4.75) and while I frankly
> don't understand it, it looks like it has provisions for things like
> finding the beginning of a class or def, which might be usable in
> building the types of commands you want.
>
> Perhaps you should try asking for help from the Emacs community. To
> someone versed in Emacs Lisp, what you want might be fairly easy.
>
> Another possibility, that I mention mainly because I find it
> interesting, and not so much because I expect it to be the best path
> for you, is Pymacs. It purports to let you customize Emacs using
> Python instead of Emacs Lisp.
>
> Good luck! I'm sorry I can't be of more help.
no biggie. Maybe the real answer is changing the conversation to look for
editors that can run on Windows but edit remotely like emacs + tramp.
Anyway, here's the speech macros I've worked out so far.
# minimal python and commands
New class = '{ctrl+a}class
{ctrl+@}(object):{ctrl+j}{tab}"""{ctrl+j}{tab}"""{enter}{ctrl+x}{ctrl+x}';
new method = '{ctrl+a} def
{ctrl+@}(self):{ctrl+j}"""{ctrl+j}"""{ctrl+j}{ctrl+x}{ctrl+x}';
new constructor = '{ctrl+a} def __init__(self):{ctrl+j}"""{ctrl+j}"""{ctrl+j}';
end colon = '{ctrl+e}:';
between single quotes = "''"{ctrl+b};
between double quotes = '""'{ctrl+b};
between triple quotes = "''''''"{ctrl+b}{ctrl+b}{ctrl+b};
between hex quotes = '""""""'{ctrl+b}{ctrl+b}{ctrl+b};
(ad|add) index = '[]{ctrl+b}';
next index = '{ctrl+s}[{ctrl+f}';
last index = '{ctrl+r}]{ctrl+b}{ctrl+r}[{ctrl+f}';
delete index = '{ctrl+r}[{ctrl+f}{ctrl+s}]{ctrl+b}{ctrl+w}';
go to Line [Number] <digit> = {esc}xgoto-line{enter}$1{Enter};
go to Line [Number] <digit> <digit> = {esc}xgoto-line{enter}$1$2{Enter};
go to Line [Number] <digit> <digit> <digit> = {esc}xgoto-line{enter}$1$2$3{Enter};
go to Line [Number] <digit> <digit> <digit> <digit> =
{esc}xgoto-line{enter}$1$2$3$4{Enter};
go to (end={ctrl+e} | beginning={ctrl+a} | start={esc}m) of line = $1;
Andreas Roehler
> Jeremiah Dodds wrote:
>
>> Eric, I don't have a good readily available solution to what you're
>> trying to do, but it seems to me that it would be worth your time to get
>> comfortable with elisp, and how it's used in emacs. The emacs
>> documentation is pretty good, even if you don't know lisp, and I think
>> it would be one of the easiest languages to integrate well with voice
>> recognition. I don't think you would need to touch what is commonly
>> referred to as emacs internals to do what you want. There's a good
>> chance that you'd be able to greatly improve emacs voice-recognition
>> support pretty easily in a month or twos time.
>
> for reasons too long to go into, trying to modify Emacs extensively is not a
> long-term win.
IMO Jeremiah Dodds is right. With all the time spent on this discussion, you could write the
needed function in elisp probably. BTW your request seems reasonable. Other python programmers may use it too.
Whats Emacs? To an important extent, it's that, you want it to be.
So if you have your code, your functions, why it shouldn't it be a long term win?
Anyway you should tell, which python-mode and which Emacs you use if any.
Andreas Röhler
Eric S. Johansson
> IMO Jeremiah Dodds is right. With all the time spent on this discussion, you
> could write the needed function in elisp probably. BTW your request seems
> reasonable. Other python programmers may use it too.
I tried learning lisp about 15 years ago. even bought a copy of the little
lisper. after a few days, I gave up because there was just too much learning
curve for the reward. I know that sounds a touch arrogant but in truth, I'd
prefer to put my energy into building a better bridge between NaturallySpeaking
and linux apps. bigger pay off helping more people. with reguard to emacs
changes I hope for and would appreciate it if someone would partner up with me
and help build these (and other) changes into python mode. I will also point
out that if another IDE is better suited, I'm open to that too.
> Anyway you should tell, which python-mode and which Emacs you use if any.
This is GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
of 2008-09-08 on LENNART-69DE564 (patched)
and I'm using the python mode that came with emacs. no version number but...
;;; python.el --- silly walks for Python -*- coding: iso-8859-1 -*-
;; Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
;; Author: Dave Love <f...@gnu.org>
;; Maintainer: FSF
;; Created: Nov 2003
;; Keywords: languages
>
> Andreas Röhler
Andreas Roehler
> Andreas Roehler wrote:
>
>> IMO Jeremiah Dodds is right. With all the time spent on this discussion, you
>> could write the needed function in elisp probably. BTW your request seems
>> reasonable. Other python programmers may use it too.
>
> I tried learning lisp about 15 years ago. even bought a copy of the little
> lisper. after a few days, I gave up because there was just too much learning
> curve for the reward. I know that sounds a touch arrogant but in truth, I'd
> prefer to put my energy into building a better bridge between NaturallySpeaking
> and linux apps. bigger pay off helping more people. with reguard to emacs
> changes I hope for and would appreciate it if someone would partner up with me
> and help build these (and other) changes into python mode. I will also point
> out that if another IDE is better suited, I'm open to that too.
I like Emacs, that's true. However I'm not married with.
If a better tools exists for my purposes, I'll use it.
Until than lets write the code you need in Emacs Lisp, which should not be that difficult.
I use
GNU Emacs 22.1.1 (i586-suse-linux-gnu, GTK+ Version 2.12.0) of 2007-11-24 on dede
with python-mode.el from
http://sourceforge.net/projects/python-mode/
AFAIK its the most advanced mode for all Emacsen.
You could give it a try.
Meanwhile I'll reflect a draft addressing your needs.
BTW, what about this stuff?:
http://www.cb1.com/~john/computing/emacs/handsfree/index.html
Eric S. Johansson
I think there's something wrong with the site because it tells me it's version
1.0 from year 2005.
> Meanwhile I'll reflect a draft addressing your needs.
there is a rather sizable set of things that could be added to assist speech
during programming. I'm mostly concerned about the editing aspect of speech
driven programming.
>
> BTW, what about this stuff?:
>
> http://www.cb1.com/~john/computing/emacs/handsfree/index.html
it's interesting but most of it is very low level user interface orientation.
Lo level stuff is relatively easy to implement. High-level stuff is much more
difficult than the equivalent GUI abstraction.
a narrow channel interface stuff is very interesting especially if you take
full advantage of the concept. With regards to programming, a narrow channel
interface would let you choose a relatively low number of "big" items in the
field of vision and then let you continue to narrow until you can easily operate
on the item of interest.
Andreas Roehler
> Andreas Roehler wrote:
>> with python-mode.el from
>>
>> http://sourceforge.net/projects/python-mode/
>
> I think there's something wrong with the site because it tells me it's version
> 1.0 from year 2005.
You are right, sorry. I should tell you the present place.
Barry Warsaw, the maintainer, took it to
https://launchpad.net/python-mode
Please look there for last version.
Maybe subscribe the mailing list at
pytho...@python.org
I suggest to continue there with all questions
concerning your needs and python-mode with Emacs.
So lets dig through python-mode.el first, if it
contains already some code suitable for you.
>
>> Meanwhile I'll reflect a draft addressing your needs.
>
> there is a rather sizable set of things that could be added to assist speech
> during programming. I'm mostly concerned about the editing aspect of speech
> driven programming.
>
Seems interesting in many respects.
MRAB
> Andreas Roehler wrote:
>> with python-mode.el from
>>
>> http://sourceforge.net/projects/python-mode/
>
> I think there's something wrong with the site because it tells me it's version
> 1.0 from year 2005.
>
>
> there is a rather sizable set of things that could be added to assist speech
> during programming. I'm mostly concerned about the editing aspect of speech
> driven programming.
>
>>
>> http://www.cb1.com/~john/computing/emacs/handsfree/index.html
>
> it's interesting but most of it is very low level user interface orientation.
> Lo level stuff is relatively easy to implement. High-level stuff is much more
> difficult than the equivalent GUI abstraction.
>
> a narrow channel interface stuff is very interesting especially if you take
> full advantage of the concept. With regards to programming, a narrow channel
> interface would let you choose a relatively low number of "big" items in the
> field of vision and then let you continue to narrow until you can easily operate
> on the item of interest.
>
http://doc.cat-v.org/plan_9/4th_edition/papers/sam/
Worth a read.
Barry Warsaw
Hash: SHA1
On Nov 27, 2008, at 3:13 AM, Andreas Roehler wrote:
> Eric S. Johansson wrote:
>> Andreas Roehler wrote:
>>> with python-mode.el from
>>>
>>> http://sourceforge.net/projects/python-mode/
>>
>> I think there's something wrong with the site because it tells me
>> it's version
>> 1.0 from year 2005.
>
> You are right, sorry. I should tell you the present place.
>
> Barry Warsaw, the maintainer, took it to
>
> https://launchpad.net/python-mode
>
> Please look there for last version.
>
> Maybe subscribe the mailing list at
> pytho...@python.org
I've tried as best I could to make it clear on the SF site that we've
moved development to Launchpad. SF doesn't make it easy though.
Unfortunately, we still haven't been able to import all the tracker
issues from SF to LP, though a request is still open on that. For
now, all new issues on python-mode.el should be opened here:
https://bugs.launchpad.net/python-mode
I'm going to try to do a new release of python-mode.el, maybe this
weekend, but it won't have much more than what's in the bzr repository
right now.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSS6y9nEjvBPtnXfVAQIHkQQApjxeqbv9cfDVKB3b0Pvy3seryYi7++8S
J1LXnwUUgq7xUtf72i5tyJrdUPQRl6cQXxMaLczzm+HE0ULdB7mRiYOYpA+eZS/J
man5kPe89KbyI6Jvd0NqXe+YJ2ud6XLVQQ37l8Is9vwBgrPFtgmHuxEkz0Ya8iS/
pV/QrTpd6ow=
=WuiR
-----END PGP SIGNATURE-----