mailing-list for TeXmacs Users

[Henri Lesourd <address@hidden>]

Corey Sweeney wrote:

> On 3/10/06, Henri Lesourd <address@hidden <mailto:address@hidden>> wrote:
>
>     Corey Sweeney wrote:
>
>     > quick note: I found my "arg" problem was that i *had* to enter args
>     > via the toolbar, and could not type \arg{enter}intro
>     >
>     >
>     > I got a chance to try this:
>     >
>     >
>     
> <assign|include-with-intro-x|<macro|filename|intro-text|<with|intro|<arg|intro-text>|<extern|(lambda
>     > (x) (tree-load-inclusion ((eval-string (string-append "tree-"
>     (substring
>     > "\<gtr\>" 4 5) "stree")) x)))|<arg|filename>>>>>
>     >
>     > <include-with-intro-x|queries.tm|this is my introductary text>
>     >
>     > This works on loading the include, and does properly display the
>     "this
>     > is my introductary text" in the middle of the document.  (which is
>     > just a "<value|intro-text>" in the document).  So much progress has
>     > been made.  However when I try to place the cursor inside "this
>     is my
>     > introductary text" to edit it (inside the embedded document that is
>     > now displaying), it won't edit.  It would edit when i made
>     macros for
>     > my web page.   Made a macro that would add borders, and you were
>     > automatically able to type on the inside, in a wysiwyg manner.
>     >
>     As soon as you use <value|...> the editability is lost.
>     Editability is only maintained for <arg|...> objects.
>
>
> I see.  If i pass it as a arg by using macro, then passed paragraph 
> will be editable in the document that requests the other document to 
> be included.  However the document that's being included will not be 
> editable, as it's now a macro.

The document that's being included is not editable not because it is part
of a macro (because inside a macro, you can precisely turn parts to being
editable using <arg>), but because it is part of <include>. On the other
hand, even in the context of only one document, the tags 
<value|variable-name>
do not allow for direct editing of the variable value.

> If I pass it as a value via <value|intro-text>, then the document 
> that's being included is editable,

No, its not : as soon as you use <include> or any of its derivatives 
(like the
one I wrote in Scheme), the included text is *not* editable any more.

> So It's basically one or the other.  Are there any other methods to 
> pass that would allow the editing from both sides?

It *should* be possible to write a Scheme macro that opens the included
file and replaces all the occurences of <value|...> by occurences of the
corresponding <arg> that happens to be a parameter of the macro.

You would have something like that :
[[
  <assign|inc1|<macro|file|text|<extern|scm-inc1|<arg|file>|<arg|text>>>
]]

and then :
[[
  (tm-define (scm-inc1 file text)
     (:type (tree -> tree))
     (:secure #t)
     (with data (tree-load-inclusion file)
        {{ Replace all the occurences of "<value|text>"
           by "<arg|text>" inside data
        }}
        data)
  )
]]

This one should work, although it relies on the naming
of the macro's parameter. Namely, inside the Scheme code,
there is no way for me to know the names of the parameters
of the calling macro : I only get their values. Nevertheless,
if I generate a tree containing an <arg|NAME> with the appropriate
NAME (in the current exemple, NAME==text), then I'm generating
an editable box for the macro parameter called NAME. The problem
is : the name NAME is to be hardcoded inside the Scheme code,
because I cannot get it from the TeXmacs macro interpreter.

But this solution should work.

>     Inside TeXmacs, we should for instance definitely be able to write :
>     <extern|(lambda (x) (string->tree x))|<arg|x>> without any problems.
>
>
> I totally agree, that would be the best way.  I also know I'm not 
> going to hold my breath waiting for that to become a priority enough 
> to happen :)

As soon as it has been discussed once, the probability of an increase in
the priority level increases, the mails in the mailing list being re-readed
at some point (although not very regularly).

> However if I define it in my personsonal my-init-texmacs.scm file, 
> then I loose the ability to trade documents with normal people.  Also 
> whenever I switch to a new computer, it's always confusing to keep 
> track of all the changes I have made.

One could perhaps find a way to store Scheme functions inside a
stylesheet (a .ts file). Thus you would need to send your .tm file
with the corresponding stylesheet. This is not perfect, but it is
much more natural for people than having to change their 
my-init-texmacs.scm.

> However could it be added and flaged as "this is not part of the 
> *real* system, but just a horrible hack, that we will remove someday 
> when we fix the real problem"?

If it is an horrible hack that people will **use** (like it would as 
amatter of fact become
the case with the macro for turning "}" into ">"), then whether you like 
it or not, it
becomes de facto part of the real system (i.e., when you remove the 
hack, the old documents
will not work anymore).

>   The only real reason I can see against doing this is a psycological 
> one, in that if you start letting temporary ones in, psycological 
> slippage may occur and permanant hacks may start getting accepted.
>
> I guess that's most everything I have to say on the subject, so I'm 
> planning this to be my last attempt at convincing that making this 
> accessable to everyone would be a good thing. :)

There is a need for being able to implement workarounds that one can
use *right now* (versus waiting a possibly unbounded amount of time
for the appropriate feature to be added to TeXmacs), and that in the
same time, these workarounds remain completely separated from the standard
system. From this it follows that such workarounds must be managed by
the user in a completely independent way. What TeXmacs *really* should
be provide to you is a good, reliable & convenient way to implement your
workarounds (I mean : more generally, a good & reliable way for implementing
things in TeXmacs --that were not foreseen-- by the developers : after all,
whether is is workarounds for bugs or implementing stuff for new 
applications,
this is the same problem. What is needed for this is a good API of low-level
functions that one can use for doing everything (i.e., an API with no "blind
spots", things that cannot be done with it) : in this respect, things 
clearly
improved over the last versions of TeXmacs).

Then we have a problem to send documents that use our hacks to other 
people. As far
as I can see, the missing feature here would rather be a more convenient 
way to embed
specific macros & Scheme code inside a particular document.

Or is there something I forgot ?