pep 8 constants

[Eric S. Johansson]

Tim Chase wrote:
>> I've tried it least two dozen editors and they all fail miserably
>> because they're focused on keyboard use (but understandable)
> [...snip...]
>> I've tried a whole bunch, like I said at least a dozen. They
>> all fail for first reasons such as inability to access all
>> functionality through keystrokes (easiest interface method
>> from speech recognition)
> 
> I'm not sure I follow which you want...you kvetch that
> they're too focused on keyboard use, but then that you can't
> access all functionality through the keyboard.

sorry. I've been living in this world for so long that I sometimes forget to
explain what's obvious inside my head. I apologize for the confusion.

The apparent conflict arises because the same term (keyboard access) is used to
describe two different problems. In the first case, the user interface model
(how you access taxes, manipulate light which (language) constructs are designed
to be efficient for your hands.  speech recognition users need an editor that
supports constructs that are efficient for the voice. One such construct is the
ability to navigate or operate on language elements by name. I've used some of
them before such as predicate, index, first method etc.

The second problem is that editors are designed to be driven by keystroke. If I
had a cross  process boundary APIPaula I can simply call the editor function to
perform to give operation. Unfortunately, today my speech recognition
environment needs to generate keystrokes to access functionality. for example,
in Emacs, when I say "delete word", the macro and marmot emits M-d

> 
> [warning, blatant vim fanaticism follows]
> 
> I use vim and can't remember the last time I used the mouse
> with it (save for occasionally lazily scrolling with the
> mouse-wheel, but you can scroll with the keyboard too), so
> it meets your "must be fully accessible through the
> keyboard" constraint.  It also has single keystroke commands
> for indenting/exdenting the current line as you mention:

you are forgiven. :-) try this experiment. Bring up the buffer full Python code
code you value them, starting in command mode, close your eyes and type a random
word. While your eyes are closed, undo that word. Every time I've tried it the
results have been mildly disastrous. If you been paying attention, I've tried to
leave speech recognition errors in place whatever didn't impede understanding
(too much) but, remember I'm getting one error in 20 errors is on average. That
means, I'll be correcting the IE errors, potentially much more dangerous errors
are regular basis. Any energy use by speech recognition must be able to cope
with a random dictation errors and let the user recover gracefully. Again, until
I started using speech recognition, I would never would've thought of this as a
failure case.

> 
>   > I know this is also counter to the Python way but having
>   > something marking and outdent would be really useful so
>   > that a vocal driven command to indent or outdent a block
>   > would be practical.
> 
> which can be done in insert-mode with control+D, control+T,
> and if you want to clear all indentation (all the way back
> to the first column), you can use "0" followed by control+D.
> Vim also allows for fairly detailed control over
> auto-indentation settings so you can match them to your
> preferences.  I suspect Emacs may be configurable to offer
> similar functionality but I'd have to defer to the emacsen
> on the list.

Yes, Emacs will, a single tab key, tab view to the indentation level specified
by the previous line unless it's already there and then it will start inventing
further. This really sucks. Sometimes, you just weary and then to  (you just
want to) go to the right place and stay there
> 
> That said, I'll be the first to admit that the vi/vim
> learning curve is more like a brick wall than a curve.
> However, I find the efficiency gains abundantly than repaid
> the time I invested to learn it well.

Yeah, I first encountered the eye in 1985. Or maybe I should say VI (Roman
numeral six).
> 
>>> Dasher[1]
>>
>> I've tried it, it's quite promising but my hands term are sufficiently
>> that I can't target accurately.
> 
> Last I tried it, it scaled the target sizes based on
> probability.  You might also try unconventional pointing
> devices for better precision.  I've seen web-cam
> eye-tracking tools which might make it a bit easier.  Or try
> a tablet input (where the motion corresponds linearly, as
> opposed to accelerated mouse motion).  Such input options
> are listed on the Dasher website, at least for those they
> tested.
> 

I like tablets. I need to buy a new one. We only problem is that most pens for
tablets are a little bit too small and hard for my hands (although they are much
better than mice). The major downfall is the buttons on the pen shaft. Damn
that's awkward to reach. I think it would need a separate tab of three buttons
that I can click and double-click independent of the pen controls.

>> Oh, another failure point. Have you ever tried to selected beach and
>> by voice. I mean I should say have you ever tried to
>> select a region by voice.
> 
> yes, not a pleasant experience.  Again, vim's modal
> interface allows for using text-objects so you can issue
> short-hand commands like
> 
>   ci"
> 
> to "[c]hange the contents [i]nside the double-quotes I'm
> currently on/withing".  The operator+motion and
> operator+textobject command syntax obviates a lot selection.
> While vim does offer a "visual" mode (akin to selection in
> other editors), I use it much less because of the power
> provided by the operator+[motion/textobject].

that's getting close to what I want to do with voice command except instead of
cryptic sequence of characters, I would say something like

string_edit = edit [<which>] string
which = first | second | third | fourth | fifth | sixth


> as you're an emacs user, my vim suggestions may sound like
> heresy. ;-)  But I suspect a skilled emacs user (or perhaps
> asking on an emacs-users list) could mimic much of the vim
> functionality.  I just can't be of much assistance there.

I really don't care what editor I use as long as it gets the job done. I have
strong preferences for always insert mode but, if I had an editor I had no
keystroke commands and everything I type went into the buffer but I committed a
complete of my speech, that would be kind of cool.
> 
> You're welcome to move it off-list...it's kinda drifted from python to
> general accessibility issues.  CC'ing c.p.l for this one in case any
> emacsen care to chime in on their suggested tweaks.

well, that you are really joined. For example, if we look at the string edit
command above, that implies he had or has the ability to properly distinguish a
string in a line of code. Think of how many ways you can express a string
triple or single quotes into different forms sometimes with  quotes nested
inside.  then take the whole object instance and know method is possible with
its type signature. This is editor work.