[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Axiom-developer] Emacs + input syntax

From: Francois Maltey
Subject: Re: [Axiom-developer] Emacs + input syntax
Date: 11 May 2006 18:13:26 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Hello Cliff, 

> A couple of quick questions, so I know what I'm up against:
> 1.  I don't suppose the use of the _ character to indicate a new line
> is unique to input syntax?  If not, would it be OK to make it so in
> Emacs if I can make multi-line input without it in "normal" input mode?
> 2.  If the answer to both questions in #1 is no and I can't assume the
> _ character is unique, is there any reliable way to detect when someone
> is inputing input syntax rather than the normal user level input?

I think it's too complex to detect inside emacs if 
the syntax is an axiom-command-line or an axiom-input-style.

You may have a global variable axiom-input-mode, someones set to 
'axiom-command-line, others to 'axiom-input-syntax.
   (setq axiom-input-mode 'axiom-command-line) 
or (setq axiom-input-mode 'axiom-input-syntax) 
at the beginning of axiommode.el

> 3.  If the answer to #2 is no, how should I know when to do the input
> syntax eval instead of the normal eval?  I could define a different key
> combination but if the user forgot to use it it might generate a bit of
> a mess.


When you use the *.input file method I find three exceptions 
where you CAN'T create a new *.input file to send data to axiom.

After the first (1)-> : think to the bug arround the duplicate (1)->.
After )quit you must send a string to axiom, not a )read command.
After )d op axiom wait a yes.

So here is my old function which respond if I must send a file or not.

The reponse of this function is 
  'wait [a file], 'wait-kbd [a string] or 'run [axiom is running]

(defun axiomRun-kernel-state-by-output nil
    (let (tmpa tmpb tmpc tmp)
      (goto-char axiomRun-marker-edit)
      (setq tmpa 
          (posix-search-backward "^\\(([0-9]*) -> $\\)" nil t) 
          (match-end 0)))
      (goto-char axiomRun-marker-edit)
      (setq tmpb
          (posix-search-backward "and return to the operating system:\n" nil t)
          (match-end 0)))
      (goto-char axiomRun-marker-edit)
      (setq tmpc
          (posix-search-backward "yes and then pressing Enter :\n" nil t)
          (match-end 0)))        
        ((not (or tmpa tmpb tmpc)) 'run)
        ((= 14 (count-lines 1 axiomRun-marker-edit)) 'run)
        ((and tmpa (eq 1 (- (marker-position axiomRun-marker-edit) tmpa))) 
        ((and tmpb (eq 1 (- (marker-position axiomRun-marker-edit) tmpb)))
        ((and tmpc (eq 1 (- (marker-position axiomRun-marker-edit) tmpc))) 
        (t 'run)))))


There is an other problem : 

If you send too quickly 2 lines to axiom, after a [Ctrl-K] [Ctrl-Y] as
axiom itself mismatch the output.

So axiom-mode might send lines (or blocks) one after the other.
Then there are two possibilities : 

1-either you send only one line to axiom, 
  and wait the next [return] for the next line
2-either you send only one line to axiom, 
  and when the output show that axiom has finish one line 
  the emacs mode sends the next one, and so on
  but finish when the cursor is inside or before the actual line.


> I've been looking at mmm-mode for other reasons, not the least of which
> is the eventual need to handle literate documents, but I think I'm
> going to need it sooner than that so I might have to take time out to
> figure out how to use it, customize it, and integrate it.  It looks
> like the most robust way to handle this might be to use an mmm-mode on
> a per-input style level and figure out invisible text, which is all
> right in a way because even in termainal mode I have other ideas for
> mmm-mode and will need to come to terms with it.

It's perhaps too complex to mix 2 modes. 
One for axiom-run and second one for faces and colors.
I never do it. 

> If I need to do that, I'm going to have to take time out for a
> re-organization and refactoring of the code.  I've got some tricks in
> there now for dealing with things like flagging mismatched IO pairs,
> but incorporating mmm-mode could result in massive changes all across
> the board.

Perhaps properties are sufficient to detect pair input/output.


> So here's the last question - is anybody using this mode now, or to be
> more specific is anybody using it enough to warrant me squashing the
> one or two easily fixed bugs before I rip the guts out?  If not I'll
> just go ahead and ram heads with mmm-mode, but that will mean no
> updates on the current mode for an unforseeable amount of time.

I admire your use of comint. 

I found easiest to re-rewrite the input/output between axiom and emacs
when I done mupad-run and axiom-run.

I don't understand what you want to do with the mmm-mode.

Have a good day !


reply via email to

[Prev in Thread] Current Thread [Next in Thread]