On Mon, 20 Mar 2000, Werner LEMBERG wrote:
> > As for adding this feature, what syntax would you suggest for that?
> > There's a problem with @defXXX in that their syntax is against the
> > normal Texinfo rules, so adding something is not easy. But given
> > the right syntax, the change in the internals should be simple.
>
> What about
>
> @defcodeindex ma
> @associateindex defmac ma
>
> at the beginning of the file? This makes @defmac emitting index
> entries for the `ma' index.
Hmm, this will probably be not hard to add to makeinfo. But what
about texinfo.tex? Karl, could you comment?
> > Please describe in more detail what would you like to control,
> > exactly.
>
> Sorry for being imprecise. If I e.g. say
>
> @deffn Escape \w string
>
> I would like to see the following line in the info file:
>
> - Escape: \w'STRING'
>
> Maybe a new request @deffndelim could be added:
>
> @deffn <category> <name> <delim1> <arg1> <delim2> <arg2> ...
>
> example:
>
> @deffn Escape \w ' string '
I probably miss some important aspect of this, because I cannot figure
out why do you need to say "string" and get it converted to "'STRING'"
in the Info output. (I am only a casual user of Groff, and I never
wrote any docs for it, so I might have some catching up to do ;-).
> BTW, I couldn't find a remark in texinfo info file that some character
> s like `(' and `[' are handled specially in the @defXXX commands --
> you have to deduce that from the examples. I'm missing the info that
> everything after those characters is printed in tt, and that you have
> explicitly use e.g. @var{} to override it.
I don't see any special treatment in makeinfo. Karl, is this specific
to texinfo.tex?
And you are right: the manual seems to keep silence about how these
look like in print.
> > Doesn't the following work (I didn't try)?
> >
> > @deffn @t{\#} ...
>
> Yes, but doing this always is tedious.
>
> What about a new command
>
> @defnamestyle @t
>
> (with the default set to @b) to handle that in a general way?
The problem is that @deffn and friends may have many words on that
line, and you probably don't want all of them be printed in tt.
Defining a @defnamestyle for all of the possibilities is going to be
painful.
If you need to use @t{} on every @deffn line, perhaps using a macro
could make this less tedious?
> > > @node Invoking groff [Invoking @code{groff}]
> >
> > You should be able to achieve this with a @anchor, if you put it
> > directly after the @node line. @anchor doesn't suffer from the
> > problem with @-commands (I think; again, I didn't check this right
> > now).
>
> Hmm, tedious...
Again, a macro could help.
> > > @ref could be then used as usual: @ref{Invoking groff}, but
> > > the printed version would typeset the word `groff' in the
> > > @code font.
> >
> > Part of the reason for discouraging use of @-commands in node names
> > (and disallowing them altogether in rare cases) is that they make a
> > mess in sorting out cross-references. So your suggestion doesn't
> > solve the real problem behind this.
>
> Please explain in more detail. I can't see a problem if you provide
> two arguments; the first is the node name used for sorting also, and
> the second is the representation for printing.
If you meant to maintain the second argument only for printing, then
it probably will work, but I don't know whether TeX can support this.
Karl?
In any case, the second version of the node name cannot be on the same
@node line, it should be a separate command, something like this:
@node Invoking groff
@nodename Invoking @code{groff}
> > but perhaps the syntax should be simply something like this:
> >
> > @findex{@strong, foo}
> >
> > This would allow to have the pages italicized etc., not only
> > emphasized.
>
> This sounds excellent.
The implementation of this is again mainly a TeX issue, so Karl will
have to comment on this. Makeinfo will need simply to skip the first
argument.
> > By default? I'm not sure: this would revoke the author's control on
> > where does the main reference point.
>
> Well, then we need another set of @defXXX macros (maybe @DefXXX) which
> either don't emit an index entry at all -- this might be a good idea
> anyway and would partially solve my indexing problem at the cost of
> some additional work -- or which would use your proposed
> @findex{@strong, foo} command.
Yes, either one would do.