[Top][All Lists]

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

Re: [Groff] Strange error messages from Groff 1.22.3

From: Eli Zaretskii
Subject: Re: [Groff] Strange error messages from Groff 1.22.3
Date: Tue, 11 Nov 2014 22:24:03 +0200

> cc: address@hidden
> Date: Tue, 11 Nov 2014 19:20:19 +0000
> From: Ralph Corderoy <address@hidden>
> > > and so wrappers around the code that's cooking up the a\b\c in the
> > > first place could transliterate there without caring where the a/b/c
> > > is later to be used?
> > 
> > The problem with this approach is that these file names are not cooked
> > by Groff code, they come from the command-line arguments typed by the
> > user, see above.  And AFAIK the (very cool, IMO) feature of
> > controlling how the user types the command line is not yet in Groff
> > ;-).
> Hmm, does that mean the argv[] processing in groff's code is a place to
> transliterate when it's known to be a filename?

Yes.  But the problem is (a) we don't know argv[i] is a file name
until it is passed to do_file, and (b) in some cases do_file is not
called with argv[i] as an argument.

So I've chosen to do this in do_file, where it is certain we are
dealing with a file name.  Also, since the normalization incurs some
overhead, I only do that when the file name is used in the .lf

> I'm just wondering if .lf won't end up being the only place that
> matters and so changing it on input rather than output might be
> better, if that's identifiable.

I don't know Groff well enough to tell.  You here are the experts, so
if there are other places where file names are emitted in directives,
please point them out.  Most probably, they will need the same
treatment, yes.

reply via email to

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