[Axiom-developer] RE: Emacs + input syntax

[C Y]

--- "Page, Bill" <address@hidden> wrote:

> Cliff, 
> 
> On Thursday, May 11, 2006 10:54 AM you wrote:
> > 
> > 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?
> 
> No. _ can be used as a line continuation both at the command line
> and in .input files. And I think also in SPAD (and Aldor)?

OK.
 
> > 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?
> 
> I am not sure what you mean. Do you mean that you would automatically
> generate the _ line continuations if the emacs buffer consisted of
> multiple lines so that in effect Axiom always is asked to execute
> the entire contents of a buffer as if it was just one long line?

Right.

> If this is what you mean, then I suppose that will work but you
> would in effect be generating yet another slightly different
> input syntax for Axiom.

Yes, but I think this is a logical extension, and definitely more
intuitive for new users.  Return for a line break and Shift-Return for
an evaluation are commonly used and well known - _ as a necessary
precursor to a line break is neither outside of Axiom.  Any other GUI
interface created for Axiom is not likely to use the _ notation for
line breaking.

> The main difference between this and the
> syntax used in the ')read' command is that it would not allow
> '#pile' (indentation) block structure. You would always have to
> insert parenthesis (not {}!) and semicolons ; to separate commands.

That's where mmm-mode should come in.  If I can master Emacs properly,
I think it might be possible to have a "pile" editing environment which
would enforce the rules.

What I am aiming for, based on what I have thought about so far, is a
default "non-pile" syntax environment (e.g. normal command line +
returns without _) and the user option to switch to an "input"
environment which supports all of the input syntax including pile
syntax.

> > 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?
> 
> Again, I am not sure what you mean by "normal user level input".
> Both the command line and the ')read' command accept _ as a line
> continuation. The difference is in the use of '#pile' indentation
> syntax as used in SPAD or not.

OK, I think I'm getting it.  So the difference between command line
legal syntax and input legal syntax is that the latter case allows (or
even requires) pile syntax?

> This is also used in some modern
> languages such as Python. On the other hand the Axiom command
> line always treats everything as a single input line (continued
> or not).

Got it.  I've programmed in python a little as part of my job, so its
not totally foreign.  Just a bit odd ;-).

> Aldor introduces yet another input syntax using brackets { }
> and semicolons ; in a block notation that is common in "C"
> and several other languages. But I suppose that is irrelevant
> to the current discussion.

Unless we are allowing Aldor in ")read" commands.  Then it might be
important.  But that's probably for the future.

> > 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.
> 
> I don't that is necessary. Simply treat everything as ')read'
> style .input syntax. In all other respects .input syntax is
> the same as the command line input. You have to allow _ in any
> case, but you don't need to generate anything automatically.

That might work, but I think I would like to have special provisions
(if I can manage it) for input/pile syntax.

> > 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.
> 
> I think this is important if you support both command input
> and SPAD/Aldor compiles. You need to know whether to generate
> a ')read' command or a ')compile' command.

Well, the eventual goal is to support all normal ways of working with
Axiom.  Which would probably be easier if I knew more about them, but I
think a lot of the support for such things will need to come later.

> You might also want to provide syntax highlighting and
> indentation folding (hiding).

Yes.  That is part of the plan but is down the road a ways.

> And of course if you are allowing noweb markup text mixed
> with your saved Axiom session that's a whole 'nother thing.

Not quite.  What I'm planning to do is create a mechanism to insert
latex or text "boxes" before and after an input-output combination. 
I'm envisioning a "graded" approach - on the far right is the basic
command line (more or less what exists now).  On the far left is a
literate latex document with aldor code chuncks.  In the middle are
EAxiom latex documents - a document with Axiom user sessions embedded
such as in the Maxima manual - and annotated terminal sessions.  So you
will eventually have your choice of a variety of modes:

1)  Terminal mode - as seen now
2)  Terminal mode + comment regions
3)  EAxiom latex document with embedded sessions
4)  Literate program with lisp code chuncks
5)  Literate program with aldor code chuncks

If there is demand for it I suppose a generic text environment with
support for sending strings to LaTeX is also possible, although I'm not
sure why one would want to use text instead of LaTeX for such a
purpose.

> > 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.
> 
> I would say "keep it simple". Just process all Axiom input
> via ')read' for now.

That might be the sensible thing.  One thing though - I'm not sure if
the _ trick for multiple lines/pile syntax will work from an Emacs
buffer.  I could probably work it by having the return check for a _
character immediately behind it, but I don't know if the default comint
bindings would do.  Hmm...

> > 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 think the change to always using ')read' for Axiom input
> should be a simple and local change to your program as it
> exists now.

Do I have to use temp files, or is there a way to do )read "string"?

Cheers,
CY

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com