[m-rev.] for review: record_all_arguments

[Julien Fischer]

On Wed, 17 Dec 2025 at 13:00, Zoltan Somogyi <zoltan.somogyi at runbox.com>
wrote:

>
>
> On Tue, 16 Dec 2025 23:37:04 +1100, Julien Fischer <jfischer at opturion.com>
> wrote:
> > On Tue, 16 Dec 2025 at 18:06, Zoltan Somogyi <zoltan.somogyi at runbox.com>
> > wrote:
> >
> > > For review by anyone. The diff does not include the
> automatically-updated
> > > getopt.m.
> > >
> > > I would like feedback on
> > >
> > > - whether we should change the argument order of record_arguments
> > >   to match the new record_all_arguments (I think we should, since it
> was
> > >   added after the last release), and
> > >
> >
> > Yes.
>
> Except that I was basing "it was added after the last release" on the
> mistaken
> belief that the entry for that library module that I modified was from
> after
> the last release. I now know that it was from *before* the last release.
> Is your answer still yes?
>

Yes.

> - whether we should use the new functionality to let mmc continue
> > >   doing its job in the presence of bad options.
> > >
> >
> > What do you mean by "continue doing its job"?  Presumably, we still
> > stop at some point and complain about the bad options?
>
> I mean doing the same job as if the bad option was not there, *except*
> for printing a diagnostic about that bad option.
>

That's potentially a problem if some of those bad options were meant to
be setting up things that the rest of compilation requires to be  error
free.
(I'm thinking particularly of options that control the target language
compilation environment here.)
Your diagnostic about the bad option may get swamped by other error
messages.


> > (Perhaps we should move the 22.01 news into the HISTORY file now, rather
> > than waiting until just before the creation of the next release branch?)
>
> It would definitely eliminate the chance of mistakes like this. I also do
> not see
> what benefit we get from having the news for the last release in that file.
>

At the time we release a stable version, there is a small benefit to
having the news for the latest release in the NEWS file because it is easily
found.  (At that point, however, there is unlikely to be any post-release
news.)

I think the main obstacle of moving that section to the HISTORY file is that
> HISTORY contains plain text, and not markdown.


The HISTORY file already contains a mixture of markdown, sort-of-markdown
and non-markdown.  At the end of the day, markdown *is* plain text, so I
don't
see it as that much of a problem.


> I would guess that everyone
> would agree with the propositions that
>
> - there is no point in converting the existing contents of HISTORY to use
> markdown, and
>

I wouldn't say there's no point, it's just a really low priority item.

- we do not want to mix plain text and markdown text in the same file.
>

Too late!


> I therefore propose that we move te 22.01.* news to a new HISTORY.md file,
> with a note at the end saying that the history continues in the plain
> HISTORY file.
> Or maybe we could name the two files HISTORY_SINCE_2022.md and
> HISTORY_BEFORE_2022.
>

I am fine with just adding the old entries to the HISTORY file.  There's
already too
many documentation-type files floating about at the top-level of the source
tree.

Julien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20251217/19eab731/attachment.html>