Browsers, source editors, etc.
David Ascher
programmers everywhere would be a full-featured platform-independent
development environment. I'm personally thinking of something like SNiFF+,
which combines source editing, project management, debugging, etc. Python
would make some things less important (makefile support, etc.) and some others
more important (intelligent interpreter support, etc.).
As Mark Hammond said in email: ``I would be happy to lend/change my code, but I
am not sure we know what the best approach is. Maybe we should take this back
to the list?''
Here are some general thoughts on the topic. This is just meant to start the
ball rolling.
Feature Set: [this is what I'd want as a minimum]
-- python-aware editor, with indentation, tagged text,
documentation/version control support, syntax checking, etc.
-- a class hierarchy browser
-- a module browser to study existing modules (built-in and
otherwise)
-- a built-in debugger
Several of the above features seem to require a fairly sophisticated parser
(maybe Fred's? I don't know enough on the topic).
Whatever the specific architecture used, some problems come up quickly:
* GUI: There is currently no truly cross-platform GUI toolkit.
While waiting for the sig-gui to deliver, it strikes me that it
should be relatively easy to determine the interfaces between the
editor & parser, the hierarchy browser & parser, etc., so that in
a first pass platform-dependent frontends could be built, to be
replaced later by something else.
* Is it feasible to reparse a module everytime the file is changed?
Are there better ways to keep track of the changes to a module?
I'm sure there are countless others. What are people's reactions?
--da
Fred L. Drake Jr.
In article <3s9ob8$d...@cocoa.brown.edu>,
David Ascher <d...@maigret.cog.brown.edu> wrote:
>would make some things less important (makefile support, etc.) and some others
>more important (intelligent interpreter support, etc.).
David,
While there won't be a need for the Makefile support per se, there
is a need to track dependency information. While the dependencies
within a 'live' program maybe difficult or impossible to track
meaningfully, a good environment should be able to handle at least
import/export dependencies outside of "exec 'import '+..."-type
statements. (Yes, I think there should be an 'export' as well.)
>Feature Set: [this is what I'd want as a minimum]
>
> -- python-aware editor, with indentation, tagged text,
> documentation/version control support, syntax checking, etc.
> -- a class hierarchy browser
> -- a module browser to study existing modules (built-in and
> otherwise)
I'm not sure how to handle editing. I like the idea of an editor in
the environment, but I'm an emacs user. Perhaps we have an integrated
editor *and* an emacs interface? ;-) (I don't guess anyone has done
anything like that outside of the standard python-mode interpreter
window, since I've received no response to my query last week.)
I've been learning to use MS VC++ recently at work. Whatever we do,
we should avoid a "browser" that simply displays source code and calls
it structure. The source should be available, but a better display
should be the normal or default operating mode.
>Several of the above features seem to require a fairly sophisticated parser
>(maybe Fred's? I don't know enough on the topic).
All I wrote was an *interface*, not the parser! Thank Guido for
that.
> * Is it feasible to reparse a module everytime the file is changed?
> Are there better ways to keep track of the changes to a module?
Maybe if they're small modules. If there's going to be a built in
editor, perhaps incremental parsing isn't such a difficult thing. The
basic parser should be quite useful in this context if we know what
the limits of the parse should be. On the other hand, a parser tuned
for incremental parsing should be quite effective in such an
environment. The question becomes: who knows enough about incremental
parsing? I think it would be fun to tackle, but it might be a few
years before I can have anything worth looking at.
There are definately a lot of good ideas. What is needed is a
requirements document that can be used, and some high-level design.
People can try their hands at aspects that interest them, and as
pieces are built, others can evaluate the pieces and see what needs to
be adjusted in the design, so things can work together smoothly.
-Fred
Ken Manheimer
> One project which I believe would be a great plus for Python and Python
> programmers everywhere would be a full-featured platform-independent
> development environment. I'm personally thinking of something like SNiFF+,
I agree (though i've never hear of SNiFF+ - odd name, that). There's an
idea that i presented at my "python programming environment" session at
the recent workshop, which i want to mention.
> Feature Set: [this is what I'd want as a minimum]
>
> -- python-aware editor, with indentation, tagged text,
> documentation/version control support, syntax checking, etc.
> -- a class hierarchy browser
> -- a module browser to study existing modules (built-in and
> otherwise)
> -- a built-in debugger
> [...]
> * GUI: There is currently no truly cross-platform GUI toolkit.
As i mentioned at the workshop, there *is* a "toolkit" that actually has
all these features available, though some aspects are currently less
developed than others. I'm talking about emacs (gasp). Here's a cute
little features compendium i had put together:
A lot of the tools i would like could be implemented in Emacs 19, and get
us a substantial, highly integrated programming environment:
- Already here, and ported to many platforms. (I figure it will
"soon" be more available on the Mac, now that the FSF's boycott
against Apple has been dropped.)
- Provides X Windows, DOS/Windows, and character-cell display.
(Character-cell, ie non-window-sys, is as important to me as any
of the other possibilities!)
- Freely available
- Exquisitely integrated environment
- "Comes with" the requisite emacs-like text edit widget:-)
:( It's also very complicated. (Not a feature!)
:( The quality of the various packages varies, but
- we have a lot of say and opportunity to improve deficiencies
Some capabilities that are ready *now*, or are currently maturing:
- Code editing - existing, wild and wonderful python-mode (thanks Tim
Peters, wherever you are, and Barry Warsaw for current development).
Includes language-specific formatting, highlighting, etc, interface
with python subprocess. (And i have a selective-display mechanism,
based on allout outline mode which is part of emacs 19, but i've
not quite packaged it for release, yet.)
- Code and document tracking:
- TAGS
- Info
- Surprisingly nice html browser, in emerging emacs 'w3' mode -
amazing, only lacks inline graphics in GNU's version of emacs 19
- the xemacs version has inlined graphics, though, and GNU emacs will
in not too long.
- GUD Debugger (Grand Unified Debugger) - truly comprehensive,
screen-oriented debugging interface, would not be hard to produce
the python interface - i actually looked it over last night, just
don't have the time to tackle it right now! Somebody, please!
- Environment Browser - check out the deveoping Object Oriented
Browser, emerging as part of the infodock project from the people
at U of Illinois:
<ftp://www.cs.uiuc.edu/pub/Dept_Of_Computer_Science/
Locally_Developed_Software/ACSL/xemacs/infodock/BR-FEATURES>
"The OO-Browser is a multi-windowed, interactive object-oriented class
browser similar in use to the well-known Smalltalk browsers. It is
unique in a number of respects foremost of which is that it works well
with a multiplicity of object-oriented languages. It provides both
textual views within an editor and graphical views under the X window
system."
I think that, altogether, this constitutes an outstanding potential. I
know it's not built on top of python, but much of it is *here now*, and
that represents a lot of work and a lot of integration that would take a
*long time* to replicate.
Fredrik Lundh
Just a little footnote...
> I agree (though i've never hear of SNiFF+ - odd name, that).
> There's an idea that i presented at my "python programming
> environment" session at the recent workshop, which i want to
> mention.
SNiFF+ is a really good development environment targeted for C++,
developed by TakeFive Software in Austria. It integrates editing,
documentation, structure browsing etc, and allows you to use your
favorite tools (such as emacs, gcc) fully integrated into the
environment. It also seems to work fine for HUGE projects. And of
course, SNiFF+ is quite expensive.
But now for the really amusing stuff:
$ cd sniff2
$ ls sniff2/lib
python
$ strings sniff2/bin/sniff | grep Copyright
/.../
Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
/.../
Yeah right! Python is everywhere.
That said, maybe someone from TakeFive is on this list, can write a
much better plug for SNiFF+, and tell me if SNiFF+ even supports
Python? (At least, that would be nice for those of us that happens to
use SNiFF+ :-)
/F
Monty Zukowski
> * Is it feasible to reparse a module everytime the file is changed?
> Are there better ways to keep track of the changes to a module?
A good LL(k) parser can parse incrementally and keep track of those changes,
since it is a top down parser. The PCCTS toolset would be ideal:
http://dynamo.ecn.purdue.edu/~hankd/PCCTS/
Unfortunately there is no example code for that kind of thing that I know of.
"Software Development by LL(1) Syntax Description" by Lewi, Vlaminck,
Steegmans and Horebeek has a small chapter devoted to it, as well as
references.
Since the parser is LL it is top down and theoretically you can have a
mapping of line regions to your parse tree. Knowing what lines have been
changed would allow you to re-parse only what you need. You do have to keep
all of your appropriate state as part of your parse tree, so you can pick up
where you left off. And you have to be careful about designing your second
and third passes if you have them.
Not that I've ever done any of this (nor am I at leisure to do so, sigh).
Anyhow it could become a python module so emacs or html could use a
background python server to get its info from.
Ain't dreaming fun?
Monty
mo...@tbyte.com
Ron Forrester
>
> Feature Set: [this is what I'd want as a minimum]
>
> -- python-aware editor, with indentation, tagged text,
> documentation/version control support, syntax checking, etc.
> -- a class hierarchy browser
> -- a module browser to study existing modules (built-in and
> otherwise)
> -- a built-in debugger
>
> (maybe Fred's? I don't know enough on the topic).
For me I would think the obvious place to do this is with Emacs -- its
already fairly python aware, and with some work could support the more
sophisticated aspects of your spec.
Its about as portable as it gets too...
rjf
--
| "I don't like being bluffed -- makes me doubt | r...@aurora.pcg.com |
| my perception of reality..." | 71722,3175 |
| Chris in the morning on KBHR | |
+---------------------------------------------------+-----------------------+
Robin Friedrich
In article <Pine.SUN.3.91.950621...@coil.nist.gov>, Ken Manheimer <k...@NIST.GOV> writes:
-snip-
|A lot of the tools i would like could be implemented in Emacs 19, and get
|us a substantial, highly integrated programming environment:
I agree in part with Ken on this. I am an Xemacs user and I wouldn't
object to having a development environment built on this robust
technology. But, I would prefer that it be thought of as a stop-gap
until a full python environment can be developed in a portable GUI
binding. I'm also a Mac user an I'd like a solution which works well on
the System 7 & 8 environments. I don't see emacs fully supporting the
kind of GUI-centric style needed on a Mac platform any time in the
forseeable future. Too many conflicting priorities in the emacs camp.
Another problem with emacs/Xemacs is the overhead of the system.
There's an enormous amount of stuff filling up RAM which never gets
exercised.
OTOH, the GUD may be a great blessing especially when it comes to
developing C/C++ extensions for python. An emacs solution is a good
idea (even though it'll need a lot of lisp programming, volunteers?)
but I would like to see the experience we gain developing it to be fed
back into a lean and mean portable GUI-based environment. I think we
would get a lot more time contibuted to this effort since it would be
written in python (everyone's favorite language;). Enhancing Xemacs
now effectively defers the GUI problem until later, which is fine. I
would hope, though, the gui-sig and the dev-sig would stay very aware
of each other's activities. Let's do it in Xemacs now _and_ in python
later.
--------------------------------------------------------------
| Robin K. Friedrich | frie...@rsoc.rockwell.com |
| Rockwell Space Operations | (713) 282-2974 |
| Houston, TX | |
--------------------------------------------------------------
Michael Scharf
SUMMARY
-------
I have integrated Python into the SNiFF+ editing and browsing
environment. This includes extracting symbol information from Python
source code (class names, method names, instance variables, function
parameters, import statements ...). In addition I have written a new
debugger interface which works fine with SNiFF+. Now it's really fun
to develop Python with SNiFF+!
--------
Fredrik Lundh <Fredri...@IVAB.SE> wrote:
> Just a little footnote...
>
> > I agree (though i've never hear of SNiFF+ - odd name, that).
> > There's an idea that i presented at my "python programming
> > environment" session at the recent workshop, which i want to
> > mention.
>
> SNiFF+ is a really good development environment targeted for C++,
> developed by TakeFive Software in Austria. It integrates editing,
> documentation, structure browsing etc, and allows you to use your
> favorite tools (such as emacs, gcc) fully integrated into the
> environment. It also seems to work fine for HUGE projects. And of
> course, SNiFF+ is quite expensive.
Yes, but for universities there exist a special discount. For more
information send a mail to (Europe: sn...@takefive.co.at) or
(USA: in...@takefive.com).
> But now for the really amusing stuff:
>
> $ cd sniff2
> $ ls sniff2/lib
> python
> $ strings sniff2/bin/sniff | grep Copyright
> /.../
> Copyright 1991-1994 Stichting Mathematisch Centrum, Amsterdam
> /.../
>
> Yeah right! Python is everywhere.
Yes everywhere :-) (That's what appears in the "About SNiFF" dialog.)
> That said, maybe someone from TakeFive is on this list, can write a
> much better plug for SNiFF+, and tell me if SNiFF+ even supports
> Python? (At least, that would be nice for those of us that happens to
> use SNiFF+ :-)
The quick answer is: SNiFF+ is going to be opened for other
languages and there will be multi language support (see below).
Therefore an "open parser interface" (OPI) has been defined. It
will be available in the next minor release (which is scheduled by
TakeFive for end of July) of SNiFF+.
Since I'm an alpha-tester of the OPI and a very big Python fan and
user, I wrote a Python parser and debugger interface. And it works!
I will make it available with the next release of SNiFF+. I don't
think it makes sense to distribute this in the current state,
because with the current SNiFF+ you can have only one parser (and
therefore language) at a time: either C/C++ or Python. Also, I
consider my code 'alpha'.
David Ascher <d...@maigret.cog.brown.edu> wrote:
>Feature Set: [this is what I'd want as a minimum]
>
> -- python-aware editor, with indentation, tagged text,
> documentation/version control support, syntax checking, etc.
> -- a class hierarchy browser
> -- a module browser to study existing modules (built-in and
> otherwise)
> -- a built-in debugger
BINGO! These are the features the SNiFF+ integration provides (except
for syntax checking)! Plus some more, like a class-browser, a
class-hierarchy-browser, a retriever (intelligent grep across a set
of files), configuration management (interface to RCS/SCCS/CVS/
ClearCase...), project management, interface to emacs (use emacs
instead the builtin editor), an integrated debugger interface etc.
I've been (and I am still!) a big emacs fan, I use emacs since 10
years, but for OO development SNiFF+ beats it because of its
specialized browsing tools.
OK, no more advertisement ;-), here is what I have done:
BROWSING PYTHON WITH SNiFF+
---------------------------
The current version of SNiFF+ (2.0.x) is very much C/C++ oriented,
but this will change in the next major release. Therefore I had to
squeeze the Python paradigms into the C/C++ model. Fortunately it
turns out that most of the important things we need for Python is
already in C++:
- The (class-) hierarchy browser works fine.
- In the symbol browser you can see all classes, methods,
instance variables, functions and global variables.
- In the class browser you can see all methods and instance
variables of a class (and it's super classes). The methods are
all public/virtual.
- If you look at functions or methods with signature, you don't
see the types of the parameters (which is a meaningless concept
in Python). Instead, you'll see the names of the parameters.
- With the retriever you can find the occurrence of any
symbol/string.
- From the editor you can jump to the definition of a selected
symbol. If you want, only the imported modules are scanned (I
fake import as C/C++ #include, so it always assumes everything
is imported)
Still, there are some problems:
- Where is an instance variable of a class declared? I just use
all places where something is assigned to the variable. So
instance variables may appear more then once in the browsing
tools. The alternative would have been to take the first
assignment as the declaration point.
- All methods are public/virtual.
- Many of the C/C++ concepts make no sense for Python (macros,
typedefs, non virtual methods, static members,
public/private/protected...). Therefore there are many buttons
in SNiFF+ which are unused for Python and should just not
appear.
- C/C++ does not have the concept of modules.
- It does not (yet?) do cross-referencing. Anyway, I think this
is almost impossible with a non statically typed language like
Python, because you cannot determine which method is meant if
you see something like x.f(). It could be any object defining a
method f() or even worse, it could be something you cannot find
out just steering at the source code (like eval or a builtin
method or some class using __getattr__). But I'm open for good
suggestions.
- Since I'm an emacs freak, I faked the font-lock-mode by
declaring strings as macros and language keywords as
typedefs. So SNiFF+ will highlight them in the editor, which
makes the code (at least for me) much more readable.
- Currently you can either run a C/C++ parser or the Python
parser. You have to quit SNiFF+ to use another language. But
this will change with the end of July version of SNiFF+.
- To my surprise, SNiFF+ has no problems with a method overridden
in a subclass having different parameter names. Since I use the
parameter names as the parameter types, SNiFF+ should recognize
a method with different names as an overloaded method and not as
overridden. Due to a bug (or a feature :-) it checks only for
the parameters to distinguish two (potentially overloaded)
methods if there is more then one method defined within the
current class (not considering the super class). (I think
gcc-2.5.8 had a similar bug).
- I assume that self in methods is really called self. This
should changed, but for now, it is a good first approximation
since most people stick to that convention.
- Class variables are not recognized. I mean in 'class X: y=42' y
is not found as member of instances of X. Except if somewhere
in a method of X there is an assignment like 'self.y=0'.
HOW IT HAS BEEN DONE
--------------------
To extract the symbol information (like variables, class, class
name etc) there is a parser running in background which is
activated each time a file changes on disk. It then feeds SNiFF+
with the start and end position of each symbol in the file. In some
cases you have to give some additional information like the list of
parameters or super-classes. But all in all it's quite simple
(unless you want to support cross-referencing). Currently only one
such parser (the C/C++ parser) can talk to SNiFF+ using
sockets. But as I have said, this will change...
I wrote a simple (fuzzy) parser using only flex with exclusive
states. To my surprise it works fine even in very tricky cases. And
it is fast.
Before this, I've been experimenting with a parser written in
Python, but it turned out, that it is far too slow -sigh-. So now
I'm experimenting with a lex/yacc-like builtin for Python. My first
experiments show, that this is about one order of magnitude faster
then something purely written in Python. As reference language I
used SGML/HTML and compare the speed to HTML-lib.py.
THE FUTURE OF THE PYTHON INTEGRATION
------------------------------------
It would be nice to teach SNiFF+ about builtin classes. If a parser
would parse the Python-C-API it could generate artificial classes
which then can be browsed and put into the class hierarchy.
Since there are two ways of inheritance, class inheritance and
delegation inheritance, it'd be nice to also support delegation
inheritance. What do I mean by this? Let's assume you would want to
extend the builtin file class. A simple wrapper would help:
class MyFile
"""A file that returns uppercased lines.
HINT: superclass=file"""
def __init__(self,file):
self._file_=file
def __getattr__(self,name):
return getattr(self._file_,name)
def readline():
line=self._file_.readline()
from string import upper
return upper(line)
It should appear as a subclass of file overriding the method
readline. Maybe with the assistance of some structured comments or
docstrings.
SNiFF+ should support some of the Python concepts better: like
modules, no static (compile time) typed variables etc.
Get some ideas how one could generate Python cross-reference
information.
Convert (automatically) the Python documentation to the
Documentation Browser format (which, in the long term, may become
SGML/HTML).
DEBUGGER INTEGRATION
-------------------
Since developing without debugging is a pain, I decided to
integrate the Python debugger into SNiFF+. SNiFF+ does the
following: It runs a command line debugger in a pty and interprets
its output (e.g. where a break point has been set or the stack
trace) and if you hit a button or a menu entry, it types something
to the debugger. To adapt to a new debugger you have to write a
debugger adaptor (in C++) which matches the output of the debugger
and does a translation of the internal (menu/button) commands
(step, break, run etc) to some strings typed at the debugger
prompt. Since I prefer writing Python code over writing C++ code, I
decided to write a new Python debugger that fakes the input and
output of the gdb (GNU debugger) for which an adaptor already
exists.
In order to make it really act like the gdb, I changed some of the
commands (input and output) + I wrote a new cmd.py (I call it
cmdl.py) which uses docstrings to find out about documentation of
the functions... (BTW. that's one of the things I use the
readlinemodule.c for, which I posted a few days ago :-). In
addition, it is not necessary to change any Python code to run the
debugger. Instead, I read the file to be debugged and eval it from
the debugger faking it would run in the module __main__.
With all this it is really fun to use the debugger, because
breakpoints are set in the source editor, you can step through the
code and print whatever you like to see ... In fact, before I had
this interface I didn't use the debugger at a lot, but now it's so
much easier :-).
I have not tried yet, but I think one could use this debugger also
from within emacs as a Python replacement of gdb. Before I make my
pydb available I'll test this as well...
What I'm also thinking of is a mode where you can have both
debuggers (gdb and pydb) simultaneously and you can set break
points either in Python or in the C/C++ code.... well it's maybe
not trivial but it would be nice.
TakeFive, SNiFF+ AND Python
---------------------------
In SNiFF+ Python is currently only used to extend the editor. It is
considered as a first step and has therefore not been made
public. There has been quite some discussion which extension
language to use for SNiFF+ and it is not clear if Python is the
best choice. The mayor argument against Python and for [incr TCL]
is that TCL is much better known (a wider user basis) and it has a
better chance of survival because of this and maintained by SUN. On
the other hand (and that is my argument), Python is the *much*
nicer and cleaner language.
So folks, how would you convince TakeFive to continue using the non
mainstream language Python instead of TCL? Or is Java the future?
(No language wars, please, just some good arguments for Python :-)
Michael
P.S.: Don't be surprised if my e-mail address will change in the
near future to Michael...@TakeFive.co.at ...
--
___ _ _ ___ _
| __) | \/ | | ) | | Michael Scharf Tel: +49 6221 387 305 FAX: 517
| _) | | | -< | |_ EMail: Michael...@EMBL-Heidelberg.de
|___) |_||_| |___) |___) http://www.EMBL-Heidelberg.de/~scharf/
Marc Wachowitz
> OTOH, the GUD may be a great blessing especially when it comes to
> developing C/C++ extensions for python. An emacs solution is a good
> idea (even though it'll need a lot of lisp programming, volunteers?)
[Heresy on]
One may also think of developing a Python front end for guile, GNU's new
scripting language - I think that's supposed to run in Emacs too at some
time. If one specifies carefully what exactly is "portable Python", it's
probably quite feasable.
------------------------------------------------------------------------------
* wonder everyday * nothing in particular * all is special *
Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Ken Manheimer
> developing C/C++ extensions for python. An emacs solution is a good
> idea (even though it'll need a lot of lisp programming, volunteers?)
> but I would like to see the experience we gain developing it to be fed
> back into a lean and mean portable GUI-based environment. I think we
> would get a lot more time contibuted to this effort since it would be
> written in python (everyone's favorite language;). Enhancing Xemacs
> now effectively defers the GUI problem until later, which is fine. I
> would hope, though, the gui-sig and the dev-sig would stay very aware
> of each other's activities. Let's do it in Xemacs now _and_ in python
> later.
I agree. I see a lot of leverage to be gained from what exists currently
in emacs (and am excited to see that the things michael scharf has done
with the SNiFF+ gdb "adaptor" may transfer over to emacs gud, and be a
reality sometime soon!). However, i see, also, some crucial benefits to
implementing a python programming environment in python, itself, and
certainly feel that is the right ultimate goal.
(One "crucial benefit" is that python-implemented progenv tools would be
more immediately usable as components of python programs - people could
deploy their functionality *in* their programs, not just in the building
process. In my view, that's a primary motive for having a python-based
GUI, in general. I expect prog-env tools should be an important component
of GUI efforts...)
David Ascher
>I see a lot of leverage to be gained from what exists currently
>in emacs (and am excited to see that the things michael scharf has done
>with the SNiFF+ gdb "adaptor" may transfer over to emacs gud, and be a
>reality sometime soon!). However, i see, also, some crucial benefits to
>implementing a python programming environment in python, itself, and
>certainly feel that is the right ultimate goal.
>
>(One "crucial benefit" is that python-implemented progenv tools would be
>more immediately usable as components of python programs - people could
>deploy their functionality *in* their programs, not just in the building
>process.
Agreed. Furthermore, the (x)emacs/sniff platforms are fine for unix
workstations, but PCs and Macs are left in the dark.
I'm quite excited by a Python integration in SNiFF+ because SNiFF+ is intended
as a dev't environment, hence has a more appropriate architecture for what is
needed than emacs has. The downside of course is that SNiFF+ is a commercial
product (albeit cheap for universities), and that SNiFF+ isn't available on non
unices.
While I don't expect a full python progenv in the immediate future, I'm glad to
see that we've already identified some of the key requirements for one, such as
an incremental parser.
--da
Ron Forrester
> Ken Manheimer wrote:
> >(One "crucial benefit" is that python-implemented progenv tools would be
> >more immediately usable as components of python programs - people could
> >deploy their functionality *in* their programs, not just in the building
> >process.
>
> Agreed. Furthermore, the (x)emacs/sniff platforms are fine for unix
> workstations, but PCs and Macs are left in the dark.
I don't know about SNiFF+, but excellent versions of Emacs are
available for Windows, Windows NT, and Mac (I am using Emacs 19.28.2
for Windows NT, which supports fonts, color, mouse, menus, etc, its as
close to XEmacs as you can get -- also, NT support has been folded
into standard Emacs as of version 19.29, which I believe was just
released). See the Emacs FAQ for where to get these versions.
Using NT Emacs with Python mode has made exploration of Python much
easier for me.
Michael...@embl-heidelberg.de
> as a dev't environment, hence has a more appropriate architecture for what is
> needed than emacs has. The downside of course is that SNiFF+ is a commercial
> product (albeit cheap for universities), and that SNiFF+ isn't available on non
> unices.
The non availability of SNiFF+ on non unices will change in the future -- at
least Windows-* will be supported sometime next year; I don't know about
MacOS.
Michael