[m-rev.] for post-commit review: make --output-compiler-error-lines a maybe_int option

[Peter Wang]

On Mon, 07 Aug 2023 10:50:32 +1000 "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> On 2023-08-07 02:40 +02:00 CEST, "Peter Wang" <novalazy at gmail.com> wrote:
> >>  @item --output-compile-error-lines @var{n}
> >> + at item --no-output-compile-error-lines
> >>  @findex --output-compile-error-lines
> >>  @findex --make
> >>  With @samp{--make}, output the first @var{n} lines of the @samp{.err}
> >>  file after compiling a module (default: 15).
> >> +Specifying --no-output-compile-error-lines removes the limit.
> > 
> > --no-output-compile-error-lines sounds like the opposite of what it
> > does, but that's okay.
> 
> There was already a problem with the name, in that the compiler
> output *usually* consists of error messages, but it can also include
> progress messages (with -v or -V) and inference messages.
> It also does not imply that it is a limit.
> 
> Would something --max-compiler-output-lines or --max-echoed-output-lines
> work better? They handle a --no in front much better.

Yes. Keep the old name as an alias.

> Another thought: should we specify --no-<whatever option name we end up with>
> in the test directories? It would make the bootcheck output in csharp and java
> grades more immediately useful, in that you could look up the diagnostics
> associated with a test failure in the bootcheck output file itself, without necessarily
> looking at the .err file.

Yes. I always set --output-compiler-error-lines to some huge number,
so I wouldn't mind if there was no limit by default either.

Peter