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

Previous Next

Full log

Message #23 received at 76587 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Visuwesh <visuweshm <at> gmail.com>
Cc: 76587 <at> debbugs.gnu.org
Subject: Re: bug#76587: 31.0.50; [FR] project.el should have a way to exclude
 certain projects from being saved
Date: Fri, 28 Feb 2025 03:17:34 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.