bug#81223: [PATCH] Fix file-missing error during async native compilation

> Date: Mon, 10 Aug 2026 10:44:57 -0400
> Cc: [email protected], [email protected], [email protected],
>  [email protected]
> From: James Cherti <[email protected]>
> 
> Hello Eli and Sean,
> 
> This patch is ready on my end, so feel free to merge it.

As you wish.

> My commit message is not that long, and the code already includes
> explanatory comments. I have also added the bug number in the latest
> patch version.

I explained at length why there are still a few minor issues with your
latest patch, and why we are asking you and others to make such
changes.

> What I personally dislike is that the standards Sean asked
> me to follow are not applied equally to everyone and seem
> based on personal preference. (For example, there are many
> long git commit messages and several commits that do not
> adhere to the CONTRIBUTE file.)

The standards _are_ applied equally, when we have the chance to apply
them.  Please don't forget that many people have write access to the
repository, in which case we see the log messages after they are
already pushed.  Your conclusion is based on what's in the repository,
not on what we say as part of patch review.

> Manually enforcing a two-space rule or commit message length
> limits is tedious and consumes valuable review time for Sean
> and other maintainers. If these specific conventions are
> required, they should be handled automatically by a linter
> or formatter rather than human reviewers.

You can set up Emacs to do this for you, but we don't request that
everyone uses Emacs, nor that they set it up that way, because most of
their work could be in cultures other than US English.

> The way these small details are enforced right now is
> unfortunately inefficient and can cause friction.

Frankly, I'm surprised that such minor requests are met with such a
strong opposition, I don't think I've heard such objections from
anyone else in all the years I'm involved in Emacs development.

> I recommend enforcing these minor formatting details through
> a pre-commit hook and a server-side check.

Feel free to work on such a hook (TIA), but please keep in mind that
it has to be 110% free of false positives, otherwise people will
disable such a hook.  Otherwise, I'm not opposed to have such hooks,
but they cannot catch and flag all the potential minor issues we try
to observe in commit log messages, comments, and documentation.  For
example, we try to avoid passive tense in our documentation, something
that is not easy to automate.  And there are other similar aspects.