[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] (Important for scheme hackers) TeXmacs tags become mor
From: |
Joris van der Hoeven |
Subject: |
Re: [Texmacs-dev] (Important for scheme hackers) TeXmacs tags become more stable |
Date: |
Wed, 12 Nov 2003 16:45:16 +0100 (CET) |
> > 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 :^)