bug#42386: Acknowledgement ([PATCH] Handle symbols in project-kill-buffers-ignores)

[Dmitry Gutov]

On 17.07.2020 20:16, Philip K. wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
>
> > On 17.07.2020 18:30, Philip K. wrote:
> > >    (defcustom project-kill-buffers-ignores
> > >      '("\\*Help\\*")
> >
> > You might as well update the default value.
>
> So what should be added, besides ERC?

Probably nothing, unless you have something else to propose.

At this point, you are the main driver of this feature. I like it in 
theory (a lot), but so far has done little to incorporate in my 
workflow, so you're the foremost person to hit the edge cases. I also 
don't do email/IRC/notes/etc in Emacs.

Speaking of some ideas, though, if you are worried about more unknown 
modes needing the same treatment, we could flip the meaning of this var 
and go with the whitelist approach, like font-lock-global-modes does. It 
can still serve as a blacklist if the first element is `not`.

To give an example:

(defcustom project-kill-buffers-conditions
  '(buffer-file-name ; All file-visiting buffers are included.
    (derived-mode . compilation-mode)
    ;; Most of the temp buffers in the background:
    (major-mode . fundamental-mode)
    ;; A bit questionable (alternatively, include
    ;; xref--xref-buffer-mode, occur-mode,
    ;; vc-dir-mode, log-view-mode, log-edit-mode separately):
    (derived-mode . special-mode))
  "Conditions for buffers `project-kill-buffers' should kill.
Each condition is either a regular expression matching a buffer
name, or a predicate function that takes a buffer object as
argument and returns non-nil if it matches, or a cons cell which <...>.

Buffers that belong to the current project, and match any of the
conditions, will be killed.  If the list starts with `not',
the meaning is negated."
  :type '(repeat (choice regexp function))
  :version "28.1"
  :package-version '(project . "0.6.0"))

If this kind of list can be exhaustive enough, this can be a decent default.

What do you think? If you're not sure, let's go with your patch now.

> > Or I wonder if you should just use memq in the implementation.
>
> I tried to find out what major-mode hierarchies exist on my system, so I
> wrote
>
>          (let (tree)
>            (dolist (f features)
>              (require f))
>            (mapatoms
>             (lambda (a)
>               (let ((p (get a 'derived-mode-parent)))
>                 (when p
>                   (push (cons p a)
>                         tree)))))
>            (with-temp-buffer
>              (insert "digraph {\n")
>              (dolist (node tree)
>                (insert (format "\"%s\" -> \"%s\";\n" (car node) (cdr node))))
>              (insert "}\n")
>              (write-file "dep.dot")
>              (shell-command "dot -Tpng dep.dot > dep.png")
>              (delete-file "dep.dot")))
>
> that generated an image of a tree. It seems it's mostly flat, meaning
> that a majority of the major modes are based on prog-mode, text-mode or
> special-mode. All further levels seem to be connected, such as with
> magit or gnus. So while I get that someone might not find it intuitive
> that major modes other than the one listed are not killed, I think a
> generous interpretation is better than killing more than one might want.

Fair enough. Or we could provide both kinds of checks, like in the 
example above (major-mode vs derived-mode).

> > Both font-lock-global-modes and desktop-modes-not-to-save are not
> > applied to derivatives.
>
> Hmm, I didn't know about that. As explained, just from looking at my
> system, taking derivations into consideration appears to have more
> advantages than disadvantages, but I'm not dogmatic on that point.

I don't know which is the best approach either.