axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] RE: Emacs + input syntax


From: Page, Bill
Subject: [Axiom-developer] RE: Emacs + input syntax
Date: Thu, 11 May 2006 12:28:19 -0400

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)?

> 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?
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. 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.

> 
> 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. 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).

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.

> 
> 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.

> 
> 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.

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

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

> 
> 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.

> 
> 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.

Regards,
Bill Page.




reply via email to

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