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

James Cherti <[email protected]> Fri, 7 Aug 2026 10:41:21 -0400
Newsgroups gmane.emacs.bugs
Message-ID <[email protected]>
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/>>
>      >
>      >
>      >
>