special editor support for indentation needed.

[Aaron Brady]

On Nov 14, 11:28 pm, "Eric S. Johansson" <e... at harvee.org> wrote:
> 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.  :-)
>
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 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?

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.