texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] problem using action inside a macro


From: david
Subject: Re: [Texmacs-dev] problem using action inside a macro
Date: Tue, 22 Apr 2003 14:32:06 +0200
User-agent: Mutt/1.5.3i

On Mon, Apr 21, 2003 at 08:47:52PM -0400, Leo wrote:
> Snippet 1:
> 
>    <assign|foo|<macro|text|xx|<action|<arg|text>|(write "say YES")>>>
> 
>    <foo|works fine|say YES>
>  
> 
> Snippet 2:
> 
>    <assign|bar|<macro|text|xx|<action|<arg|text>|(write "<arg|xx>")>>>
> 
>    <bar|does not work|say YES>

That is a subtle problem with how some texmacs primitives understand
parameters.

The primitive ACTION expects its first parameter to be a tree (that
is something which may contain elaborate structures) but its second
parameter to be a string (a tree containing only a string leaf). See
concat_active.cc line 195.

If you had used the Scheme format to copy-paste the snippets, the
difference would have been more obvious:

Snippet 1:

    (assign "foo" (macro "text" "xx"
      (action (arg "text") "(write \"say YES\")")))

Snippet 2:

    (assign "bar" (macro "text" "xx"
      (action (arg "text") (concat "(write \"" (arg "xx") "\")"))))

You see that in snippet 2, the second parameter is a concat, which is
evaluated (in env_exec.cc lines 175--183) into

    '(concat "(write\"" "say YES" "\")").

But "action" do not know what to do with this since it is not an
atomic tree.

The way to fix your problem is to use the MERGE primitive to build
your string from parts.

    (assign "bar" (macro "text" "xx"
      (action (arg "text") (merge "(write \""
                            (merge (arg "xx") "\")")))))

Also, it is bad to use a MACRO where one of the parameters is not
_accessible_. Backspacing into an expansion of the macro "bar", will
yield the Green Cursor Of Death because the logical position will be
inside parameter xx which has no corresponding visual position.

So, it is better to use a FUNCTION when one of the parameters is to be
hidden.

If you *really* want to preserve editability of the first parameter
and keep the second parameter inaccessible, you can use a MACRO, but
expand it with the (undocumented, experimental) primitive HIDE_EXPAND
instead of EXPAND. Currently, this primitive is used by the macros
"switch" and "fold"/"unfold". It behave exactly like EXPAND excepted
that its last parameter is specified not to be accessible. See tree.cc
lines 282-283 and 491.

--
                                                            -- DDAA




reply via email to

[Prev in Thread] Current Thread [Next in Thread]