Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Stefan Monnier]

> +(defun project--kill-buffer-check (buf conditions)
> +  "Check if buffer BUF matches any element of the list CONDITIONS.
> +See `project-kill-buffer-conditions' for more details on the form
> +of CONDITIONS."
> +  (catch 'kill
> +    (dolist (c conditions)
> +      (when (cond
> +             ((stringp c)
> +              (string-match-p c (buffer-name buf)))
> +             ((symbolp c)
> +              (funcall c buf))
> +             ((eq (car-safe c) 'major-mode)
> +              (eq (buffer-local-value 'major-mode buf)
> +                  (cdr c)))
> +             ((eq (car-safe c) 'derived-mode)
> +              (provided-mode-derived-p
> +               (buffer-local-value 'major-mode buf)
> +               (cdr c)))
> +             ((eq (car-safe c) 'not)
> +              (not (project--kill-buffer-check buf (cdr c))))
> +             ((eq (car-safe c) 'or)
> +              (project--kill-buffer-check buf (cdr c)))
> +             ((eq (car-safe c) 'and)
> +              (seq-every-p
> +               (apply-partially #'project--kill-buffer-check
> +                                buf)
> +               (mapcar #'list (cdr c)))))
> +        (throw 'kill t)))))

Why do we need to invent a small language for that?


        Stefan

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Dmitry Gutov]

On 29.07.2020 02:10, Stefan Monnier wrote:
> Why do we need to invent a small language for that?

Check out the discussion in bug#42386.

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Stefan Monnier]

>> Why do we need to invent a small language for that?
> Check out the discussion in bug#42386.

In that case, could someone try and make this "set of buffers" work not
just for project-kill-buffers but also for all those other places where
we want a similar specification, such as `font-lock-global-modes`,
`desktop-buffers-not-to-save`, ... ?


        Stefan

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Philip K.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Why do we need to invent a small language for that?
>> Check out the discussion in bug#42386.
>
> In that case, could someone try and make this "set of buffers" work not
> just for project-kill-buffers but also for all those other places where
> we want a similar specification, such as `font-lock-global-modes`,
> `desktop-buffers-not-to-save`, ... ?

Sure, but wouldn't that mean that this functionality would have to be
published in it's own ELPA package or project.el would have to depend on
something like Emacs 27.2?

-- 
	Philip K.

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Stefan Monnier]

> Sure, but wouldn't that mean that this functionality would have to be
> published in it's own ELPA package or project.el would have to depend on
> something like Emacs 27.2?

That'd be a very secondary problem, to which we can easily imagine
various solutions, so that shouldn't stop us from doing the right thing.


        Stefan

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Philip K.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Sure, but wouldn't that mean that this functionality would have to be
>> published in it's own ELPA package or project.el would have to depend on
>> something like Emacs 27.2?
>
> That'd be a very secondary problem, to which we can easily imagine
> various solutions, so that shouldn't stop us from doing the right thing.

Of course, but the main problem seems to be to decide which solution to
pick. The code (project--kill-buffer-check and project--buffers-to-kill)
is already close-to generic enough to be easily moved around.

-- 
	Philip K.

Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions

[Stefan Monnier]

> Of course, but the main problem seems to be to decide which solution to
> pick.  The code (project--kill-buffer-check and project--buffers-to-kill)
> is already close-to generic enough to be easily moved around.

I think instead that the main problem is to make use of that code in
places which currently use another code, and deal with the corresponding
potential incompatibilities.

Once that's done, we can try and figure out where is the best place for
that generic code (if not project.el) and how to make it work for GNU
ELPA packages like project.el.  There are many different acceptable
options there (including keeping a backward-compatibility copy of that
generic code in project.el, or placing it into a separate GNU ELPA
package added as a new dependency, ...).
I think it'll be pretty easy to solve.


        Stefan