axiom-developer
[Top][All Lists]
Advanced

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

[Axiom-developer] Re: Axiom tutorial by Bill


From: Joris van der Hoeven
Subject: [Axiom-developer] Re: Axiom tutorial by Bill
Date: Sun, 9 Nov 2003 12:09:31 +0100 (CET)

http://www.math.u-psud.fr/~vdhoeven: personal homepage
-----------------------------------------------------------

On Sat, 8 Nov 2003, root wrote:
> Good morning, Joris.
> One of the things to think about is that the tutorial was written to
> run in Axiom's help system called hyperdoc. Hyperdoc has several
> features that are enabled by embedded tex macros. All of these are
> in the axiom style file. Using tmdoc would break things in hyperdoc.

No, it does not; the axiom-manual style should inherit from tmdoc,
but may also provide all functionality from the original axiom style.
Secondly, it is easy to write scheme functions which forget about
the additional functionality provided by tmdoc.

> It will allow examples to be clicked on and executed.
>
> It allows "constraints" between lines. That is, if the example that is
> chosen requires previous examples then the previous examples will be
> automatically run first. If you try to execute, say, a draw command
> and the function defined in the draw command is defined elsewhere
> you can specify in the tex macros that the definition must be run first.

Yes, that is the idea. But we have to be careful about how,
precisely, this should be implemented.

> It allows navigation (thus the random-looking "help", etc).
>
> It allows embedding the live graphics image directly into the page.
> Thus if you execute a draw command the image will show up in the page.
> But if you click on the image it becomes a separate window on the desktop
> and can execute live (e.g. rotate, scale, print, etc).

Live graphics is again another topic. Ideally speaking someone should
implement an OpenGL plugin for TeXmacs, so that the user can do this
kind of manipulations both directly into the text or in a separate window.
Also, such a component would be easily reusable by the 18 other system to
which TeXmacs connects... So if someone is interested to spend a month
or so on this job, then please contact me.

> It allows "tear-off" pages. That is, you can click on a page and move
> it to the desktop as a freestanding page. It would be like clicking on
> a mozilla tab and opening it a new desktop window.

I do not exactly understand what you mean, but this seems easy to do.

> Almost all of this is supported by inline TeX macros.
>
> Several new facilities are planned such as the ability to follow
> citations in the text, dynamically extract, compile, load, and execute
> the code in a pamphlet, dynamic "booklet" construction by adjoining
> sections from pamphlets, semantic search (so you can find Abelian as
> a concept, as a math definition, as code implementation in a particular
> domain, or as standard text in pamphlets and booklets.

This is much easier to program when your document is a tree and
we already have some of these facilities in TeXmacs. So: why not
implement the others inside TeXmacs, because this will serve many
others besides axiom users?

> re: buggy tex/latex
>
> If you find buggy examples of tex/latex please send them to the list.
> I know of one bug due to escapes that I'm chasing on another queue.
> I'm documenting how I debug it in the DevelopersNotes file so developers
> can see some of the debugging tools. It is listed as an open bug.

Just look at Bills tutorial, and you will find many of them,
either bugs, or ugly exports.

> I never use tex/latex output so I'm unlikely to see the bugs.
>
> re: trailing ->
>
> We could probably implement a "set prompt" command that would allow
> you to set the prompt to anything (including nothing). Would that help?

No; I have to do something here...

> re: the more general interaction of TeXmacs and Axiom
>
> We've had many discussions about this subject as I have a near religious
> belief that documentation is vital. We're not using the computer to do
> anything more than a fancy typewriter at the moment. That's fine for now
> but it will be positively primitive in 30 years. I've attached parts of
> other discussions here just to recover them from history.
>
> I'm not sure how far TeXmacs is willing to change to support Axiom.
> Clearly most of the technology we develop over time will not be specific
> to Axiom (e.g. running embedded code in a pamphlet could be Maple code).
> If the machinery is done correctly then the current Axiom would just be
> a plugable "engine". A lot of the ideas would be useful in TeXmacs.

Yes, and *much* easier to program directly inside TeXmacs,
because we already have all necessary infrastructure for it.
Moreover, TeXmacs is a *dynamic* editor, not a batch job processor,
and improvements inside TeXmacs *directly* serve to all other systems
to which we already connect.

About the attached previous discussion:
  1) What existing systems for documentation did you take a look at?
     The OMDOC DTDs might provide many of the things you need.
  2) If you have a precise idea about the DTD you want, then it will be
     worth it to spend some time to write a TeXmacs plug-in for that,
     consisting of a style file and scheme routines with interesting
     operations for your tags.
  3) Live graphics would be quite easy to implement in TeXmacs,
     if there is a volunteer to write an OpenGL plug-in.





reply via email to

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