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

[Robin Friedrich]

|>Tom writes:
|> >Guido writes:
|> >>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?
No it just figures the minimal combination of (8space)tabs and 4 space segments
needed when you need the next deeper indent (after a :<return>). Personally
I don't like this scheme and turn it to just straight spaces in emacs with
(setq-default indent-tabs-mode nil). The tabs thing just complicates matters
and having a feature in Alpha to always expand tabs to spaces would be fine
with me.
|> 
|> >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 agree with Guido. I prefer just hiliting language keywords and strings.
Hopefully the doc string problem can be fixed.
[snip - color delimiter discussion]
|> 
|> >> 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.

Although the fill-in-the-blanks idea may be useful, I probably wouldn't find
myself using templates in Alpha. Python's just too easy.;-)
[snip - snip]

|> >> 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.

I would stay away from separate files. You might check out gendoc on the 
www.python.org site. It can generate documentation from the doc strings
and program structure automatically. [http://www.python.org/sigs/doc-sig]

-Robin Friedrich

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

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