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

[Leo Razoumov]

David,
thank you for your  reply but, apparently, your solution 
does NOT work!!

It seems that "merge" does not work inside the action's second
argument. Try the following simple example

(action "print me"
  (merge "(write \"print me\")" ""))


In my case (TeXmacs-1.0.1, RHL-8.0) action produces no output whatsoever.

Thanks,
--Leo--


On Tuesday April 22 2003 08:32, address@hidden wrote:
> 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.