Re: special editor support for indentation needed.
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 [EMAIL PROTECTED] 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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. 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. That reminds me of the text editor sam: http://doc.cat-v.org/plan_9/4th_edition/papers/sam/ Worth a read. -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
Eric S. Johansson wrote: 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 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 [EMAIL PROTECTED] ;; Maintainer: FSF ;; Created: Nov 2003 ;; Keywords: languages Andreas Röhler -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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. 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 [EMAIL PROTECTED] ;; Maintainer: FSF ;; Created: Nov 2003 ;; Keywords: languages Andreas Röhler -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
John Yeung wrote:
On Nov 15, 8:50 pm, Eric S. Johansson [EMAIL PROTECTED] 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
[EMAIL
PROTECTED](object):{ctrl+j}{tab}{ctrl+j}{tab}{enter}{ctrl+x}{ctrl+x}';
new method = '{ctrl+a}def
[EMAIL PROTECTED](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;
--
http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
Eric S. Johansson wrote: 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 -- http://mail.python.org/mailman/listinfo/python-list
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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
In article [EMAIL PROTECTED], Eric S. Johansson [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ It is easier to optimize correct code than to correct optimized code. --Bill Harlan -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Nov 15, 8:50 pm, Eric S. Johansson [EMAIL PROTECTED] 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. 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Mon, Nov 17, 2008 at 1:36 AM, John Yeung [EMAIL PROTECTED]wrote: On Nov 15, 8:50 pm, Eric S. Johansson [EMAIL PROTECTED] wrote: well, therein lies the rub. I don't know lisp, I don't know Emacs internals let alone python mode. 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'm not familiar with vr-mode, but a quick glance at at vr.el on sourceforge shows it to be a minor mode. There are a few ways of combining major modes as well (two-mode-mode, mmm-mode, mumamo). 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. -- http://mail.python.org/mailman/listinfo/python-list
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Nov 14, 9: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? 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? -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
Aaron Brady wrote: 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
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) -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
[EMAIL PROTECTED] 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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
Hi Eric, 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 [EMAIL PROTECTED]: in trying to make programming in Python more accessible to disabled programmers (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? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Nov 14, 11:41 am, Eric S. Johansson [EMAIL PROTECTED] wrote: in trying to make programming in Python more accessible to disabled programmers (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? 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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 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 indentdef ^(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. :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Nov 14, 4:08 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
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 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 indentdef ^(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. :-)
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'.
--
http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
[EMAIL PROTECTED] wrote:
On Nov 14, 4:08 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
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 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 indentdef ^(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. :-)
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_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
--
http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
On Nov 14, 5:27 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On Nov 14, 4:08 pm, Eric S. Johansson [EMAIL PROTECTED] wrote:
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 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 indentdef ^(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. :-)
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_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.
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?
--
http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
[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? -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: special editor support for indentation needed.
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
Re: special editor support for indentation needed.
On Nov 14, 11:28 pm, Eric S. Johansson [EMAIL PROTECTED] wrote: 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. :-) 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?
