Aaron Brady wrote: > On Nov 14, 8:01 pm, "Eric S. Johansson" <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] 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? -- http://mail.python.org/mailman/listinfo/python-list
