mailing-list for TeXmacs Users

["Corey Sweeney" <address@hidden>]

On 3/10/06, Henri Lesourd <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.

If I pass it as a value via <value|intro-text>, then the document that's being included is editable, but the passed paragraph is not editable in the document that's requesting the include.

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

> P.S.  Let me know if your gonna add something like that "> converter"
> to the texmacs scheme libraries.  Also let me know what char you'd
> use, so I don't have to go change my files when I start using it.
>
I will not add something like that "> converter" into TeXmacs, otherwise
Joris
would crucify me :-). To workaround this problem, it is much simpler to
store
the necessary hacks in your own my-init-texmacs.scm.

In fact, the appropriate solution is to improve the unquoting mechanism
in such a way that the appropriate conversion would be done inside
an <extern|...> : the current behaviour is clearly buggy.

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 :)

And of course I also agree that it is a horrible hack, {thus why i
named it "(define horrible-scheme-hack ..."}.  My objective was
not to add this to the specification as to how texmacs works, but to
use it as a temporary work around.  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.

I understand wanting to keep the insides clean.  And I understand
how joris is too ;) (about 15 months ago he gave me my code back to
refactor before inclusion in the distribution.  (i'm about half
way there :))   Keeping the code insanely clean is a
good  thing.  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"?  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. :)

Corey
-- 
((lambda (y) (y y)) (lambda (y) (y y)))