bug#76587: 31.0.50; [FR] project.el should have a way to exclude certain projects from being saved

[Dmitry Gutov]

On 27/02/2025 06:04, Visuwesh wrote:

> > This sounds reasonable. Should we call it something like
> > project-list-exclude[-regexps]?
>
> Sounds good to me.

Great.

> There are no repositories here to speak of.  I use this project backend
> when there is no associated vc backend with the file I'm visiting (i.e.,
> project-vc fails).  To make my example more concrete, consider the
> following example of find-sibling-rules:
>
>      '(find-sibling-rules
>         (rx-let ((basename (group (1+ (not ?/)))))
>            ;; Supplementary info.
>           `((,(rx "papers/" basename ".pdf" eos)
>              "papers/\\1_si_*.pdf" "papers/\\1_si.pdf")
>             (,(rx "papers/" basename "_si" (? "_" (+ num)) ".pdf" eos)
>              "papers/\\1.pdf"))))
>
> With this rule in place, when I say M-x find-sibling-file when I'm
> visiting ~/doc/.../papers/X.pdf, it visits ~/doc/.../papers/X_si.pdf for
> me.  With my sibling-file backend (see at end), I can say M-x
> project-list-buffers, or C-x p b, or C-x p f to switch to related files
> easily.  I was thinking of writing a project-specific C-x <right>/<left>
> commands to switch between project buffers easily.

Sounds helpful.

> > > I could use
> > > find-sibling-file but using project.el comes with bonuses like
> > > project-list-buffer, etc.
> >
> >  From where I'm standing, it might be more ergonomical to add a few
> > extra commands for the "siblings" search, and bind them to a
> > submap. But I'm probably missing something.
>
> I think we have different notions of a "project."  I see it as a list of
> related files, but the current project backend is built upon a singular,
> exact definition of a root directory inside which all files can be
> found.  For my use case, this root directory is a bit hard to define
> since the sibling file need not be restricted to be under the same
> directory (see an example of such a rule in the docstring of
> find-sibling-rules).  Perhaps, my idea of a project is most closest to
> what the satchel package does.

That's not a problem, as long as the fileset doesn't intersect with a VC 
repository.

But I'm guessing the problem is that there is no meaningful "root" for 
those files either, and so showing those projects in the project history 
is not that easy, even if one wanted (i.e. you can't go from the root to 
the file list, only in the reverse direction).

> I could definitely add yet another submap to my config but I would like
> to merge "regular" project.el projects, and my personal
> "transient-but-a-bit-more-defined" projects into a single one.  This
> elevates the pain of having to remember two different sets of commands.

If you're always inside just one kind of project at a time, that indeed 
shouldn't be necessary.

> All this complexity arises because I don't/can't use Git (or other VC)
> for most of my files.  (Emacs' backup and vc-backup does everything I
> need.)
>
>
>
>
> Here's the promised implementation:

Nice.