* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
[not found] ` <20200728222420.F3D25209DF@vcs0.savannah.gnu.org>
@ 2020-07-28 23:10 ` Stefan Monnier
2020-07-31 23:28 ` Dmitry Gutov
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-07-28 23:10 UTC (permalink / raw)
To: Philip K; +Cc: emacs-devel
> +(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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-07-28 23:10 ` master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions Stefan Monnier
@ 2020-07-31 23:28 ` Dmitry Gutov
2020-09-05 18:19 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Dmitry Gutov @ 2020-07-31 23:28 UTC (permalink / raw)
To: Stefan Monnier, Philip K; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-07-31 23:28 ` Dmitry Gutov
@ 2020-09-05 18:19 ` Stefan Monnier
2020-09-05 19:06 ` Philip K.
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-09-05 18:19 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: Philip K, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-09-05 18:19 ` Stefan Monnier
@ 2020-09-05 19:06 ` Philip K.
2020-09-05 19:39 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Philip K. @ 2020-09-05 19:06 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, dgutov
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-09-05 19:06 ` Philip K.
@ 2020-09-05 19:39 ` Stefan Monnier
2020-09-06 21:42 ` Philip K.
0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2020-09-05 19:39 UTC (permalink / raw)
To: Philip K.; +Cc: emacs-devel, dgutov
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-09-05 19:39 ` Stefan Monnier
@ 2020-09-06 21:42 ` Philip K.
2020-09-07 3:24 ` Stefan Monnier
0 siblings, 1 reply; 7+ messages in thread
From: Philip K. @ 2020-09-06 21:42 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel, dgutov
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions
2020-09-06 21:42 ` Philip K.
@ 2020-09-07 3:24 ` Stefan Monnier
0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2020-09-07 3:24 UTC (permalink / raw)
To: Philip K.; +Cc: emacs-devel, dgutov
> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-09-07 3:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20200728222419.2111.71622@vcs0.savannah.gnu.org>
[not found] ` <20200728222420.F3D25209DF@vcs0.savannah.gnu.org>
2020-07-28 23:10 ` master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions Stefan Monnier
2020-07-31 23:28 ` Dmitry Gutov
2020-09-05 18:19 ` Stefan Monnier
2020-09-05 19:06 ` Philip K.
2020-09-05 19:39 ` Stefan Monnier
2020-09-06 21:42 ` Philip K.
2020-09-07 3:24 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).