bug-texinfo
[Top][All Lists]
Advanced

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

Re: [bug #43122] texi2dvi does not compile enough times to get toc


From: Gavin Smith
Subject: Re: [bug #43122] texi2dvi does not compile enough times to get toc
Date: Wed, 9 Sep 2015 01:14:56 +0100

On 4 September 2015 at 00:53, Karl Berry <address@hidden> wrote:
>     gs> Remove env var from help message - there should be no need for the
>     gs> user to think about this.
>     ...
>     vb> Anyway, let us give Karl the final word about that...
>
> 0) I don't know what the current state is, since changes are apparently
> not committed yet.
>
> 1) I'm not sure that it's up to me.
>
> 2) I already expressed my opinion to Gavin that it is worth mentioning
> the envvar in the help message.  I see nothing to be gained by keeping
> it "secret".  In my experience, points like this can cause a lot of
> unnecessary frustration when the available options are not documented
> and, for whatever reason, the default behavior is not working right.
> Which is not unlikely with complicated scenarios such as just have been
> introduced.

I can't say I understand or agree. If it doesn't work, that's a bug in
texi2dvi which has to be fixed. It's not a user option, it's an option
for debugging texi2dvi. If someone discovers this causes a bug then
the envvar is useful for debugging.

Would you be happy if it was documented in the manual, but not in the
help message? I think the help message is too long, anyway.
Documenting it in the manual wouldn't get in the way as much. That's
the problem with extra options, the user wastes time reading about
them when they were interested in something else.

Another problem is maintenance and stability. It's another thing that
someone can rely on. An environment variable is easily ignored,
though.

Vincent mentioned the problem of the efficiency of running the test
for --recorder every time. I don't think it's a problem: if it led to
a noticeable slowdown (maybe tenth of a second or so) that would be a
problem. There could be other ways to improve efficiency though. I
don't like the idea of adding lots of knobs to tweak performance and
internal implementation, when it should be good by default.

Once again, I'd be happy enough to put it in the manual if others see
a need for it.



reply via email to

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