Re: -x repetition, initialization

[Sergey Poznyakoff]

Hi Karl,

> > Each subsequent occurrence of [-x] increases the debugging output 
> > verbosity> I dislike this kind of formulation, because it makes it 
> > impossible for
> users to know how to get "everything".

Well, yes, that's a good point!

> It looks like the maximum number
> of -x's currently used is two, right?  So I'd rather just say that that
> (or something) is the max.

Yes, currently it is 2, but I will certainly add more granularity.

> Alternatively, I rather suspect that anyone who cares enough to get
> debugging info at all would want to get everything.

Oh no, I definitely cannot agree with that.  The idea behind a
"debugging level" is that the bigger (numerically) the level is,
the more detailed debugging info is output.  Notice, that it is useful
not only when debugging the program.  It is also of much use for anyone
who is trying to understand the behavior of the program when it, for some
reason or other, does not meet exactly his expectations.  Whatever the
reason for enabling the verbose debugging is, setting it to the highest
possible level is always a big mistake, because the amount of data
output in that case not only does not help to clarify the problem, but
on the contrary, it often further obscures it -- one does not see the
wood behind the trees.

In contrast, abridging the amount of output information can help
immensely in solving the problem.  In other words, lack of debugging
info does not help, but neither does its excess.  What's necessary is
the "aurea mediocritas".

Of course, all possible levels of debugging should be clearly documented
(and thanks for pointing out that they are not), and the simple
incremental command line option is not convenient enough and should
therefore be changed to something more manageable.

In my other projects I use two approaches.  If the program is
comparatively simple and a single numeric level is enough to control the
verbosity of its debugging output, then a command line option with a
numeric argument is provided, e.g. -x N.  Quite often that argument is
optional, meaning that giving just -x without it would enable the basic
(very terse perhaps) debugging output.

In the complex cases, the debugging info is split into "categories",
each of them having its own debugging level, so that one can trace
the behavior of each logical part of the program separately.  An example
of it can be found here:

  http://mailutils.org/wiki/Debug_level

When introducing the debugging output for Info, I thought that the
latter method would rather be an overkill, so I implemented the
former.

> > Unless the window system is initialized, debugging output goes to the
> > standard error.  When it is initialized, it is diverted to the file
> > @file{infodebug} in the current working directory.
> 
> I'm afraid I don't understand the idea here.  I mean, I can see that
> info_windows_initialized_p is being set in initialize_info_session,

Unfortunately, I failed to explain it properly.  Thanks for pointing
that out.  By the "window system" I meant, of course, the full-screen
mode of the Info itself, rather that any external windowing system.  The
idea behind this is simple:

When info starts up, it performs a set of preparative operations before
starting the curses library and going full-screen.  If any of these
operations fails, it prints the diagnostics on the stderr and
termintates.  Therefore, it seems quite logical to do the same with the
debugging output, i.e. to output it where it will immediately be seen.

On the other hand, after having initialized the curses library and
opened the requested document in a terminal window, info can no longer
use stderr, be it for error or debugging output, because in doing so it
will spoil the carefully maintained display and mix the debugging info
with the actual document displayed on the screen.  In this case, the
error output goes to the echo area, where it can easily be distinguished
from the document itself.  However, info cannot do the same with the
debugging output and that's for two reasons: first, it is too copious
for that, and secondly, it is often intended for a careful analysis
after the program is terminated.  Therefore it is quite logical to
divert all debugging output to a separate file.

Notice, that this reasoning does not entirely apply to the debugging
info issued prior to initialization of ncurses, because it is neither
copious, nor reasonably suitable for a post-mortem analysis: if the
program fails before going to the full-screen mode, both error messages
and debugging output preceding it would remain on the screen, which is
extremely helpful in diagnosing the cause of the failure.

Regards,
Sergey