Re: special editor support for indentation needed.

[Eric S. Johansson]

Almar Klein wrote:

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 NaturallySpeaki ng.

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}"""{e nter}<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. :-)

[drobinow@gmail.com]

Re: special editor support for indentation needed.

On Nov 14, 4:08 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

Almar Klein wrote:

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 anniversaryof being
injured next year....
>
another initiative is exporting the speech recognition environment to theLinux
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  NaturallySpeaki ng.
>

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.  Thereis 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}"""{e nter}<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.  :-)

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]

Re: special editor support for indentation needed.

drobinow@gmail. com wrote:

On Nov 14, 4:08 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

>Almar Klein wrote:

>>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 NaturallySpeaki ng.
>>

>>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}"""{e nter}<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. :-)

>
The backspace key in emacs does exactly what you want. Have you tried
it?

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_nonst op()

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

[drobinow@gmail.com]

Re: special editor support for indentation needed.

On Nov 14, 5:27 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

drobi...@gmail. com wrote:

On Nov 14, 4:08 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

Almar Klein wrote:
>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 toand 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  NaturallySpeaki ng.

>

>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}"""{e nter}<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.  :-)

>

The backspace key in emacs does exactly what you want. Have you tried
it?

>
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_nonst op()
>
 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'svocal
cords and, a text-to-speech output doesn't let you know what lines up with what.

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?

[Eric S. Johansson]

Re: special editor support for indentation needed.

drobinow@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|thr ice)). 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 counterproducti ve at best and physically
damaging at worst for a disabled user.


any clearer?

[Aaron Brady]

Re: special editor support for indentation needed.

On Nov 14, 8:01 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

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|thr ice)).  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 parenself
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 interventionto tell
you how may times to outdent and that's counterproducti ve at best and physically
damaging at worst for a disabled user.
>
any clearer?

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]

Re: special editor support for indentation needed.

Aaron Brady wrote:

On Nov 14, 8:01 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

>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|th rice)). 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 counterproducti ve at best and physically
>damaging at worst for a disabled user.
>>
>any clearer?

>
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.

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]

Re: special editor support for indentation needed.

On Nov 14, 11:28 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

Aaron Brady wrote:

On Nov 14, 8:01 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

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|thr ice)).  This is probably best shown by example although, I'm not
guaranteeing my example will make it any clearer.  :-)

>

snip

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.

>
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 youcan'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?

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_comman d', 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
miscommunicatio n 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]

Re: special editor support for indentation needed.

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.

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

[drobinow@gmail.com]

Re: special editor support for indentation needed.

On Nov 14, 9:01 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

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|thr ice)).  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 parenself
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 interventionto tell
you how may times to outdent and that's counterproducti ve at best and physically
damaging at worst for a disabled user.
>
any clearer?

I still don't understand. 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?

[Eric S. Johansson]

Re: special editor support for indentation needed.

John Yeung wrote:

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]

Re: special editor support for indentation needed.

drobinow@gmail. com wrote:

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 astrophotograph y).

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]

Re: special editor support for indentation needed.

Eric S. Johansson wrote:

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.
>

You seem to be smart enough to realise that this can only take care of
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]

Re: special editor support for indentation needed.

In article <mailman.4013.1 226696904.3487. python-list@python.org >,
Eric S. Johansson <esj@harvee.org wrote:

>
>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".

The command word you want is "dedent".

signed, deaf person with cochlear implant
--
Aahz (aahz@pythoncra ft.com) <* http://www.pythoncraft.com/

"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan

[John Yeung]

Re: special editor support for indentation needed.

On Nov 15, 8:50 pm, "Eric S. Johansson" <e...@harvee.or gwrote:

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