--- Martin Rubey <[EMAIL PROTECTED]> 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 _______________________________________________ Axiom-developer mailing list Axiom-developer@nongnu.org http://lists.nongnu.org/mailman/listinfo/axiom-developer