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

Even I can still be verbose after a couple of years of steady
contributions.  If I'd received comments to that expansive commit message,
I'd have made requested changes.  In that commit's case, it was pushed by
Yuan, not a core maintainer, but the maintainer of treesit.  The core
maintainers surely dislike that commit.

On Fri, Aug 7, 2026 at 10:41 AM James Cherti <[email protected]>
wrote:

> Hello Stephane,
>
> I am not against comments. I remember in one of my first
> contributions, Eli Z. modified my commit message himself,
> merged it, and then told me that he recommended writing
> commit messages similar to those of other Emacs
> contributors.
>
> I prefer this practice over nitpicking small details and
> making addressing them a condition for merging.
>
> By the way, it looks like this "convention" that you do not
> consider nitpicking does not apply to you (there are several
> other long commits by other maintainers and contributors):
> --8<---------------cut here---------------start------------->8---
> commit 060451d6e0b3c91882c62ae1a574125c1f448487
> Author: Stéphane Marks <[email protected]>
> Date:   2026-04-30 15:34:23 -0400
>
>      treesit-explore-mode usability improvements (bug#80935)
>
>      Improve the usability of treesit-explore-mode.
>
>      - Prompt for the primary parser first, if there is one, rather
>      than the first in the list reported by 'treesit-parser-list'.
>      Previously, in a multi-parser buffer like 'markdown-ts-mode', one
>      had to hunt for the primary parser.
>
>      - Kill the tree buffer and its window if the source buffer is
>      killed or 'treesit-explore-mode'.  Previously, when
>      'treesit-explore-mode' is disabled in the source buffer, its
>      companion explorer tree buffer was left dangling and window
>      open (with an unrelated buffer).
>
>      - Improve 'treesit--explorer-refresh-1' to recenter the window
>      around the selected nodes when the selected region in the source
>      buffer changes.  Previously, one had to navigate manually to find
>      the corresponding highlighted node in the tree window which may
>      be far away from that the source buffer's region represents.
>
>      - Disable 'treesit-explore-mode' in the source buffer if its
>      companion tree buffer is killed.  Previously,
>      'treesit-explore-mode' remained active in the source buffer in
>      an effectively unusable state.
>
>      - Disable 'treesit-explore-mode' if the user quits
>      'completing-read' in 'treesit-explorer-switch-parser' when
>      enabling the mode.  Previously, 'treesit-explore-mode' was left
>      enabled after quit.
>
>      - New command to switch back and forth between the source buffer
>      and tree buffer windows to make navigating more convenient.
>      Previously, in a multi-window frame, one had to navigate to/from
>      these two related windows in a more cumbersome way.
>
>      - New command to quit 'treesit-explore-mode' and
>      'treesit--explorer-tree-mode' and handle buffer and window
>      cleanup.
>
>      * lisp/treesit.el (treesit--explorer-refresh-1): Recenter the
>      window, if amenable, to the node selected in the source buffer.
>      (treesit--explorer-kill-explorer-buffer): Remove function.
>      (treesit--explorer-generate-parser-alist): Prioritize the
>      primary parser, if there is one.
>      (treesit--explorer-tree-mode-cleanup): New defun.
>      (treesit-explore-quit): New command.
>      (treesit-explorer-tree-window): New defun.
>      (treesit-explorer-source-buffer-window): New defun.
>      (treesit-explore-mode-map): Revise key bindings.
>      (treesit--explorer-tree-mode-map): Revise key bindings.
>      (treesit--explorer-tree-mode): New keymap.
>      (treesit-explorer-switch-parser): Add a default to
>      completing-read.
>      (treesit-explore-mode): Guard completing read quit.  Wire up the
>      new cleanup functions.
> --8<---------------cut here---------------start------------->8---
>
> --
> James Cherti
> GitHub: https://github.com/jamescherti
> Website: https://www.jamescherti.com/
>
> On 2026-08-07 10:25, Stéphane Marks wrote:
> > I think of it more as tips to condition my muscle memory to hew closer
> > to accepted conventions.  That said, what makes you think that the
> > maintainers do not provide input, perhaps privately, to those who have
> > commit rights and can use said input to improve their commits?
> >
> > On Fri, Aug 7, 2026 at 10:20 AM James Cherti <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     I checked the Emacs git log, and many recent commit messages
> >     are quite long (including those written by the maintainers
> >     themselves). What is the actual standard here? A standard
> >     should apply to everyone equally.
> >
> >     While standards and conventions are important, excessive
> >     criticism can make contributors hesitate to submit patches.
> >
> >     This feels like nitpicking.
> >
> >     --
> >     James Cherti
> >     GitHub: https://github.com/jamescherti <
> https://github.com/jamescherti>
> >     Website: https://www.jamescherti.com/ <https://www.jamescherti.com/>
> >
> >     On 2026-08-07 09:56, Stéphane Marks wrote:
> >      > As a community, we should value maintainer input and attention to
> >     detail
> >      > for the conventions that make it easier to perform a maintainer's
> >     job.
> >      > When each of us regular contributors triages a potential issue,
> >     we also
> >      > benefit.  This isn't a hobgoblin of little minds consistency,
> >     this is
> >      > thoughtful consistency.
> >      >
> >      > On Fri, Aug 7, 2026 at 9:48 AM James Cherti
> >     <[email protected] <mailto:[email protected]>
> >      > <mailto:[email protected]
> >     <mailto:[email protected]>>> wrote:
> >      >
> >      >     Hello Sean and Phillip,
> >      >
> >      >     Please don't make it difficult to contribute to Emacs.
> >      >
> >      >     I would appreciate it if we focused on the core changes
> >      >     rather than nitpicking.
> >      >
> >      >     The latest patch already includes comments that are clear
> >      >     enough and is ready to be merged.
> >      >
> >      >     On 2026-08-07 06:45, Sean Whitton wrote:
> >      >      > James Cherti [06/Aug  7:20pm -04] wrote:
> >      >      >> Subject: [PATCH] Fix file-missing error during async
> native
> >      >     compilation (bug#81223)
> >      >      >>
> >      >      >> The async native compilation queue can sometimes retain
> stale
> >      >     jobs for
> >      >      >> files that no longer exist on disk (for example, when
> >     files are
> >      >     removed
> >      >      >> during a package upgrade or deletion). Attempting to
> >     resolve the
> >      >     target
> >      >      >> .eln filename for these missing files signals a file-
> >     missing error.
> >      >      >
> >      >      > Please remove this or move it into comments.  We prefer
> >     not to have
> >      >      > extensive commentary in commit messages, see CONTRIBUTE.
> >      >      >
> >      >      >> * lisp/emacs-lisp/comp-run.el (comp--run-async-workers):
> >     Verify
> >      >     source
> >      >      >> files exist before attempting to resolve their .eln paths
> >     in the
> >      >      >> dispatch loop. In the process sentinel, wrap the
> compilation
> >      >     block in a
> >      >      >> condition-case to catch file-missing errors and prevent
> the
> >      >     async worker
> >      >      >> queue from stalling.
> >      >      >
> >      >      > Possibly this could be made shorter too, but it's less
> >     important.
> >      >      >
> >      >
> >      >     --
> >      >     James Cherti
> >      >     GitHub: https://github.com/jamescherti <https://github.com/
> >     jamescherti> <https://github.com/jamescherti <https://github.com/
> >     jamescherti>>
> >      >     Website: https://www.jamescherti.com/ <https://
> >     www.jamescherti.com/> <https://www.jamescherti.com/ <https://
> >     www.jamescherti.com/>>
> >      >
> >      >
> >      >
> >
>
>