[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Axiom-developer] RE: Emacs + input syntax
From: |
C Y |
Subject: |
[Axiom-developer] RE: Emacs + input syntax |
Date: |
Thu, 11 May 2006 12:07:24 -0700 (PDT) |
--- "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