[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: |
Philippe Audebaud |
Subject: |
Re: [Texmacs-dev] (Important for scheme hackers) TeXmacs tags become more stable |
Date: |
Wed, 12 Nov 2003 16:25:38 +0100 |
User-agent: |
Mutt/1.5.4i |
On Wed, Nov 12, 2003 at 01:33:40PM +0100, Joris van der Hoeven wrote:
> I more or less completed a major reorganization whose object is to
Thanks a lot Joris for all these explanations.
Following the CVS entries already helped me *a lot* already. Nevertheless:
> 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...
And if, for example, I have to generate is from a program, what are the rules
to respect ?..
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"))
> 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 ? In other words, is there a place where
is set of primitives of exported to the knowledge of scheme scripts?
There remains the question of how do I compute the path of a subtree from
outside the TeXmacs world? Is the algorithm trivial now?
> 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'.
> So if you wrote some non-trivial scheme code for TeXmacs, then it is
> possible that you have to update some parts of it, especially if you used
> the APPLY tag.
There is a benefit for that, so that's ok!
> Fortunately, things should remain stable from now on though.
>
> Let me explain 3) a bit. TeXmacs DRD's (Data Relation Definitions)
> are meant to become an enrichment of usual DTD's with additional
> logical structure. Whereas a usual DTD would mainly formalize which
> documents are correct (i.e. arities of tags and maybe constraints
> of which tags should be or cannot be used inside other tags),
> the DRD also contains information like "the user is allowed to
> place the cursor inside the n-th child of this tag" or "this tag
> is a block structure".
where hide_expand and the likes were examples in the ancient times ;)
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 ? These
two properties are really different from my point of view.
> Because of the macro facility of TeXmacs, it should also be noticed
> that DTD's and DRD's have to be extremely flexible, since they
> basically change each time when the user adds a new macro.
> So TeXmacs has to provide a mechanism which both
>
> 1) Allows you to specify a very precise DTD/DRD which cannot
> be altered by the user (example: certain forms in industry).
> 2) Allows the DRD to be updated in a user friendly way when
> you define new macros or style files.
>
> The solution I found for this problem is the following:
> TeXmacs style files will both specify style and DRD properties.
> (Consequence: there will be no clear distinction between style files
> and DRD files in TeXmacs. A style file may only contain formatting
> instructions, or DRD instructions, or both.)
>
> 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.
> 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)?
> Have fun, Joris
I do.
--
Philippe Audebaud