special editor support for indentation needed.

[Eric S. Johansson]

Aaron Brady wrote:
> On Nov 14, 8:01 pm, "Eric S. Johansson" <e... at harvee.org> wrote:
>> drobi... at 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.  :-)
>>
>> 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?
> 
> 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?