Re: [Axiom-developer] Lazy re-evaluation (was: More AxiomUI)

[William Sit]

Bill: 

This is Part IV: History, 2D editing


> [comments on using )history snipped]
> 
> > What is desirable in the interpreter interface, is the ability to
> > edit previous input lines in a 2D way. Mathematica allows it and
> > makes it very easy to do quick exploratory computations during the
> > development phrase.
> 
> 2-d editing might be possible if we can use mathML. In that case
> it is possible to select displayed 2-d sub-expressions, modify them
> with a few keystrokes (e.g. by typing the corresponding linear 1-d
> sub-expression). But in general wysiwyg equation editing is often
> awkward at best. And input of commands actually involves more
> semantics than what is normally explicit in the 2-d display. Both
> Maple and Mathematica have invested a great deal of effort in a user
> interface that (in principle) allows this. But even after all this
> effort, I really don't like to use it. I am too used to the "old" way
> of doing it, I guess - using a separate linear 1-d "input syntax"
> to type the commands.

You know what, I agree 100% with you on this. But you misunderstood my
interpretation of 2D editing (well I guess was not clear). I mean the ability to
edit "previous input lines in a 2D-way". This means being able to jump to (mouse
to?) an input line on screen, edit this in a 2D way (screen editing, like what
can be done even in vi). I do not mean the extra fancy things like selecting
subexpression from outputs! Yes, M and M allow that, but they don't work well
precisely for the reason you mentioned. (Derive did it really well).
 
> > The final order of execution can be done with cut and paste right
> > there on screen in the FrontEnd and there is no need to save the
> > history into a file first (because the interface *is* the editor
> > as well). Maybe an emacs or TeXmacs interface can do that?
> 
> The information in the history file is necessary if we want to
> perform lazy re-evaluation as I described above.

I would say a cleaned history file: only commands that were executed correctly
should be in the history file.

> >> These could be mapped to corresponding output areas in the
> >> browser.
> >
> > A browser (web browser) is not a text editor (yet). In fact, it
> > is probably undesirable to make a browser into an editor.
> 
> I disagree. Have you tried Kai's AxiomUI demo yet?

No. How?
I think you might have misunderstood my comment above. Why would any web site
(other than Wiki sites; commercial ones especially) allow users to edit a page?
Editing user inputs, yes, but that is different. Embedding an editor and giving
some real estate to it is not what I had in mind.
 
> > As nice as Wiki is, one still have to edit the source text, rather
> > than the rendered text.
> 
> That is true, but in most cases I would argue that this is *more
> efficient* then 2-d editing of the commands whose output generated
> some rendered mathematics.

I did not comment on editing output. I used "rendered text". I think it is more
efficient to be able to edit rendered text without resorting to a separate
region running an external editor (which allows screen (2D) editing). However,
that would not be desirable for other reasons.
 
> > In Mathematica, this would be like requiring editing the Notebook
> > file in text mode (which one *can* do, even on a cell-by-cell basis).
> > I can't imagine editing XML in text mode (I have tolerated editing
> > html, including those generated by MS Word or including Chinese, but
> > I think direct editing XML is not for me).
> 
> It is not expected that an AxiomUI user would edit XML markup. It
> is also likely that we can avoid almost all HTML except in the
> case of some complex page structures.

Sure, it is "not expected". But since when is it true that when things are
editable that it is not edited? They say the same thing when html first came
out. You know how big those html files are when generated automatically by MS
word? As I said, neither is Mathematica Notebook expected to be edited, but
occasionally, it is necessary, if only on a cell basis.

> > What may be needed and would be extremely helpful in terms of
> > user experience, is again what Mathematica allows: 2D editing,
> > with multiple selection of cells, not necessarily adjacent,
> > and then one shift-enter does it.
> 
> "Selection of cells" is essentially what Bob and I were discussing
> above that you seemed to "miss".

Glad we agree on the feature. But this editing feature is separate from, though
can be used for, the problem about re-evaluation.

> 
> > I would love to have Mathematica FrontEnd working for Axiom
> > (the best of both worlds). There are many many features of the
> > FrontEnd that are great and unparallelled (to name just a
> > few besides those already mentioned: all Notebooks are ASCII,
> > include editable input and output, graphics, incorporated style
> > sheets, independent of platform or operating systems, can be
> > converted into html, tex, etc; the entire Mathematica documentation
> > available, with live editable examples, and programmable using
> > FrontEnd commands).
> 
> Don't get me wrong: I think there are some very good things about
> both the Mathematica and Maple user interfaces. But user preferences
> for particular worksheet interfaces is a very subjective thing.
> Because of the high learning curves it is often dictated largely
> by one's individual experience and emotions like product loyalty
> (or the opposite of loyalty ;) which are often generated by intense
> intellectual investment. Disagreements on user interface design
> probably generates just as much or more "heat" then opinions
> about programming languages.
> 
There you have it. We agree to disagree.

William