[PYTHONMAC-SIG] Future stuff for the Alpha python mode

[Tom Fetherston]

>>My main gripe is that I don't see an obvious way to change the default
>indentation the way I want to.  I'm not very experienced in using
>Alpha, so maybe it's there somewhere, but I didn't find anything
>obvious.  I want a feature that Emacs mode has, and which is necessary
>for compatibility with files originating on Unix: while a tab
>character is worth 8 spaces, the block indentation is worth 4 spaces.

block indentation, does this have its own keybing?  If so do you use it to
put in the four spaces in a single line, or does it do what it sounds like,
ident a (selected?) block?

>So you will find that the first level is indented with 4 spaces, the
>2nd level is indented with a single tab, the 3rd level is indented
>with a tab plus 4 spaces, the 4th level with 2 tabs, and so on.  This
>style is used extensively by many standard library modules -- in fact
>it is the default style for Emacs nowadays.  Notice that setting the
>*tab stop* to 4 spaces is the wrong thing to do here: it would make
>the 1st and 2nd level indistinguishable.  Please don't tell me that I
>have to convert all tabs to spaces.
>
No, I'll just have to change some of the key invoked procedures, (the ones
for return and tab), and get python mode to change the tab lenght to 8
instead of the default of four while in the python mode.
>My other gripe is that the coloring is a bit too colorful to my taste.
>For instance, it colors parentheses -- well, this is okay, I suppose
>-- but it also colors various plain identifiers in ways that are more
>confusing than useful.  In particular, it seems to know most (but not
>all!) standard methods and built-in function names, and will color
>these names even where they occur as local variables or methods of
>unrelated objects.  I'd rather not see identifiers colored at all,
>except in clearly recognizable syntactical positions (e.g. Emacs
>colors the name of a function or class definition different).

 I've
>also noticed that the coloring is very sensitive to backspacing --
>oftentimes, when colors look really weird, typing Control-L will fix
>them.
>
Yes, the colorizing routines in alpha only go back a few versions, it seems
to be implemented by embeding unprintable "color escapes" in the text.  In
a mode, the colorXon/colorXoff pairs are done dynamically, i.e. only added
to the text buffer.  These are added when, a) the text is read into the
buffer, and b0 as you are typing.  The colorizing follows regular
expression pattern matching, no actual parsing of the code is done, (Lisp
is better at inteligent parsing than Tcl).  The combination of
inserting/deleting the escapes and then invoking a redraw seems to miss
sometimes, usually the colorizing-redraw gets left out, the control-L you
mention seems to invoke such a redrw manually.

>> What has eaten up the most time is overhualing the template insertion
>> facilities that are avaliable in Alpha.  Included in the alpha distribution
>> is a set of files that support a template facility known as ElectricAlias.
>
>I've seen this in the HTML mode, and personally, don't care for them.
>I'm so used to typing the full syntax that remembering the key
>sequences for the templates rarely saves me any time.
>
To tell the truth, this won't be as useful in python as it is in other
modes, languages with begin/end --block type snytax benefit the most from
this.  There are a lot of useful feature in this (most trying to assist
entry without getting you to memorize weird abbreviations), and, I'm
planning to write an app that lets you rough out the logic of an algorithm
visually, drag it into alpha and get a "fill-in the blanks" type template
of the whole thing.

>> A number of people found the colorizing excessive and/or garrish in the
>> choice of colors.  If you have come up with your own set of colors that you
>> like, and/or you have turned off colorizing of certain groups of words,
>> please pass this back to me.  I'm working on making this more sanely
>> customizable.
>
>Ah thanks.  Disabling coloring for the "known functions and methods"
>by default would go a long way for me...
>
>> I've written routines that parse the include and from...includ...
>> statements in such a way that option-clicking on the titlebar will produce
>> a pop-up of the module names.  Selecting one of these will open the
>> associated file.  You can also cmd-double click a module name and open its
>> file. (note: Alpha 6.5 has a bug in its pop-up routine, you might have to
>> uses a later beta version --usally pretty stable)
>
>Ah this is cool (except for the Alpha beta).
double-clicking on a module name will work in the current release, the
option click method runs into what looks likke an "off by one" type error,
the first module name get's dropped from the list of modules and the last
name is just random garbage.

>Seems fine for me.  Are you serious that Alpha can't hilite
>single-quote delimited strings?
>
Haven't found ay way to do it yet, since Alpha only uses pattern matching
to do its colorizing, and not the parsing that lisp allows, it is pretty
easy for you to write legal combinations that exceed strict pattern
matching.
>> To support the commenting of programs, (creating and maintaing), I'am
>> considering the following sheme;
>>
>> A module would be parsed for definitions and any existing comments.  A file
>> would be created with only these parts (i.e. definiton heads and existing
>> comments--no bodies).  These files would be given the module name and a new
>> extension (say .pyd), perhaps they would all end up in a "Doc" subfolder of
>> the parent module's folder.  This new file would be easy to naviagate and
>> add comments to.  Things like instant templates for presenting a table of
>> the arguments and explantion would be provided.
>
>Except that .pyd is a bad choice because it means "PYTHON DLL" on
>Windows platforms.  Sooner or later someone cross mounting file
>systems would be confused.  Maybe use .pyi for Python interface, or
>.py-doc.
>
>Not sure how this feature would be used, personally -- I'd rather keep
>all my meta info in comments and doc strings in the source file rather
>than in a separate file.  It also sounds like a scheme that would be
>cumbersome when you're *not* using Alpha...

Actaully , the idea is mostly to be an aid to documentating code,  (Let's
face it, it --does-- tends to be written last).  You can quickly write the
documentation in this file, merge it into the source, and still have the
.pyi file to turn into html and/or hard copy for reference.
>
Tom Fetherston
Pittsburgh, PA USA



=================
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
=================