> Date: Thu, 21 Feb 2013 21:19:00 +0100
> From: Patrice Dumas <[email protected]>
>
> On Thu, Feb 21, 2013 at 09:41:51PM +0200, Eli Zaretskii wrote:
> > > Date: Thu, 21 Feb 2013 20:18:56 +0100
> > > From: Patrice Dumas <[email protected]>
> > >
> > > The first ambiguous construct is in fact
> > >
> > > @set x@c
> > >
> > > I am not sure how this should be interpreted? It may be considered
> > > 1. wrong
> > > 2. the same as
> > >
> > > @set x
> > >
> > > 3. the same as
> > >
> > > @set x @c
> >
> > Neither. It's #2, but the following newline should be removed from
> > output when the macro is expanded. Using @c for this purpose was a
> > popular trick with the old makeinfo.
>
> It is not a macro, it is a @value.
No, it is a macro that sets a variable that can be later recalled with
@value:
@macro xxx {one}@c
@set \one\@c
@end macro
@macro yyy {one, two}@c
@xxx{x\one\}@c
@ifclear x@c
\one\@w{}\two\@c
@end ifclear
@clear x\one\@c
@end macro
@macro trampfn {method, user, host, localname}@c
@value{prefix}@yyy{\method\,@value{postfixhop}}@yyy{\user\,@@}\host\@value{postfix}\localname\@c
@end macro
The important one is the last one: it needs to produce results like
this:
@file{@trampfn{smb, daniel%BIZARRE, melancholia, /daniel$$/.emacs}}
=> `/smb:daniel%BIZARRE@melancholia:/daniel$$/.emacs'
Without the @c parts, the result would be broken, like this:
`/smb:
daniel%BIZARRE@
melancholia:/daniel$$/.emacs'
> And I am not sure it is correct, as
> in
> '@set' and '@value'
> it is said, about @set:
>
> The value is the remainder of the input line, and can contain
> anything.
"Remainder of the line" arguably doesn't include the newline. But it
is pointless to argue about this, since using @c is how idiosyncrasies
of makeinfo macros and other constructs were worked around for ages.
> Taken literraly, it means that a @c on the line is to be part of the
> value.
But since pre-v5 makeinfo repeatedly expanded text until there was
nothing left to expand, the @c and everything after it, including the
newline, would then disappear without a trace.
> I can change the Parser code to remove wha tlooks like a comment
> from the value (trailing spaces are already removed), but then,
> maybe the manual should be modified?
Describing this in the manual is a good idea, IMO, and certainly
cannot hurt.
