[Axiom-developer] Re: [ANN] new version of axiom mode for emacs.

[C Y]

--- Martin Rubey <address@hidden> wrote:

> Dear all,
> 
> after a day of hacking and with some help from Cliff and Jay (many
> thanks!) I have a new version of axiom.el, which you find attached. 

SWEEET!  Thanks Martin!

> I'd be extremely grateful for feedback! 

I'll test it on my home machine tonight.
 
> M-x axiom 
> starts an axiom session or returns to an already started one.  We
> really should provide functionality to have several sessions in 
> parallel, but I don't know how to do this.

I didn't either, when I worked on it :-(.  I think it involves tracking
number of buffers and process IDs of various Axioms or some such...

>   * I fixed bugs that positioned point incorrectly and screwed up
> overwriting old output.  Cliff: you said you fixed that already 
> once.  Could you see whether you had a different axiom.el.pamphlet
> than provided on MathAction?

Sure.  Your solution may be more robust than mine, or perhaps the
version I have on my machine doesn't match the latest on the wiki...

> ToDo:
> 
> * Testing: does it work with xemacs? does it work under MSwindows?

It used to work under Windows (with AXIOMsys), at least the one time I
was able to test it (except for the overlay mechanism used to turn
input red - that worked partially but only was completely correct in
the latest cvs development version of Emacs for Windows...)
 
> * the way we deal with system commands like )quit is unsatisfactory
> for two reasons:
> 
>   - we do not allow user interaction: )quit will quit without asking,
> but worse, )di op 1 will make emacs appear to hang. C-g get's
> everything back to normal.  Reason: )di op 1 will make axiom ask
> whether we really want a long list of operations.

I forced quit to avoid having to hack up a way to handle it cleanly if
someone typed )quit somewhere other than the final input line, IIRC.  I
have no idea how to deal cleanly with ) style commands - the current
mode uses string matching, which is quite simply a hack.

>   - (1+x)q will be parsed as )quit.  We do not check yet whether the
> first non-white space character is the open parenthesis.

Opps.

> * the underscore character does not work.  It should...
> 
> * the way we wait for output looks extremely dangerous to me:

Absolutely agree, I would very much appreciate a better way if anyone
knows one.

>   what if output contains ") -> " and we are unlucky?  Not sure
> whether this is a problem though.  In all other places, instead
> of ") -> " the regular expression axiom-prompt is used.  Shouldn't
> we do this here, too? 

That should be OK, but it wouldn't solve the "output contains ) -> "
problem.  That is not solvable in any reasonable way unless you want to
track column position in the regexp, and I'm not sure how to do that in
Elisp - maybe search for #\Newline(****) -> somehow?  Ironically, the
cl-web style buffer processing would actually be useful here. The best
way would be a communications protocol and buffer behavior that doesn't
rely on these kind of regexp hacks at all.

> Isn't there a simpler way to look for output?

Probably, but as you are no doubt gathering I don't know enough about
Emacs to be able to say :-(.
 
>   In fact, it might make sense to keep the current output number in a
> variable -- that way we could also detect errors.

That would also be nice, but at the time I couldn't figure out how to
store buffer contents in variables.  (Silly, I know.)  I think Jay may
have pointed out how to do that at some point...

> * It would be nice to give the output a different face, as in
> mmm-mode, but I'm a bit lazy.  Maybe today evening.

That would be nice.

> * S-return should overwrite old output while return should copy the
> input line at point and evaluate it at the bottom of the buffer.

Heh - I guess I have opposite expectations for behavior - I expect
basic arrow keys to move me to inputs and return to overwrite ;-).  No
problem, key bindings are easy to change if documented.

> * it would be extremely nice to have command tab-completion, as when
> starting axiom in a shell.  (The polymake team would like to have
> this, for example.) Anybody knows how to go about this?

Erm.  SLIME does it for Lisp, but I have no idea how.

> * undo should have sane behaviour, whatever that is.  Possibly, it
> should be restricted to the current input, but that might be too
> restrictive. (For example, if one has overwritten some important 
> output by accident.)

That's a point. Hmm.

> * cleanup is certainly necessary.  I don't know elisp well enough.

Neither do I :-(.

>   It is extremely important that this mode works reliably, and as it
>   is currently, I wouldn't be surprised if it would screw up in weird
>   circumstances.

Indeed.  However, it's original ambitions were rather modest :-).  I
don't expect most of the current design to scale, but I have no idea
how to make the Emacs behavior more robust.  Personally I'd be more
interested in using LTK or McCLIM to make exactly what we need, but
that's a ways off - for now, it's Emacs or nothing :-/.

Thanks for your work Martin!

Cheers,
CY


       
____________________________________________________________________________________Got
 a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz