texmacs-dev
[Top][All Lists]
Advanced

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

Re: [Texmacs-dev] Path computations


From: David Allouche
Subject: Re: [Texmacs-dev] Path computations
Date: Tue, 24 Jun 2003 15:24:30 +0200
User-agent: Mutt/1.5.4i

I love this kind of message!

On Mon, Jun 23, 2003 at 10:59:11AM +0200, Philippe Audebaud wrote:
> 
> Assume  (for a reason  or another)  one wants  to allow  a script  or program
> external to TeXmacs making computations on paths for a document.

I am not sure I understand what you mean by "a program external to
texmacs". Operations on texmacs documents are best done inside
texmacs. I believe there is some way to control texmacs from an
external program using the "plugin" (aka. CAS) interface. Maybe you
should give us more context.

> ----------------------------------><8---------------------------------------
> this is a string
> 
> <verbatim|(0 13)> is the path, cursor left to the second 'i' letter.
> 
> - the meaning is 0=first paragraph in the document, 13=position in the string
> 
> <strong|this is a string>
> 
> <verbatim|(3 1 13)> for the same postion, and the structure is
> <verbatim|\<less\>strong\|this is a string\<gtr\>>
> 
> - the meaning is 3=fourth paragraph, 1=second position in the macro, 13=...
> 
> <with|mode|math|this is a string>
> 
> <verbatim|(6 2 13)> for the same position, the structure being
> <verbatim|\<less\>with\|mode\|math\|this is a string\<gtr\>>
> 
> - the meaning is 6=sixth para, 2=fourth position in the macro, 13=...
> ----------------------------------><8---------------------------------------


There is a bit of confusion here because you are using the deceptive
so-called "texmacs format". This format really is only good to let
human readers grasp what is inside a texmacs document without using
texmacs. For any other purpose (especially structural operations) you
should use the "Scheme format".

You can get the scheme representation of the current buffer with:

    (tree->object (the-buffer))

You document then becomes something like:

  (document
    "this is a string"
    (concat (verbatim "(0 13)") " is the path ...")
    "- the meaning is ..."
    (strong "this is a string")
    (concat (verbatim "(3 1 13") " for the same ..."))
    "- the meaning is ..."
    (with "mode" "math" "this is a string")
    (concat (verbatim "(6 2 3)") " for the same ...")
    "- the meaning is"
    ""
    ""
    "")

> So what  ? 'strong' is a user  macro, defined in some  TeXmacs package, while
> 'with' is a  TeXmacs *primitive*. In the first case,  the macro name position
> is taken  into account in  the computation. In  the second case, it  is *not*
> taken into account.

This is exact.

> 1) what are  the very reasons for such  a difference within the  two kinds of
> 'macros' ?

Internally a macro expansion is represented as

  (expand "strong" "this is a string")

Actually, if you do

  (tree->object (object->tree '(expand "strong" "this is a string")))
You get
  (strong "this is a string")

The reason is that in its canonical representation, a macro expansion
whose macro names is different from all built-in structures (see
tree_label.cc) has an _implicit_ EXPAND.


> 2) If such a behavior must be  preserved, then I think a scheme function like
> 'primitive?', 'tm-primitive?' (...which ever  the name), returning the status
> for these names will be welcome to help developers.

In the module (convert tools stm) I defined a function
"stm-primitive?" which does exactly that.


> I feel really bad with such a distinction, and TeXmacs crashed badly for many
> times  until I  figured out  that  the problem  was *that*  one. Moreover,  I
> remember defining a macro with name  'group' without knowing it was a TeXmacs
> primitive.  Of  course, several  documents  of  mime  behaved badly  in  this
> context! But  no warning  was given  for redefining a  primitive... And  as a
> matter of consequence, path computation  changed !

In scheme notation, the expansion of the macro "group" is written:

  (expand "group" "blah blah")

because indeed GROUP is a primitive.

> I can also imagine status changing from a TeXmacs version to
> another, so the way of computing paths seems too much context
> sensitive to me.

When loading documents from older versions, TeXmacs will automagically
perform any required upgrade, so you can be confident that your
document semantics will not silently change (as long as you keep
opening older documents with newer executables, there is garantee the
other way).

> How can we deal best with this issue?

I depends on what exactly you are doing. Most of the time you need not
deal with this issue. When you really have to, the best way is
definitely to use the stm-primitive? predicate and make a clear
separations between macros and primitives.

In tmhtml.scm (the texmacs->html converter), I use two tables:
%tmhtml-primitives for primitives and %tmthml-stdmarkup for macros.
The dispatcher system then use the right tables when appropriate.

Well... actually the tmhtml dispatcher does not use the robust (though
hackish) stm-primitive? function, so it is not really robust when the
set of primitive names changes. Thanks, I put fixing this on my todo
list.

-- 
                                                            -- ddaa




reply via email to

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