Re: [Texmacs-dev] (Important for scheme hackers) TeXmacs tags become more stable

[Joris van der Hoeven]

> >   1) Replace all EXPAND/VAR_EXPAND/HIDE_EXPAND/APPLY tags by
> >      built-in primitives or COMPOUND tags. The second ones are
> >      only used if the name of the COMPOUND tag is not a string.
>
> still the  *meaning* of the COMPOUND tag  remains unclear to me.  Do you mean
> this  tag wraps  around  anything  with is  not  a string  :  macro call  for
> instance, etc ?? For sure not, otherwise it would be redundant maker...

Yes, it should rarely be used. In fact it is only needed when the "name"
of the macro is itself the result of a computation. This can be useful if
a stylefile automatically generates macros (i.e. \newtheorem).

> And if, for example, I have to generate is from a program, what are the rules
> to respect ?..

As EXPAND and APPLY before. But if the name of the macro is
a known string, then you should not use it.

> Wanting to go further yesterday,  I checked throughout the automatic material
> generated in the cache/__blabla__ files,  but did not succeed in catching the
> precise idea.
>
> For instance, in the following example?
>
>  (compound
>    "theorem*"
>    (concat
>      (translate "Notation" "english" (language))
>      " "
>      (compound "thetheorem"))
>    (arg "body"))

This should now be

(theorem*
  (concat
    (translate ...)
    " "
    (thetheorem))
  (arg "body"))

It may be that some output routines still generate "compound"
even when this is not necessary.

> >   2) A consequence of 1) is that the scheme representation now
> >      perfectly matches the intern representation.
>
> That's really  nice.  A  problem I  met some months  ago.  Together  with the
> question of  how it  is possible to  know which  tags are so  called internal
> tags, from the  scheme side, *statically* : by which I  mean without asking a
> running TeXmacs about this property ?

You cannot; this information is still contained in the C++ code,
but it is quite transparent: see the drd_std.cpp file.

> In other words, is there a place where
> is set of primitives of exported to the knowledge of scheme scripts?

I don't understand this question. I guess that the answer is no.
I will deal later with better scheme integration.

> There remains  the question of how  do I compute  the path of a  subtree from
> outside the TeXmacs world? Is the algorithm trivial now?

Yes, exactly what one would do internally; Scheme and C++ now match.

> >   3) Drd properties can be associated to tags and exploited by
> >      the editor.
>
> I  checked the  related files,  and found  that a  lot of  various  pieces of
> information is  actually bound to tags  via DRD. We'll see  that point latter
> anyway.
>
> As a matter of example, one could point out the underline/overline macros
> which are associated properties with 'drd_props' in
> 'packages/standard/std-markup.ts'.

Yes. Nevertheless, all this is just starting and very incomplete.
I might also have to change the support for DRDs inside style files later.
My priority will rather be to simplify the existing code using the DRD.
My next priority is to provide scheme programmers with a clean interface
for modifying live documents.

> where hide_expand and the likes were examples in the ancient times ;)

Exactly. var_expand is not really supported anymore though,
but I could do that if someone really needs it.

> In  that sentence, I  see the  first property  has something  to do  with the
> interactive edition within  TeXmacs ; while the second  is a static property,
> providing some piece  of typing information somehow. I got  it, Joris ?

Yes.

> These two properties are really different from my point of view.

That is why I gave both of them. But they are unified in the context
of DRD's which is (or rather: will be, because the C++ drds do not yet
match with the scheme ones) merely some kind of logical programming.

> > Moreover, TeXmacs provides a high-quality and on-the-fly heuristic
> > algorithm in order to automatically determine missing DRD properties
> > merely from the definition of a macro. For example, if you write
> > a macro like
> >
> >     (assign "hi" (macro "name" (concat "Hi " (arg "name"))))
> >
> > then TeXmacs will automatically recognize that "hi" has arity 1
> > and that its only child is accessible. Nevertheless, if the user
> > explicitly sets the DRD properties of a tag in a style file,
> > then this will disable the heuristic determination of this property.
>
> Nice heuristics. I saw some generated results in the system cache files.

For normal macros it should mostly work (conditional macros with IF's
still have to be treated more intelligently). For xmacros (arbitrary
number of arguments) it should also work on simple cases, but in this
case the heuristics are more error-prone.

> > Little advantage is taken out of the DRD information right now,
> > but in future versions, we plan to further enrich it and
> > implement more reliable cursor movement, block structures,
> > structured editing facilities, etc.
>
> Which are certainly  required, at least for me... But  at this point, TeXmacs
> is  already provided  with a  huge amount  of possiblities.   Maybe  times to
> disseminate  these informations  and provide  examples  for the  sake of  the
> developpers (at least)?

If you understand how it works, then you may try to document it :^)