GNU logs - #58839, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 12:58:01 +0000
Resent-Message-ID: <handler.58839.B.166696183425764 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 58839 <at> debbugs.gnu.org
From: Philip Kaludercic <philipk@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Fri, 28 Oct 2022 12:56:52 +0000
Message-ID: <87sfj8umwb.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@HIDDEN;
 helo=mout02.posteo.de
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)


When wanting to clean up behind a project I like to use C-x p k to get
rid of everything I have opened related to it.  If I was using Eglot and
there is still an active LSP server running in the background, killing
the project fails with these messages:

--8<---------------cut here---------------start------------->8---
Kill 7 buffers in ~/Source/sgo/? (y or n) y
[eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup
)
[eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup
)
[eglot] error sending textDocument/didClose: (error Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup
)
[eglot] Asking EGLOT (sgo/(c-mode c++-mode)) politely to terminate
[jsonrpc] Server exited with status 1
down-list: Process EGLOT (sgo/(c-mode c++-mode)) not running: hangup
--8<---------------cut here---------------end--------------->8---

Running C-x p k a second time does succeed.

The issue was previously also discussed here:
https://github.com/joaotavora/eglot/discussions/822#discussioncomment-3986357


In GNU Emacs 29.0.50 (build 23, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.17.6) of 2022-10-22 built on rhea
Repository revision: ab283bddb2505e767bdf08b063c648b87d71d33a
Repository branch: feature/package+vc
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --with-pgtk --with-imagemagick'

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ IMAGEMAGICK
JPEG JSON LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS XIM
GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  TeX-PDF-mode: t
  rcirc-color-mode: t
  rcirc-track-minor-mode: t
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  outline-minor-mode: t
  flymake-mode: t
  yas-minor-mode: t
  flyspell-mode: t
  repeat-mode: t
  display-battery-mode: t
  display-time-mode: t
  diff-hl-flydiff-mode: t
  diff-hl-mode: t
  winner-mode: t
  windmove-mode: t
  corfu-history-mode: t
  corfu-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  electric-pair-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  save-place-mode: t
  savehist-mode: t
  pixel-scroll-precision-mode: t
  pixel-scroll-mode: t
  xterm-mouse-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tab-bar-mode: t
  file-name-shadow-mode: t
  context-menu-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/philip/.config/emacs/site-lisp/flymake-proselint/flymake-proselint hides /home/philip/.config/emacs/elpa/flymake-proselint-0.3.0/flymake-proselint
/home/philip/.config/emacs/elpa/transient-0.3.7/transient hides /home/philip/Source/emacs/lisp/transient
/home/philip/.config/emacs/elpa/xref-1.5.1/xref hides /home/philip/Source/emacs/lisp/progmodes/xref

Features:
(shadow emacsbug go-mode find-file etags fileloop nroff-mode dictionary
dictionary-connection vertico-buffer loadhist embark ffap url-cache
url-http url-auth url-gw display-line-numbers vc-annotate reposition
multi-prompt two-column shortdoc rect gnus-draft ox-odt rng-loc rng-uri
rng-parse rng-match rng-dt rng-util rng-pttrn nxml-parse nxml-ns
nxml-enc xmltok nxml-util ox-latex ox-icalendar org-agenda org-refile
ox-html table ox-ascii ox-publish ox reftex-sel cursor-sensor
reftex-parse reftex-toc consult-vertico consult compat-28 magit-bookmark
bookmark em-unix em-term term ehelp em-script em-prompt em-ls em-hist
em-pred em-glob em-extpipe em-cmpl em-dirs esh-var em-basic em-banner
em-alias esh-mode eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg
esh-module esh-groups esh-util ange-ftp whitespace preview reporter
desktop frameset tex-fold reftex-dcr reftex-auc reftex reftex-loaddefs
reftex-vars font-latex latex latex-flymake tex-ispell tex-style tex
texmathp tex-mode latexenc mhtml-mode css-mode js sgml-mode facemenu
gnus-search eieio-opt mailalias smtpmail rcirc-color rcirc
autocrypt-message ecomplete flow-fill mm-archive sh-script smie
executable quail org-element avl-tree generator ol-eww eww url-queue
mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect ol-docview
doc-view jka-compr image-mode exif ol-bibtex ol-bbdb ol-w3m ol-doi
org-link-doi org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro
org-footnote org-src ob-comint org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob-core ob-eval org-table
oc-basic bibtex ol org-keys oc org-compat org-macs org-loaddefs cal-menu
calendar cal-loaddefs ef-bio-theme ef-autumn-theme ef-frost-theme
ef-night-theme ietf-drums-date sort smiley gnus-cite mail-extr textsec
uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check qp
gnus-async gnus-bcklg gnus-ml disp-table autocrypt-gnus autocrypt
nndraft nnmh utf-7 nnfolder epa-file network-stream nsm gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime gnutls dig nntp gnus-cache gnus-sum shr
pixel-fill kinsoku url-file svg dom gnus-group gnus-undo gnus-start
gnus-dbus gnus-cloud nnimap nnmail mail-source utf7 nnoo gnus-spec
gnus-int gnus-range gnus-win ef-duo-dark-theme ef-trio-dark-theme
ef-trio-light-theme ef-themes cus-theme flymake-proselint xdg apropos
tabify cus-start cl-print mule-util pulse markdown-mode color profiler
avy copyright cc-mode advice cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-langs cc-vars cc-defs cc-bytecomp
magit-extras goto-addr face-remap magit-submodule magit-obsolete
magit-blame magit-stash magit-reflog magit-bisect magit-push magit-pull
magit-fetch magit-clone magit-remote magit-commit magit-sequence
magit-notes magit-worktree magit-tag magit-merge magit-branch
magit-reset magit-files magit-refs magit-status magit magit-repos
magit-apply magit-wip magit-log which-func edebug magit-diff smerge-mode
git-commit log-edit message yank-media puny rfc822 mml mml-sec epa
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader add-log magit-core magit-autorevert magit-margin
magit-transient magit-process with-editor server magit-mode transient
edmacro kmacro magit-git magit-section magit-utils crm dash dired-aux
gnus-dired autorevert char-fold misearch multi-isearch bug-reference
buffer-env compat vc-backup vc-fossil vc-hg vc-git vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs eglot array filenotify jsonrpc ert debug backtrace
xref imenu find-func vertico-directory orderless vertico-flat noutline
outline so-long checkdoc flymake-proc flymake warnings
yasnippet-snippets yasnippet flyspell ispell init auth-source-pass
repeat project battery dbus xml shell-command+ thingatpt dired-x time
sendmail rfc2047 rfc2045 ietf-drums gnus nnheader gnus-util mail-utils
range mm-util mail-prsvr finder-inf diff-hl-flydiff diff diff-hl
log-view pcvs-util vc-dir ewoc vc dired dired-loaddefs vc-dispatcher
diff-mode hippie-exp winner windmove corfu-history corfu
vertico-multiform vertico elec-pair tramp-sh tramp tramp-cache
time-stamp tramp-loaddefs trampver tramp-integration cus-edit pp icons
tramp-compat shell pcomplete parse-time iso8601 time-date ls-lisp
format-spec recentf tree-widget wid-edit saveplace savehist pixel-scroll
cua-base xt-mouse modus-operandi-theme modus-themes cus-load setup
site-lisp auto-site loaddefs-gen lisp-mnt auctex-autoloads tex-site
ef-themes-autoloads xr-autoloads consult-autoloads corfu-autoloads
focus-autoloads vertico-autoloads debbugs-autoloads
rcirc-color-autoloads inspector-autoloads flymake-proselint-autoloads
geiser-guile-autoloads xref-autoloads vc-fossil-autoloads
diff-hl-autoloads crdt-autoloads embark-autoloads magit-autoloads
buffer-env-autoloads compat-autoloads geiser-chibi-autoloads geiser-impl
help-fns radix-tree geiser-custom geiser-base geiser-autoloads
slime-autoloads transient-autoloads info speedbar ezimage dframe package
let-alist cl-extra help-mode browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util mailcap url-handlers url-parse auth-source eieio
eieio-core password-cache json map byte-opt bytecomp byte-compile
derived cl-seq compile easy-mmode files-x rx text-property-search comint
ansi-osc ansi-color ring cconv cl-macs gv pcase url-vars inline epg
rfc6068 epg-config subr-x cl-loaddefs cl-lib rmc iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/pgtk-win pgtk-win term/common-win pgtk-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock
font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq
simple cl-generic indonesian philippine cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button
loaddefs theme-loaddefs faces cus-face macroexp files window
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget keymap hashtable-print-readable backquote threads dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk multi-tty make-network-process emacs)

Memory information:
((conses 16 1976854 260727)
 (symbols 48 63144 155)
 (strings 32 275874 35428)
 (string-bytes 1 8519084)
 (vectors 16 169530)
 (vector-slots 8 3195578 164029)
 (floats 8 1123 670)
 (intervals 56 51553 1925)
 (buffers 1000 89))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Philip Kaludercic <philipk@HIDDEN>
Subject: bug#58839: Acknowledgement (29.0.50; project-kill-buffer fails
 when Eglot is running)
Message-ID: <handler.58839.B.166696183425764.ack <at> debbugs.gnu.org>
References: <87sfj8umwb.fsf@HIDDEN>
X-Gnu-PR-Message: ack 58839
X-Gnu-PR-Package: emacs
Reply-To: 58839 <at> debbugs.gnu.org
Date: Fri, 28 Oct 2022 12:58:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 58839 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
58839: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D58839
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 17:17:02 +0000
Resent-Message-ID: <handler.58839.B58839.166697738827938 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>,  Dmitry Gutov <dgutov@HIDDEN>
Cc: 58839 <at> debbugs.gnu.org
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
In-Reply-To: <87sfj8umwb.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Fri, 28 Oct 2022 18:17:18 +0100
Message-ID: <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000870d2205ec1b6a2e"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--000000000000870d2205ec1b6a2e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic <philipk@HIDDEN>
wrote:

> When wanting to clean up behind a project I like to use C-x p k to get
> rid of everything I have opened related to it.  If I was using Eglot and
> there is still an active LSP server running in the background, killing
> the project fails with these messages:

Thanks Philip.  This was discussed at

https://github.com/joaotavora/eglot/discussions/822

Some more information is needed:

1. The error only happens when eglot-autoshutdown has been set to t by
   the user.

2. When it has not been set to t, then the behavior is still not
   correct, but the user may not notice it.

3. According to Manuel Uberti, the problem also happens with CIDER, a
   Clojure IDE for Emacs.  So it seems it is not exclusive to Eglot.

The problem happens because `project-kill-buffers` uses project.el's
sense of a project buffer, and then endeavours to kill all such buffers.

So far so good, but the determination of project buffers according
to `project-buffers` considers all buffers whose buffer-local default
directory starts with a given root of some project.

This is subtly wrong because it also considers buffers whose name starts
with space and without buffer-file-names, so-called "hidden buffers" which
are deemed "uninteresting" to the user (according to the Elisp manual).
They commonly function as implementation details of other packages, such
as Eglot (and possibly CIDER).  These buffers are not normally visible
to the user in M-x ibuffer, switch-to-buffer, etc.

In Eglot's case, the buffer whose name is " EGLOT process..." is
created by eglot.el and then handed over to jsonrpc.el, which becomes
responsible for it.

Killing this buffer from Lisp using `kill-buffer` is incorrect because
it contradicts Eglot's user preferences eglot-autoreconnect and
eglot-autoshutdown:

1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the
   process and confuses the LSP shutdown logic, which is a polite
   "teardown" conversation with the LSP server.  This is Philip's error.

2. If eglot-autoshutdown is nil but eglot-autoreconnect is non-nil (in
   fact, these are the defaults), killing the buffer has the effect of
   immediately restarting the connection, and thus re-creating the
   buffer.  The best that can happen is that nothing was achieved
   and only time was wasted.

The fact is that the buffer in question is an internal Eglot implementation
detail that other packages should stay clear of.

In fact, I think that all hidden buffers can be considered thusly.
They're just like `--` symbols in obarray or in other symbol's plists:
they're visible to all Lisp packages but they are implementation details
that shouldn't be messed with except by the owner of such details.

Dmitry tells me that there was some discussion where it was determined
that it's somehow useful in project-kill-buffers to also target buffers
that the
user isn't aware of.

But I've not seen evidence of this usefulness.  If there is indeed some,
I propose we come up with some convention so that it is possible for
packages to create buffers which are "definitely hidden and private and
not to me tinkered with".  Such a convention could be starting the
buffer name with two spaces.

Whatever the convention, currently I think that the patch after my
signature is the correct approach to fix this bug.

Thanks,
Jo=C3=A3o

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..4f542137a8 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -352,14 +352,18 @@ project--remote-file-names
                 (concat remote-id file))
               local-files))))

+(defun project--buffer-uninteresting-p (buf)
+  (and (string-prefix-p " " (buffer-name buf)) (null (buffer-file-name
buf))))
+
 (cl-defgeneric project-buffers (project)
   "Return the list of all live buffers that belong to PROJECT."
   (let ((root (expand-file-name (file-name-as-directory (project-root
project))))
         bufs)
     (dolist (buf (buffer-list))
-      (when (string-prefix-p root (expand-file-name
-                                   (buffer-local-value 'default-directory
buf)))
-        (push buf bufs)))
+      (unless (project--buffer-uninteresting-p buf)
+        (when (string-prefix-p root (expand-file-name
+                                     (buffer-local-value
'default-directory buf)))
+          (push buf bufs))))
     (nreverse bufs)))

 (defgroup project-vc nil
@@ -680,11 +684,12 @@ project-buffers
          dd
          bufs)
     (dolist (buf (buffer-list))
-      (setq dd (expand-file-name (buffer-local-value 'default-directory
buf)))
-      (when (and (string-prefix-p root dd)
-                 (not (cl-find-if (lambda (module) (string-prefix-p module
dd))
-                                  modules)))
-        (push buf bufs)))
+      (unless (project--buffer-uninteresting-p buf)
+        (setq dd (expand-file-name (buffer-local-value 'default-directory
buf)))
+        (when (and (string-prefix-p root dd)
+                   (not (cl-find-if (lambda (module) (string-prefix-p
module dd))
+                                    modules)))
+          (push buf bufs))))
     (nreverse bufs)))

--000000000000870d2205ec1b6a2e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic &lt;<a h=
ref=3D"mailto:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br><br>=
&gt; When wanting to clean up behind a project I like to use C-x p k to get=
<br>&gt; rid of everything I have opened related to it.=C2=A0 If I was usin=
g Eglot and<br>&gt; there is still an active LSP server running in the back=
ground, killing<br>&gt; the project fails with these messages:<br><br>Thank=
s Philip.=C2=A0 This was discussed at<br><br><a href=3D"https://github.com/=
joaotavora/eglot/discussions/822">https://github.com/joaotavora/eglot/discu=
ssions/822</a><br><br>Some more information is needed:<br><br>1. The error =
only happens when eglot-autoshutdown has been set to t by<br>=C2=A0 =C2=A0t=
he user.<br><br>2. When it has not been set to t, then the behavior is stil=
l not<br>=C2=A0 =C2=A0correct, but the user may not notice it.<br><br>3. Ac=
cording to Manuel Uberti, the problem also happens with CIDER, a<br>=C2=A0 =
=C2=A0Clojure IDE for Emacs.=C2=A0 So it seems it is not exclusive to Eglot=
.<br><br>The problem happens because `project-kill-buffers` uses project.el=
&#39;s<br>sense of a project buffer, and then endeavours to kill all such b=
uffers.<br><div><br></div><div>So far so good, but the determination of pro=
ject buffers according</div>to `project-buffers` considers all buffers whos=
e buffer-local default<br>directory starts with a given root of some projec=
t.<br><br>This is subtly wrong because it also considers buffers whose name=
 starts<br>with space and without buffer-file-names, so-called &quot;hidden=
 buffers&quot; which<br>are deemed &quot;uninteresting&quot; to the user (a=
ccording to the Elisp manual).<br>They commonly function as implementation =
details of other packages, such<br>as Eglot (and possibly CIDER).=C2=A0 The=
se buffers are not normally visible<br>to the user in M-x ibuffer, switch-t=
o-buffer, etc.<br><br>In Eglot&#39;s case, the buffer whose name is &quot; =
EGLOT process...&quot; is<br>created by eglot.el and then handed over to js=
onrpc.el, which becomes<br>responsible for it.<br><br>Killing this buffer f=
rom Lisp using `kill-buffer` is incorrect because<br>it contradicts Eglot&#=
39;s user preferences eglot-autoreconnect and<br>eglot-autoshutdown:<br><br=
>1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the<br>=
=C2=A0 =C2=A0process and confuses the LSP shutdown logic, which is a polite=
<br>=C2=A0 =C2=A0&quot;teardown&quot; conversation with the LSP server.=C2=
=A0 This is Philip&#39;s error.<br><br>2. If eglot-autoshutdown is nil but =
eglot-autoreconnect is non-nil (in<br>=C2=A0 =C2=A0fact, these are the defa=
ults), killing the buffer has the effect of<br>=C2=A0 =C2=A0immediately res=
tarting the connection, and thus re-creating the<br><div>=C2=A0 =C2=A0buffe=
r.=C2=A0 The best that can happen is that nothing was achieved <br></div><d=
iv>=C2=A0=C2=A0 and only time was wasted.</div><br><div>The fact is that th=
e buffer in question is an internal Eglot implementation <br></div><div>det=
ail that other packages should stay clear of.=C2=A0 <br></div><br>In fact, =
I think that all hidden buffers can be considered thusly.<br>They&#39;re ju=
st like `--` symbols in obarray or in other symbol&#39;s plists:<br>they&#3=
9;re visible to all Lisp packages but they are implementation details<br><d=
iv>that shouldn&#39;t be messed with except by the owner of such details.</=
div><br>Dmitry tells me that there was some discussion where it was determi=
ned<br><div>that it&#39;s somehow useful in project-kill-buffers to also ta=
rget buffers that the</div><div>user isn&#39;t aware of.<br></div><br>But I=
&#39;ve not seen evidence of this usefulness.=C2=A0 If there is indeed some=
,<br>I propose we come up with some convention so that it is possible for<b=
r>packages to create buffers which are &quot;definitely hidden and private =
and<br>not to me tinkered with&quot;.=C2=A0 Such a convention could be star=
ting the<br>buffer name with two spaces.<br><br>Whatever the convention, cu=
rrently I think that the patch after my<br><div>signature is the correct ap=
proach to fix this bug.</div><div><br></div><div>Thanks,<br></div><div>Jo=
=C3=A3o<br></div><div><br></div><div>diff --git a/lisp/progmodes/project.el=
 b/lisp/progmodes/project.el<br>index ac278edd40..4f542137a8 100644<br>--- =
a/lisp/progmodes/project.el<br>+++ b/lisp/progmodes/project.el<br>@@ -352,1=
4 +352,18 @@ project--remote-file-names<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(concat remote-id file))<br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0local-files))))<br>=C2=A0<br>+(def=
un project--buffer-uninteresting-p (buf)<br>+ =C2=A0(and (string-prefix-p &=
quot; &quot; (buffer-name buf)) (null (buffer-file-name buf))))<br>+<br>=C2=
=A0(cl-defgeneric project-buffers (project)<br>=C2=A0 =C2=A0&quot;Return th=
e list of all live buffers that belong to PROJECT.&quot;<br>=C2=A0 =C2=A0(l=
et ((root (expand-file-name (file-name-as-directory (project-root project))=
))<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bufs)<br>=C2=A0 =C2=A0 =C2=A0(dolis=
t (buf (buffer-list))<br>- =C2=A0 =C2=A0 =C2=A0(when (string-prefix-p root =
(expand-file-name<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-=
local-value &#39;default-directory buf)))<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0(=
push buf bufs)))<br>+ =C2=A0 =C2=A0 =C2=A0(unless (project--buffer-unintere=
sting-p buf)<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (string-prefix-p root (e=
xpand-file-name<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
buffer-local-value &#39;default-directory buf)))<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0(push buf bufs))))<br>=C2=A0 =C2=A0 =C2=A0(nreverse bufs)))<br=
>=C2=A0<br>=C2=A0(defgroup project-vc nil<br>@@ -680,11 +684,12 @@ project-=
buffers<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 dd<br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 bufs)<br>=C2=A0 =C2=A0 =C2=A0(dolist (buf (buffer-list))<br>-=
 =C2=A0 =C2=A0 =C2=A0(setq dd (expand-file-name (buffer-local-value &#39;de=
fault-directory buf)))<br>- =C2=A0 =C2=A0 =C2=A0(when (and (string-prefix-p=
 root dd)<br>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not=
 (cl-find-if (lambda (module) (string-prefix-p module dd))<br>- =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules)))<br>- =C2=A0 =C2=A0 =C2=A0 =C2=
=A0(push buf bufs)))<br>+ =C2=A0 =C2=A0 =C2=A0(unless (project--buffer-unin=
teresting-p buf)<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0(setq dd (expand-file-name=
 (buffer-local-value &#39;default-directory buf)))<br>+ =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(when (and (string-prefix-p root dd)<br>+ =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (not (cl-find-if (lambda (module)=
 (string-prefix-p module dd))<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0modules)))<br>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(push buf bu=
fs))))<br>=C2=A0 =C2=A0 =C2=A0(nreverse bufs)))<br>=C2=A0<br>=C2=A0=0C</div=
></div>

--000000000000870d2205ec1b6a2e--

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 17:30:02 +0000
Resent-Message-ID: <handler.58839.B58839.166697814829191 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 28 Oct 2022
 18:17:18 +0100")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Fri, 28 Oct 2022 17:28:50 +0000
Message-ID: <87edur3lil.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> On Fri, Oct 28, 2022 at 1:58 PM Philip Kaludercic <philipk@HIDDEN>
> wrote:
>
>> When wanting to clean up behind a project I like to use C-x p k to get
>> rid of everything I have opened related to it.  If I was using Eglot and
>> there is still an active LSP server running in the background, killing
>> the project fails with these messages:
>
> Thanks Philip.  This was discussed at
>
> https://github.com/joaotavora/eglot/discussions/822
>
> Some more information is needed:
>
> 1. The error only happens when eglot-autoshutdown has been set to t by
>    the user.
>
> 2. When it has not been set to t, then the behavior is still not
>    correct, but the user may not notice it.
>
> 3. According to Manuel Uberti, the problem also happens with CIDER, a
>    Clojure IDE for Emacs.  So it seems it is not exclusive to Eglot.
>
> The problem happens because `project-kill-buffers` uses project.el's
> sense of a project buffer, and then endeavours to kill all such buffers.
>
> So far so good, but the determination of project buffers according
> to `project-buffers` considers all buffers whose buffer-local default
> directory starts with a given root of some project.
>
> This is subtly wrong because it also considers buffers whose name starts
> with space and without buffer-file-names, so-called "hidden buffers" which
> are deemed "uninteresting" to the user (according to the Elisp manual).
> They commonly function as implementation details of other packages, such
> as Eglot (and possibly CIDER).  These buffers are not normally visible
> to the user in M-x ibuffer, switch-to-buffer, etc.
>
> In Eglot's case, the buffer whose name is " EGLOT process..." is
> created by eglot.el and then handed over to jsonrpc.el, which becomes
> responsible for it.
>
> Killing this buffer from Lisp using `kill-buffer` is incorrect because
> it contradicts Eglot's user preferences eglot-autoreconnect and
> eglot-autoshutdown:
>
> 1. If eglot-autoshutdown is t, killing the buffer from Lisp kills the
>    process and confuses the LSP shutdown logic, which is a polite
>    "teardown" conversation with the LSP server.  This is Philip's error.

> 2. If eglot-autoshutdown is nil but eglot-autoreconnect is non-nil (in
>    fact, these are the defaults), killing the buffer has the effect of
>    immediately restarting the connection, and thus re-creating the
>    buffer.  The best that can happen is that nothing was achieved
>    and only time was wasted.
>
> The fact is that the buffer in question is an internal Eglot implementati=
on
> detail that other packages should stay clear of.
>
> In fact, I think that all hidden buffers can be considered thusly.
> They're just like `--` symbols in obarray or in other symbol's plists:
> they're visible to all Lisp packages but they are implementation details
> that shouldn't be messed with except by the owner of such details.
>
> Dmitry tells me that there was some discussion where it was determined
> that it's somehow useful in project-kill-buffers to also target buffers
> that the
> user isn't aware of.
>
> But I've not seen evidence of this usefulness.  If there is indeed some,
> I propose we come up with some convention so that it is possible for
> packages to create buffers which are "definitely hidden and private and
> not to me tinkered with".  Such a convention could be starting the
> buffer name with two spaces.
>
> Whatever the convention, currently I think that the patch after my
> signature is the correct approach to fix this bug.
>
> Thanks,
> Jo=C3=A3o
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..4f542137a8 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -352,14 +352,18 @@ project--remote-file-names
>                  (concat remote-id file))
>                local-files))))
>
> +(defun project--buffer-uninteresting-p (buf)
> +  (and (string-prefix-p " " (buffer-name buf)) (null (buffer-file-name
> buf))))
> +
>  (cl-defgeneric project-buffers (project)
>    "Return the list of all live buffers that belong to PROJECT."
>    (let ((root (expand-file-name (file-name-as-directory (project-root
> project))))
>          bufs)
>      (dolist (buf (buffer-list))
> -      (when (string-prefix-p root (expand-file-name
> -                                   (buffer-local-value 'default-directory
> buf)))
> -        (push buf bufs)))
> +      (unless (project--buffer-uninteresting-p buf)
> +        (when (string-prefix-p root (expand-file-name
> +                                     (buffer-local-value
> 'default-directory buf)))
> +          (push buf bufs))))
>      (nreverse bufs)))
>
>  (defgroup project-vc nil
> @@ -680,11 +684,12 @@ project-buffers
>           dd
>           bufs)
>      (dolist (buf (buffer-list))
> -      (setq dd (expand-file-name (buffer-local-value 'default-directory
> buf)))
> -      (when (and (string-prefix-p root dd)
> -                 (not (cl-find-if (lambda (module) (string-prefix-p modu=
le
> dd))
> -                                  modules)))
> -        (push buf bufs)))
> +      (unless (project--buffer-uninteresting-p buf)
> +        (setq dd (expand-file-name (buffer-local-value 'default-directory
> buf)))
> +        (when (and (string-prefix-p root dd)
> +                   (not (cl-find-if (lambda (module) (string-prefix-p
> module dd))
> +                                    modules)))
> +          (push buf bufs))))
>      (nreverse bufs)))

I still don't agree that this is the right interpretation of the issue
or solution, but wouldn't it be better to add this to
`project-kill-buffer-conditions'?

The solution I would prefer is if project.el would define a sort of
project-kill-hook, that Eglot would modify and make sure that
`eglot-shutdown' is invoked before any buffer is killed.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 17:36:02 +0000
Resent-Message-ID: <handler.58839.B58839.166697855629884 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166697855629884
          (code B ref 58839); Fri, 28 Oct 2022 17:36:02 +0000
Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 17:35:56 +0000
Received: from localhost ([127.0.0.1]:34206 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooTGu-0007lv-7e
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:35:56 -0400
Received: from mail-oa1-f42.google.com ([209.85.160.42]:34733)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ooTGs-0007lh-BO
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 13:35:54 -0400
Received: by mail-oa1-f42.google.com with SMTP id
 586e51a60fabf-13ba86b5ac0so7082869fac.1
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 10:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=feoRXod2uxVIgJD8Xr8N0mIda1WYvWiIoq7xhULSrxk=;
 b=Y0miWxW8LgurcD8Aw15lTERHdZJ4sfSpJ47bn+lUTGIvOSklTX0V6oSFm/8i+l1gjz
 odQ4hfhtWARLx3XdqzPy+vfhjxAypprQPCTedeW0pfpCRhx2hqkkbGOVcfQFMBLdXzge
 uK8meA0CAU7MlWigfjXK64zW9OwoNUezgUz0L30MahJSVPhkRIFUO/FOuMQejpaxPpVW
 dZ9U2Xao0Ap7rC8qYgBEgyskMEFK34vMuF5S0/a0/s4RXodE/4mRiMIga8QLVgM7tTIZ
 y2CSNa+lUoSmc64sa5PItOC5nLx4rrzWBG5TAzPV2VjHe4u+wSmih4X3w0hdQplJPUxo
 xnsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=feoRXod2uxVIgJD8Xr8N0mIda1WYvWiIoq7xhULSrxk=;
 b=K8mcuZX6j5u/6Kx4Ipag+4l2jeQkkqxG5lKqXGqCjYcSkM0jsD13TgszQrY0Io5TCu
 scVjBD+8QUrsjuDXxPBlcvzxtb/DIlwp+ekiS0eH/FzovT6LArmVkRlLU7ziaY99H9sd
 nIzwgsBV5IaKP3dmBhAVAGysJKuGslBgF5b6c0vHEZmS0DtSslUU80UglnuyQOIqS0Fp
 1ZPXAJT/CfdAVA/lcZwOCuYbJBD78NzaZ51EvQoF8Q9ZUc7O26gIWUdH0piZapkP/EhA
 IpThkRGWRhY0pYav1h6PikQJ8NVFyqgqFQFLD4JKLpoH6yDMO1a6YtmFWJelPyztgCq1
 gtpQ==
X-Gm-Message-State: ACrzQf2CseAyT77BQrZxhr2qwKganPHY0DcE/eKgN/7P2Y/Le0nGUAZs
 5edOv98imEQ1iu/qNXP6teHe9ELgdrGOKTxXn9A=
X-Google-Smtp-Source: AMsMyM7HdMZb8rrqCrQbtItf0zZLzSXLM0qWhzkVnzLPDb/GiLfL71rFQdDgU7tc9CDJw1po8kiOYNH2d0uRcDzGy8w=
X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id
 g21-20020a056870215500b0013c8db12446mr1393909oae.171.1666978548597; Fri, 28
 Oct 2022 10:35:48 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
In-Reply-To: <87edur3lil.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Fri, 28 Oct 2022 18:36:48 +0100
Message-ID: <CALDnm51t_G39W6s1VVbtE7qjsAdeh1+bxLuQNk=entsaV-O-rg@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000003cc74405ec1bb08d"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000003cc74405ec1bb08d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 28, 2022 at 6:28 PM Philip Kaludercic <philipk@HIDDEN>
wrote:

>
> I still don't agree that this is the right interpretation of the issue
> or solution, but wouldn't it be better to add this to
> `project-kill-buffer-conditions'?
>
> The solution I would prefer is if project.el would define a sort of
> project-kill-hook, that Eglot would modify and make sure that
> `eglot-shutdown' is invoked before any buffer is killed.
>

I believe we have been over this.  Eglot's preference eglot-autoshutdown
and eglot-autoreconnect already control this behaviour.  You should use
those: eglot-autoshutdown does _exactly_ what you want: shut the process
down (in a controlled fashion) if all manged buffers are killed.

You may argue (in a separate issue) that eglot-autoshutdown's default shoul=
d
be t.  Just like any other user preference, we can weigh the pros and cons.

That buffer is Eglot's property, just like internal symbols or global data
structures.
Just because it's a buffer, it doesn't mean you may touch it.   It is
hidden because
you may not.  What would even be the advantage here?

You can of course show a patch, but I doubt it's going to be much simpler
than
what I have proposed.  For starters, your idea increases coupling between
two packages, which is generally not good.

Jo=C3=A3o

--0000000000003cc74405ec1bb08d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Fri, Oct 28, 2022 at 6:28 PM Philip Kaludercic &lt;<a href=3D"mai=
lto:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><br>
I still don&#39;t agree that this is the right interpretation of the issue<=
br>
or solution, but wouldn&#39;t it be better to add this to<br>
`project-kill-buffer-conditions&#39;?<br>
<br>
The solution I would prefer is if project.el would define a sort of<br>
project-kill-hook, that Eglot would modify and make sure that<br>
`eglot-shutdown&#39; is invoked before any buffer is killed.<br>
</blockquote></div><div><br></div><div>I believe we have been over this.=C2=
=A0 Eglot&#39;s preference eglot-autoshutdown</div><div>and eglot-autorecon=
nect already control this behaviour.=C2=A0 You should use <br></div><div>th=
ose: eglot-autoshutdown does _exactly_ what you want: shut the process</div=
><div>down (in a controlled fashion) if all manged buffers are killed.</div=
><div><br></div><div>You may argue (in a separate issue) that eglot-autoshu=
tdown&#39;s default should</div><div>be t.=C2=A0 Just like any other user p=
reference, we can weigh the pros and cons.<br></div><div><br></div><div>Tha=
t buffer is Eglot&#39;s property, just like internal symbols or global data=
 structures.<br></div><div>Just because it&#39;s a buffer, it doesn&#39;t m=
ean you may touch it.=C2=A0=C2=A0 It is hidden because <br></div><div>you m=
ay not.=C2=A0 What would even be the advantage here?</div><div><br></div><d=
iv>You can of course show a patch, but I doubt it&#39;s going to be much si=
mpler than <br></div><div>what I have proposed.=C2=A0 For starters, your id=
ea increases coupling between <br></div><div>two packages, which is general=
ly not good.<br></div><div><br></div><div>Jo=C3=A3o<br></div></div>

--0000000000003cc74405ec1bb08d--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 18:15:02 +0000
Resent-Message-ID: <handler.58839.B58839.16669808781155 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16669808781155
          (code B ref 58839); Fri, 28 Oct 2022 18:15:02 +0000
Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:14:38 +0000
Received: from localhost ([127.0.0.1]:34240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooTsM-0000IZ-0O
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:14:38 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:44725)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ooTsH-0000IH-54
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:14:36 -0400
Received: by mail-wr1-f41.google.com with SMTP id v1so7626598wrt.11
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=RoZdUhsriRrC/v6F7u2dkDpRLeu8GwlgG3iWKgtJjbQ=;
 b=CNO0+d8LOTx/j5h+3BdSKeBUIsEDhdz1amh72vlXe8eyJJ2asdA0NdXW8GGZOGCWuL
 gb6HaN/Fx740r/uJaEtONjsXByhHP7+u0mK/tgjK+61+l+8qki/FwqWVvrPg0SyC0YBx
 QuPvgRXK8k8on4CrEy/kx7/guBHOsG6RUPSzOX/ItnNgdb9py+1Iiv+A+5MV7T1RdEMs
 155ehbTgg3xtVZSOlyQXI68MSpB6zQ+eyxKaCHs+VKtVDsPFCBPu8IXC2kpwiRZdQ1W9
 uFrB9lecOWBOhWGMLNqAJE6O37MIK4BoCkGdYMnckGSGlpXk1lXiu/LBK0GJjUQmdoc/
 8MAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=RoZdUhsriRrC/v6F7u2dkDpRLeu8GwlgG3iWKgtJjbQ=;
 b=dlEGzUKQeUw13tvGAQs86YBXVCB9IaF8u3lEfnx1fn+BNUndy0NVvoiT7JV9vWtkPC
 3UAgymZa9KRuHnvrxRmlcqplQOkzQJxRY3W0qf3gXxDgPCUimWvoF2w6B/UYL+uGAGBP
 2wLILoZjhHinxc/J+ugIWQVo4KG1PQrBPFf/imc8WSsw68plFAq6DQohzJpFu+WuaKps
 xvIuQ3J8H/m/aEmi0/rwmcDp5p6Ca+y8FsqvUfjXKKwsHXFoE1V35qnM0FH7fj1TEEmU
 MlW4+fFmJ5Sy8MmVQQ9I/2ob/X8cE50XsBf+oh7eTUmoIuZ7MgkOJFlL39ZU+bWDSM2s
 g1TQ==
X-Gm-Message-State: ACrzQf368SGb95/MdXhgFIjqeF7Flje7WbpbbYQJ0B1MQiJjK9fv8sJX
 kuU8EeAKKWSCF8AflmkfmwBdIpxH/wU=
X-Google-Smtp-Source: AMsMyM4OEdcA0EgEO/GLlDHKue+cD9SXuxScyExJPZg2HyMGE0zjbadhM72vIWFC0CiLIlD0zi4eLw==
X-Received: by 2002:a5d:4e8c:0:b0:236:6f5a:e893 with SMTP id
 e12-20020a5d4e8c000000b002366f5ae893mr397568wru.44.1666980867561; 
 Fri, 28 Oct 2022 11:14:27 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 bt6-20020a056000080600b0023677e1157fsm4406855wrb.56.2022.10.28.11.14.26
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Oct 2022 11:14:27 -0700 (PDT)
Message-ID: <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
Date: Fri, 28 Oct 2022 21:14:25 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87edur3lil.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 28.10.2022 20:28, Philip Kaludercic wrote:
> I still don't agree that this is the right interpretation of the issue
> or solution, but wouldn't it be better to add this to
> `project-kill-buffer-conditions'?

I don't mind a new variable specifically, but 
kill-buffer-query-functions seems to serve this purpose just fine.

And no extra "coupling between two packages" will be added.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 18:22:02 +0000
Resent-Message-ID: <handler.58839.B58839.16669812641799 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16669812641799
          (code B ref 58839); Fri, 28 Oct 2022 18:22:02 +0000
Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:21:04 +0000
Received: from localhost ([127.0.0.1]:34252 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooTya-0000Sx-Dm
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:21:04 -0400
Received: from mout01.posteo.de ([185.67.36.65]:40737)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1ooTyU-0000S4-Nc
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:21:02 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 8DE0A240027
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 20:20:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1666981252; bh=xHzjSbUD8YcF5nDe2B3QfuX43RRLVXCw7u+bPXzDCUQ=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=TMzfRsB/YntCXZjMnSma/lR20crUDyq+qWho+9VhlhuDZiQTGF4ITgffh3rW8p9zv
 AEokmhZXGye5vtQYWyIdijZP4dCrl/K2F4nOwOlqkAuZUJMTMYwXZvmp4R44jUCzxx
 e4gDe4OxMX03EXb5ZKeV6UlSKQh5HVz3Gr9g8hWRHiIWZwDOXb8kZXS8KM6Xu0o2EW
 TQtc84mtHBTtNPk7a4Eqpi/TOiLErajC6Lgdia3S2oTZURtOCPLsRp4FkUXDWgjxG7
 Q6C+G6uJyY2r8uID+7Y9ZKLnMLBXFIjvQXOim+2Z0L0R4b63ihOa4UayVmLfji+DPG
 ZRzFZtUNlj8XA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4MzW7k57Zfz6tmM;
 Fri, 28 Oct 2022 20:20:48 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> (Dmitry Gutov's
 message of "Fri, 28 Oct 2022 21:14:25 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Fri, 28 Oct 2022 18:20:47 +0000
Message-ID: <87a65f3j40.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 28.10.2022 20:28, Philip Kaludercic wrote:
>> I still don't agree that this is the right interpretation of the issue
>> or solution, but wouldn't it be better to add this to
>> `project-kill-buffer-conditions'?
>
> I don't mind a new variable specifically, but
> kill-buffer-query-functions seems to serve this purpose just fine.
>
> And no extra "coupling between two packages" will be added.

How would you imagine it being used in this case?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 18:32:01 +0000
Resent-Message-ID: <handler.58839.B58839.16669818792870 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16669818792870
          (code B ref 58839); Fri, 28 Oct 2022 18:32:01 +0000
Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:31:19 +0000
Received: from localhost ([127.0.0.1]:34274 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooU8U-0000kD-Tu
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:31:19 -0400
Received: from mail-oa1-f53.google.com ([209.85.160.53]:46048)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ooU8S-0000k0-7y
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:31:18 -0400
Received: by mail-oa1-f53.google.com with SMTP id
 586e51a60fabf-13be3ef361dso7178140fac.12
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=dsdCkw3+Y9upUNKOyKq4YiYwt11xbrecoFyaugno7fg=;
 b=TS1hxPnHEaPsBD+uWTEbCv+EVYcbzbUUYIXjva+elxuX03ELMXZPOJ/k0qAsk8FIm/
 tQx67BDo9qEZf8OerQTRZMcYrBRe+Vd9n3xkVjWIrEECy+LzquHmc4BVPZbZUXWMKMi9
 vzjzHnh15Rj/HPQRqu1xWnhvjSLkm+AidYB0DFbQQXFcfzi58j3R5kWx9DUfbODpu5fL
 V1hQ1vaZ6JB/GYRHqRPsoyMPf2hhYxguQqf3WkskWeuFtzNoMKu1GDc/IM9B9ciOF96e
 xN6fqzLArTepFs0SJAGR5f7qcSZ6AY+Z8OPQV4UVnQ+ANTOMAOCcSRuE57/SwG2KOG34
 RrjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=dsdCkw3+Y9upUNKOyKq4YiYwt11xbrecoFyaugno7fg=;
 b=6J8IYdy6t9h5puWL3s5Y53KXaFZr9Waq/Zk3/2TtwQGUtRCdCTrdlWVW7NHmjp3nOG
 qs1+VZ6wDTsNnt/F9BzzCO5YKydCsgDf4NBKryavxkUpFcJS/vmU/lGvpmlRHmBtRKlq
 I/QljsRjyrxMkQpvCd6XDcy4D+I0jgHxAQgLjNGtr0VsfMfYMz9zE5f9SO6JHgYcYzcE
 7d8iWythc0uD2b4tJq0e7qidF8uH+T4dQyBCwdcBSLpZHbx125JWbwDEt2q96k5Ii+a/
 BXNojsMEd1VpvgalXUkgl154mz6NOKo6/B5vWzOk4u2lwymAYr/TdlC89wnBvijvpVj3
 ReOQ==
X-Gm-Message-State: ACrzQf1Bb9mlRu18k/uqp3slOPJb1cIYt1n6wq8PHiQwpGD2KOZhcIJ2
 HEOOrCaPLdhCEqevoR0jIGFIQ+d5XXTvtcSzik4=
X-Google-Smtp-Source: AMsMyM77PZzRRms58T/8T0GoU1C/QWSN2cYjtbCV9RbbRpJ8GWK/M80SH4AEWiY4CCsx6Q/Q82/PNG44LhWOL+AZxRA=
X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id
 g21-20020a056870215500b0013c8db12446mr1524113oae.171.1666981870623; Fri, 28
 Oct 2022 11:31:10 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
In-Reply-To: <87a65f3j40.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Fri, 28 Oct 2022 19:30:59 +0100
Message-ID: <CALDnm50uCekkuvzM_WB1cQ3Gp1tbRZaPXP=c-Pt=y-vUhj2JWw@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000003ee50d05ec1c76a6"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000003ee50d05ec1c76a6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Oct 28, 2022, 19:20 Philip Kaludercic <philipk@HIDDEN> wrote:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
> > On 28.10.2022 20:28, Philip Kaludercic wrote:
> >> I still don't agree that this is the right interpretation of the issue
> >> or solution, but wouldn't it be better to add this to
> >> `project-kill-buffer-conditions'?
> >
> > I don't mind a new variable specifically, but
> > kill-buffer-query-functions seems to serve this purpose just fine.
> >
> > And no extra "coupling between two packages" will be added.
>
> How would you imagine it being used in this case?


May I suggest that we jump over the imagination directly to the reality?

The patch provided lives in the latter realm.

Jo=C3=A3o


>

--0000000000003ee50d05ec1c76a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>On Fri, Oct 28, 2022, 19:20 Philip Kaludercic &lt;<a=
 href=3D"mailto:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></=
div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">Dmitry Gutov &lt;<a href=3D"mailto:dgutov@HIDDEN" targ=
et=3D"_blank" rel=3D"noreferrer">dgutov@HIDDEN</a>&gt; writes:<br>
<br>
&gt; On 28.10.2022 20:28, Philip Kaludercic wrote:<br>
&gt;&gt; I still don&#39;t agree that this is the right interpretation of t=
he issue<br>
&gt;&gt; or solution, but wouldn&#39;t it be better to add this to<br>
&gt;&gt; `project-kill-buffer-conditions&#39;?<br>
&gt;<br>
&gt; I don&#39;t mind a new variable specifically, but<br>
&gt; kill-buffer-query-functions seems to serve this purpose just fine.<br>
&gt;<br>
&gt; And no extra &quot;coupling between two packages&quot; will be added.<=
br>
<br>
How would you imagine it being used in this case?=C2=A0</blockquote></div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto"><div dir=3D"auto">May I =
suggest that we jump over the imagination directly to the reality?=C2=A0</d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">The patch provided lives i=
n the latter realm.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jo=
=C3=A3o</div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
</blockquote></div></div></div>

--0000000000003ee50d05ec1c76a6--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 28 Oct 2022 18:42:02 +0000
Resent-Message-ID: <handler.58839.B58839.16669824743766 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16669824743766
          (code B ref 58839); Fri, 28 Oct 2022 18:42:02 +0000
Received: (at 58839) by debbugs.gnu.org; 28 Oct 2022 18:41:14 +0000
Received: from localhost ([127.0.0.1]:34278 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooUI4-0000ye-3E
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:41:14 -0400
Received: from mail-wr1-f47.google.com ([209.85.221.47]:44727)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ooUHy-0000xy-Nl
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 14:41:10 -0400
Received: by mail-wr1-f47.google.com with SMTP id v1so7701010wrt.11
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 11:41:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=ljY+AsPqvYxkR7JuJNSPTaTitINx+vL34JWr9iTBxiE=;
 b=TiyyvASyt9GJQxtGNpho1gHkttzBTIXg9DfyguQzXUL3hCtD2H5OJ9nayUdNYCXEIS
 0N+J0Ywg/l2U0+055yqpkmwcMevVOxU+jMk0118aq8ysoAIzGxWT0ZztNI6m7T+JyGH9
 aTSFVZ73UPw11r/ziYnY4xkAcJLzAxKCGWYey7vL1TgiYkiwfXX5epkGbC1Ug3kGcat6
 Zbq45JBAMrNvrKwt+okaye0O5mIViqrHU12Ns7lNAkViytyHYsg0BLhJWK0qV5+dwXhk
 POh1bHGjtBHxpAgAAHtN/RY8HXV0JJCk2b4jk5WNePxturwaEBvtPP3kIZbBf6Q3VbPY
 L6+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=ljY+AsPqvYxkR7JuJNSPTaTitINx+vL34JWr9iTBxiE=;
 b=0GK6XpopSG4A4twjkPTlh98ydd+2Ia+kHtI9+Ah6MrqaSKFMmN10/kebl8IkzeJKSO
 vuqD8Ic6IBbIlR+CyqwNE1VbJs7d/cBsDz2NCQPoyqkjDMh9WTJklLDNh62D3PzWhx8V
 zosrma5k8tkqhOSoWy9kxWJZLZitcH79Uv2bRRiepCycKVWDM1YBd6qnZwzGh21SxaRp
 yfyV4XkwdG8w4cdbkmPkl2lIkhqs7p6OlDPpsm9s8SSthl7H0dRR8iyvEMU9mjv3+fHa
 QzhIP6yZrYnbHjgmrT7b4a8aJP1asUYNVpmWAa6EWw+7X7F9wVACTtNNyV/6YvU5Gmi9
 OzXQ==
X-Gm-Message-State: ACrzQf2h62IUB2LgyGyHnnJRfF4nYtndKl4zC7iKxs24N2R43wNzKG7G
 tIDoqLiFdVLY11W2Y5D63Vs=
X-Google-Smtp-Source: AMsMyM4mXGPwOUW4AO2m3RJVj88LZYIj5y5IL/L7rdyeG3h6FNmJoWvn/pY6gJUSZSaXeOsC4IDHdQ==
X-Received: by 2002:adf:f883:0:b0:236:a6a3:d6ac with SMTP id
 u3-20020adff883000000b00236a6a3d6acmr448698wrp.538.1666982460731; 
 Fri, 28 Oct 2022 11:41:00 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 t14-20020a5d690e000000b00225307f43fbsm4034921wru.44.2022.10.28.11.40.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Oct 2022 11:41:00 -0700 (PDT)
Message-ID: <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
Date: Fri, 28 Oct 2022 21:40:58 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87a65f3j40.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 28.10.2022 21:20, Philip Kaludercic wrote:
> Dmitry Gutov<dgutov@HIDDEN>  writes:
> 
>> On 28.10.2022 20:28, Philip Kaludercic wrote:
>>> I still don't agree that this is the right interpretation of the issue
>>> or solution, but wouldn't it be better to add this to
>>> `project-kill-buffer-conditions'?
>> I don't mind a new variable specifically, but
>> kill-buffer-query-functions seems to serve this purpose just fine.
>>
>> And no extra "coupling between two packages" will be added.
> How would you imagine it being used in this case?

(defun eglot-before-kill-special ()
   (eglot-shutdown)
   t)

;; somewhere inside that special buffer's setup:
(add-hook 'kill-buffer-query-functions #'eglot-before-kill-special nil t)

Or use kill-buffer-hook, no need to watch the return value then.

In either case, it will also cover the scenario of the user killing the 
background buffer some other way.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 00:16:01 +0000
Resent-Message-ID: <handler.58839.B58839.166700250128808 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166700250128808
          (code B ref 58839); Sat, 29 Oct 2022 00:16:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 00:15:01 +0000
Received: from localhost ([127.0.0.1]:34523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooZV6-0007UK-Qx
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 20:15:01 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:33493)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ooZV1-0007Tx-0Z
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 20:14:59 -0400
Received: by mail-wm1-f54.google.com with SMTP id
 14-20020a05600c228e00b003cf4eaef74eso4119896wmf.0
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 17:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=;
 b=bow9NPHVhq+2xCikKWo9PKl5e3Ca1u7susqaXZZt/MblT1Dw4uCfmSt28XCriWYM1N
 aMK8bveqq97Ea1dIN4YrlV9aeVTOpyNJBm5H+0m3DtF0Vru+uyrd+KG8L8Ddp0RHfzbj
 49PdpCIr2asKkRbr5zQ4eAO/0bYt2FRlg+b5r04BuCkV+675/+5P0UHXurW4sGFbJxU1
 94OQdlwbfooGzM1/3rVmEuL9Jo5pFGEaOwWlpvR1+65yvQbsU4hX8ax768nkxI3LfTQc
 T3nUEVqYT/aRKVyds0P5M99h8K3iiBHy7l48xjxmTSI0PYZf/2E/xPOft/Pk1PDnCySB
 pwXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=HMjLyUQUBWPWXEFvLdG+3+qjKdrBmYkWm4ht3LFRSGk=;
 b=1caPViiGu8mVZhlhjJQxOfYQbJC7rQeYiFskZtZz7RRXxU9WP9ss1QEK1f9becYAZ0
 nm1GNEdjEEaAMoamX8vRFSrSgaXjZOhgBq8fWm+yHukHD2NjdDsbkJZOHQ0y9GAqMD1G
 IukwPWxyPy77UXEq2r1i/u7i2/0rH352/QNPMv633ljg2uEmfKmMWNGI0QVjmgTvN8Kf
 2pYgEsbrsvQ/49mfWrTgb6c6f+RW8CXYZu5UGqiEUn7dUmB0wlvEOSxgs7uHk9NgsUB+
 yhbQ5Rl2sIjhDjWgY0Etc1M6ji0+HPtVzLxFeLfHlGyxxpT951j9dc4uHwgzLPSe/kM+
 i1iw==
X-Gm-Message-State: ACrzQf0GODL6tCIGQUOSPqbWe2sPV/mTy+HmJpTmQNm8Vzuh9JEK4Gjx
 K5Rq17GhH0/CKbO0BzkBI4Ww0stywH4=
X-Google-Smtp-Source: AMsMyM5duHoYlo9KHiORI+4lg8bppNrVl64uKzg1x9X8qPfUG0OExG++13HlI9OU6YW/lZKViNy4WA==
X-Received: by 2002:a05:600c:600e:b0:3c6:fc59:5eda with SMTP id
 az14-20020a05600c600e00b003c6fc595edamr1020521wmb.30.1667002488607; 
 Fri, 28 Oct 2022 17:14:48 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
 by smtp.gmail.com with ESMTPSA id
 s12-20020a5d6a8c000000b002364c77bcacsm70450wru.38.2022.10.28.17.14.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 28 Oct 2022 17:14:48 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> (Dmitry Gutov's
 message of "Fri, 28 Oct 2022 21:40:58 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
Date: Sat, 29 Oct 2022 01:15:57 +0100
Message-ID: <87zgdfwkle.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> (defun eglot-before-kill-special ()
>   (eglot-shutdown)
>   t)
>
> ;; somewhere inside that special buffer's setup:
> (add-hook 'kill-buffer-query-functions #'eglot-before-kill-special nil t)
>
> Or use kill-buffer-hook, no need to watch the return value then.

Thanks, but this is simply wrong.  Besides missing a required argument,
it doesn't respect the preference of eglot-autoshutdown: I explained
that in the second message of this thread replying to Philip.

I also explained in that message that Eglot doesn't "own" the process
buffer, jsonrpc.el does.  Clients of jsonrpc.el don't even know there's
a process buffer, they only own a handle to a jsonrpc "connection",
which may or may not use buffers underneath.  So your "somewhere
inside..." is a big problem.

> In either case, it will also cover the scenario of the user killing
> the background buffer some other way.

The "background buffer" is hidden.  Users don't see it unless they go
considerably out of their way.  Even M-x project-switch-to-buffer
somehow doesn't list it.

Let me ask you this: can you conceive to that some buffers in Emacs's
buffer list simply don't belong to _any_ project?  If you agree that
there are such cases, then it should become clear that the buffer in
question must be at the top of that list.

There are more hints that the concept of "buffer belonging to a project"
was not fully thought through, even in cases unrelated to this bug
report.

* Take the *scratch* buffer.  It has a default-directory.  Does this
  also make *scratch* belong to a project?  It doesn't make any sense to
  me that it would.  Yet it is caught by project-buffers.

* project-buffers also catches the one-time *Completions* buffers, the
  kind produced by hitting TAB after C-x p b.  If you type C-x p b
  again, it quite comically offers the stale *Completions* buffer as a
  candidate to switch to.

But back to *scratch*.  Somehow *scratch* is not killed by M-x
project-kill-buffers.  I think it's because it doesn't have a
buffer-file-name.  But then neither does the Eglot/Jsonrpc's "background
buffers"!  It seems it is being targeted merely because it uses
fundamental-mode, a most reasonable mode to use for exchanging messages
via standard streams.

I guess this means that the hack below is enough to fix the issue, but
it is also decidedly silly.

So please consider fixing this in project.el.  As Manuel pointed out,
the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
buffers and handles this whole thing very well.  We should just take a
hint from it.

Jo=C3=A3o

diff --git a/lisp/jsonrpc.el b/lisp/jsonrpc.el
index 90833e1c1d..2914d380e9 100644
--- a/lisp/jsonrpc.el
+++ b/lisp/jsonrpc.el
@@ -365,6 +365,9 @@ jsonrpc-process-connection
 :ON-SHUTDOWN (optional), a function of one argument, the
 connection object, called when the process dies.")
=20
+(define-derived-mode jsonrpc--fundamental-mode fundamental-mode ""
+  "Make project.el's stay out of our internal buffers.")
+
 (cl-defmethod initialize-instance ((conn jsonrpc-process-connection) slots)
   (cl-call-next-method)
   (cl-destructuring-bind (&key ((:process proc)) name &allow-other-keys) s=
lots
@@ -377,6 +380,7 @@ initialize-instance
     ;; (but maybe not a slot).
     (let ((calling-buffer (current-buffer)))
       (with-current-buffer (get-buffer-create (format "*%s stderr*" name))
+        (jsonrpc--fundamental-mode)
         (let ((inhibit-read-only t)
               (hidden-name (concat " " (buffer-name))))
           (erase-buffer)
@@ -411,6 +415,7 @@ initialize-instance
     (set-process-filter proc #'jsonrpc--process-filter)
     (set-process-sentinel proc #'jsonrpc--process-sentinel)
     (with-current-buffer (process-buffer proc)
+      (jsonrpc--fundamental-mode)
       (buffer-disable-undo)
       (set-marker (process-mark proc) (point-min))
       (let ((inhibit-read-only t))

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 01:10:02 +0000
Resent-Message-ID: <handler.58839.B58839.16670057631740 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16670057631740
          (code B ref 58839); Sat, 29 Oct 2022 01:10:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 01:09:23 +0000
Received: from localhost ([127.0.0.1]:34585 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooaLi-0000S0-Tt
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:09:23 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:33352)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ooaLh-0000Rm-2q
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:09:22 -0400
Received: by mail-wm1-f48.google.com with SMTP id
 14-20020a05600c228e00b003cf4eaef74eso4140489wmf.0
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 18:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=ERtSdsGFWugoH5FE3ZTapyIsB7jLM0KLRY/XjIek4DM=;
 b=CbZlJUA1NmyCgmo+0updqrf56xr1CuUM3ZbpkharKgOY65mgYDoqV/4NJawcOL1aae
 nS/FOMwYHkRH/U5pWvtWFhV2/793U3UkqD6bLOzM32+Y6+WOrgArNqXwMPXiwHPN8AUw
 0JydatlZsWRugXLPhqrdL9LjZC4MxSdpx3hUNany+wTLmRzgKTI4xrmJ4mkDWxmO1lMB
 NUGdER76YjXPMqI3K0Jn5ZrIRM3DF6fUWkRftxM8ewwe8TgdxGll0+7H5TAw8zGHBZpS
 9IuZWgwcs+2Krb4lcHu1hAxRGUk/a5RFXVLe2GF4kuB0XOv0HxixyO7aH7CSrroYTnIa
 Li9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=ERtSdsGFWugoH5FE3ZTapyIsB7jLM0KLRY/XjIek4DM=;
 b=LuvzAWuDTqUh22MGRAoaB1W5JHyREc7gCPT+DuFNiR97e/THnR/r5BsLMqeqNUPeF7
 uTAYfq239CEuUWgNHAEwmXLyJf7vvHjPq0/uEWNDa8cPoLNGU8ZrBYkhSovmqM4zhurU
 EI7sMVNvncS8veUusqxLh3ZVlUPNMWQXumT01WvG9Jq3ou/p9x+Lx5FFgdtTxWX6M08T
 GkdDGkTMiJbe9N0kRw6apAiszbd4yMehuIfN2k9iihXjXm1TfdvdSG49Ys4cCfMopKCH
 caqK7QenZBJ/0ggsXAghqZXoM4l2Pb0r3AJfQM4AXO//xTuqD9HhLoJiv7Vq+OTTaz9m
 HV7w==
X-Gm-Message-State: ACrzQf2rp2TSLP82mPwewRAayHud3hVa8g8o5ZvmupVVFLH0uEPbFqBe
 +SjkZqfpSTX9/3XWR+QlSo8=
X-Google-Smtp-Source: AMsMyM5/EuG7vt/rIqut80oPPkyrmk32w8k0zLl+SxbmBzLkB4DNuQ0l6DKMrlfLf8UhkSlyrW+yWA==
X-Received: by 2002:a05:600c:2196:b0:3cf:4de3:163c with SMTP id
 e22-20020a05600c219600b003cf4de3163cmr9991728wme.122.1667005754907; 
 Fri, 28 Oct 2022 18:09:14 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 az29-20020a05600c601d00b003cdf141f363sm156077wmb.11.2022.10.28.18.09.14
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 28 Oct 2022 18:09:14 -0700 (PDT)
Message-ID: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
Date: Sat, 29 Oct 2022 04:09:13 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87zgdfwkle.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 29.10.2022 03:15, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> (defun eglot-before-kill-special ()
>>    (eglot-shutdown)
>>    t)
>>
>> ;; somewhere inside that special buffer's setup:
>> (add-hook 'kill-buffer-query-functions #'eglot-before-kill-special nil t)
>>
>> Or use kill-buffer-hook, no need to watch the return value then.
> 
> Thanks, but this is simply wrong.  Besides missing a required argument,
> it doesn't respect the preference of eglot-autoshutdown: I explained
> that in the second message of this thread replying to Philip.

Sorry, I don't have Eglot checked out, or the time to test out the patch.

> I also explained in that message that Eglot doesn't "own" the process
> buffer, jsonrpc.el does.  Clients of jsonrpc.el don't even know there's
> a process buffer, they only own a handle to a jsonrpc "connection",
> which may or may not use buffers underneath.  So your "somewhere
> inside..." is a big problem.
> 
>> In either case, it will also cover the scenario of the user killing
>> the background buffer some other way.
> 
> The "background buffer" is hidden.  Users don't see it unless they go
> considerably out of their way.  Even M-x project-switch-to-buffer
> somehow doesn't list it.
> 
> Let me ask you this: can you conceive to that some buffers in Emacs's
> buffer list simply don't belong to _any_ project?

I suppose. But the current criterion depends on the value of 
default-directory, and that makes it a match.

> If you agree that
> there are such cases, then it should become clear that the buffer in
> question must be at the top of that list.

I'm not sure. Intuitively, I'd say that this buffer belongs to the 
project because it "services" the project. But if it were to work for 
several projects at the same time, I suppose I could say it doesn't 
belong to any particular one.

> There are more hints that the concept of "buffer belonging to a project"
> was not fully thought through, even in cases unrelated to this bug
> report.
> 
> * Take the *scratch* buffer.  It has a default-directory.  Does this
>    also make *scratch* belong to a project?  It doesn't make any sense to
>    me that it would.  Yet it is caught by project-buffers.

*scratch* is not that special - you can create similar buffers at will. 
So there are two ways of looking at that question. One can create a 
"scratch" for a project, and it will be part of that project.

If "~" (the usual value of default-directory in the original *scratch*) 
belongs to a project, then *scratch* also does.

> * project-buffers also catches the one-time *Completions* buffers, the
>    kind produced by hitting TAB after C-x p b.  If you type C-x p b
>    again, it quite comically offers the stale *Completions* buffer as a
>    candidate to switch to.

We could make an exception for that too.

> But back to *scratch*.  Somehow *scratch* is not killed by M-x
> project-kill-buffers.  I think it's because it doesn't have a
> buffer-file-name.  But then neither does the Eglot/Jsonrpc's "background
> buffers"!  It seems it is being targeted merely because it uses
> fundamental-mode, a most reasonable mode to use for exchanging messages
> via standard streams.
> 
> I guess this means that the hack below is enough to fix the issue, but
> it is also decidedly silly.

It's not much better than adding a function to 
kill-buffer-query-functions that returns nil. And/or behaves accordingly 
to eglot-autoshutdown.

> So please consider fixing this in project.el.  As Manuel pointed out,
> the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
> buffers and handles this whole thing very well.  We should just take a
> hint from it.

I'm unable to find that message.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 01:39:01 +0000
Resent-Message-ID: <handler.58839.B58839.16670075144541 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16670075144541
          (code B ref 58839); Sat, 29 Oct 2022 01:39:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 01:38:34 +0000
Received: from localhost ([127.0.0.1]:34625 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooany-0001BA-4o
	for submit <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:38:34 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:44701)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ooanv-0001Aw-3f
 for 58839 <at> debbugs.gnu.org; Fri, 28 Oct 2022 21:38:33 -0400
Received: by mail-wm1-f45.google.com with SMTP id
 bg9-20020a05600c3c8900b003bf249616b0so4881209wmb.3
 for <58839 <at> debbugs.gnu.org>; Fri, 28 Oct 2022 18:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=T1/g2QpkiYxmE9EqeXM0SBU9TGqsuE6ECzZds2++sfY=;
 b=b+QhHQOY/f48MKpm2ZiyPIQrCIxloMkfE6+CIuBxHcYC0Hv8jQGg8aYpgkHkLeuGU4
 HfSWvYhV4LYejdWTb5/8G1QmAn34OKpA54mLHzdUqVCUAmx0FcymiEdnGRuzqURe2afo
 q4ZmQs14qr/e7rTN+9cmgM7GSEaPjski8BXvdwRscL9j4JbliLn7uWKp8rz6bFAYuyE8
 lAdiURaHJgxBk4khUNcImnREbCEWa9FkUrKdQgPrRzxoW76lvGmBSrfKA8vvTma5xvUt
 fFpSVTkIMZ/n1JISbwWOoKBS/lMzmJZ1pv081FtRP+Fk6tgTfK0TuKWxtW/nQkeHv6Xg
 Aj0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=T1/g2QpkiYxmE9EqeXM0SBU9TGqsuE6ECzZds2++sfY=;
 b=3/+uWYUzDHrBcISAkM6rhdLlpvlbVFewsdZZ8dfrh1fjLapPehcG1e0MkoTRoz30mc
 Yhs5FNyrtooBIoqUMi9dQoFLMAaLmgWwQGQzu+FV35b5XQLjUuTWaZfiQ/WevrPfhDrt
 5RC2DQeXbfERQ5MbBFzCCAG+88F6DirxmRF1ox54guvASxsej6slTwZjMI4yaFb1zJ13
 Dhu+WVSp8wuW3Ob4pkrcX0mKdSRJmY1pQZ8xkpCtL21fTap+XZEq09EPch6mZ1vhKnep
 FaJLmd15RZDDCpBz81gO4+20Mjs2lzvqNofe8OR8LuPvB1CtifBCeWLCO6oSGQjjxZhL
 cWsg==
X-Gm-Message-State: ACrzQf3ve6UoofZZeJmpuSji+MIqWjdb1OsGQDpc53uRxx6w7/WjbZ4c
 BtwKvq564NE0AiTTSzCKT2Q=
X-Google-Smtp-Source: AMsMyM5kWPnEuBEAVYQn8DL1vDDAG2O2fsTgjBk+/jcAGa2YfJ1Hvk3DftFysnc6uk0nMuvEE9NNjw==
X-Received: by 2002:a05:600c:314f:b0:3c6:f27d:fa52 with SMTP id
 h15-20020a05600c314f00b003c6f27dfa52mr11087713wmo.20.1667007504982; 
 Fri, 28 Oct 2022 18:38:24 -0700 (PDT)
Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id
 m13-20020adffe4d000000b0022afcc11f65sm172855wrs.47.2022.10.28.18.38.23
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 28 Oct 2022 18:38:24 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> (Dmitry Gutov's
 message of "Sat, 29 Oct 2022 04:09:13 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
Date: Sat, 29 Oct 2022 02:39:34 +0100
Message-ID: <87v8o3wgq1.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> Sorry, I don't have Eglot checked out, or the time to test out the
> patch.

If you missed it, Eglot has been merged in lisp/progmodes/eglot.el.
There's not much point in testing that your patch: I can tell you right
away it doesn't work.

> I suppose. But the current criterion depends on the value of
> default-directory, and that makes it a match.

This criterion is wrong.  It makes mistakes.  But a criterion that is
"default-directory and is not hidden", though probably still not ideal,
but is definitely better.

>> If you agree that
>> there are such cases, then it should become clear that the buffer in
>> question must be at the top of that list.
>
> I'm not sure. Intuitively, I'd say that this buffer belongs to the
> project because it "services" the project. But if it were to work for
> several projects at the same time, I suppose I could say it doesn't
> belong to any particular one.

It indeed indirectly services just that one project: but it's also just
another object.  Eglot has lots of objects, variables etc., that
"service the project" and project.el fortunately isn't crazy to to touch
them.  The buffer in question is an implementation detail of jsonrpc.el.
It's not a buffer of interest in any way for the user or project.el's
manipulations.  And it's only a buffer because buffer's are Emacs'
common way of communicating with external entities, and jsonrpc.el uses
that technique.  But it could use some other way, say another
process-filter or function calls into C code of a dynamic library.
There would also be objects that indirectly "service" the project, but
not buffers.

>> There are more hints that the concept of "buffer belonging to a project"
>> was not fully thought through, even in cases unrelated to this bug
>> report.
>> * Take the *scratch* buffer.  It has a default-directory.  Does this
>>    also make *scratch* belong to a project?  It doesn't make any sense to
>>    me that it would.  Yet it is caught by project-buffers.
>
> *scratch* is not that special - you can create similar buffers at
>  will. So there are two ways of looking at that question. One can
>  create a "scratch" for a project, and it will be part of that
> project.
>
> If "~" (the usual value of default-directory in the original
> *scratch*) belongs to a project, then *scratch* also does.

I M-x cd in *scratch* all the time.  It's a global scratch pad,
now accessible via scratch-buffer everywhere.

>> * project-buffers also catches the one-time *Completions* buffers, the
>>    kind produced by hitting TAB after C-x p b.  If you type C-x p b
>>    again, it quite comically offers the stale *Completions* buffer as a
>>    candidate to switch to.
>
> We could make an exception for that too.
>
>> But back to *scratch*.  Somehow *scratch* is not killed by M-x
>> project-kill-buffers.  I think it's because it doesn't have a
>> buffer-file-name.  But then neither does the Eglot/Jsonrpc's "background
>> buffers"!  It seems it is being targeted merely because it uses
>> fundamental-mode, a most reasonable mode to use for exchanging messages
>> via standard streams.
>> I guess this means that the hack below is enough to fix the issue,
>> but
>> it is also decidedly silly.
>
> It's not much better than adding a function to
> kill-buffer-query-functions that returns nil. And/or behaves
> accordingly to eglot-autoshutdown.

You should think your solution through before comparing with the ones
provided so far, which have been tested.  Where in the source code would
you even set kill-buffer-query-functions?  Eglot code in jsonrpc.el??
Not to mention duplicating the eglot-autoshutdown check in unrelated
places is pretty ugly.

>> So please consider fixing this in project.el.  As Manuel pointed out,
>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
>> buffers and handles this whole thing very well.  We should just take a
>> hint from it.
>
> I'm unable to find that message.

In the original conversation: 

https://github.com/joaotavora/eglot/discussions/822#discussioncomment-2053395

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 06:39:01 +0000
Resent-Message-ID: <handler.58839.B58839.166702549910569 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166702549910569
          (code B ref 58839); Sat, 29 Oct 2022 06:39:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 06:38:19 +0000
Received: from localhost ([127.0.0.1]:34836 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oofU2-0002kO-VF
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 02:38:19 -0400
Received: from mout01.posteo.de ([185.67.36.65]:56339)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oofU0-0002k6-QO
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 02:38:17 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 35E6C240028
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 08:38:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667025491; bh=x0JCDjSusjc1lShQnGCFd69Y9IrqgQ1sT+L1crE4X5Y=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=pbMjb1dYGx1ZqvTeb8KMN/79qJcCxx7je74uTRUiOtjK8JPI8jz257Bjv5Th/8ETC
 1YxGO26g9VmTaiSHT4TZ+gSYPRlAH2gjmcmidbJGLaPOuxkMaL9Mf5/ZUptM5wchvo
 TlIb/Qudn09t9ukkf0t7jW8m3Aax94psRmnqWs0aOuiUyymD/BoaANJmzG0ttltzuo
 QfV1aAVBE/WXpfVkSsrgP5J7YOU0UBjt7KIg0FClGysOMOre+w13KItkOmF9epU7yZ
 a/gc5Z3gRTqsm/on2NcfJ1iktP2ijxKua3ov/7WTLViwHD4WTQuHb32/3ezyJ+Cujl
 NTv86O5teIfxQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4MzqVV10m2z9rxQ;
 Sat, 29 Oct 2022 08:38:09 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> (Dmitry Gutov's
 message of "Sat, 29 Oct 2022 04:09:13 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Sat, 29 Oct 2022 06:38:09 +0000
Message-ID: <87czab16em.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)


Dmitry Gutov <dgutov@HIDDEN> writes:

>> If you agree that
>> there are such cases, then it should become clear that the buffer in
>> question must be at the top of that list.
>
> I'm not sure. Intuitively, I'd say that this buffer belongs to the
> project because it "services" the project.=20

This is my perspective too.  I am under the impression that Jo=C3=A3o or
looking at this from a too technical perspective, and is missing the way
users perceive the situation.

If it is currently not possible, then this is an issue not an excuse
that we should tackle.  IMO having Eglot integrate with project.el ought
to be fine, since project is an Eglot dependency.

>                                            But if it were to work for
> several projects at the same time, I suppose I could say it doesn't
> belong to any particular one.

In that case I think a kind of "project reference counter" should ensure
that the server is only then killed when the last project using it is
killed (and the right user options are set).

(Btw., the tone of this discussion is a bit unpleasant, could we try and
focus on the issue at hand and do our best to understand each other?)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 11:00:02 +0000
Resent-Message-ID: <handler.58839.B58839.166704117912591 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166704117912591
          (code B ref 58839); Sat, 29 Oct 2022 11:00:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 10:59:39 +0000
Received: from localhost ([127.0.0.1]:35024 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oojYw-0003H1-PL
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 06:59:39 -0400
Received: from mail-wr1-f52.google.com ([209.85.221.52]:33494)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1oojYq-0003Gj-Gi
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 06:59:37 -0400
Received: by mail-wr1-f52.google.com with SMTP id h9so9643231wrt.0
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 03:59:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=/R/FHV07JsHzibV0Il62r5tQF/BapS20vM5OprGQMRw=;
 b=O9fbn74Ej0vYgb9em3VWoinHj/CmviesJsLXk6IWr8Qg6pABRv8lS51Mwo2blYzhOV
 iV3EqJ87X1H/dEQwoGp2B+AKDpfbchcLq1Pl1jrAHKedSb8u69uQE59rPkKXrGBzfUfE
 nq6qHj8RVPlQwAK6w0otjKpvJCNr+3xo97uepLaMukChNj585jc0B63NMis8auWyVCrl
 JXqKWOY5zcIAV1L4kXUnVn+wkHM6annL+oE3/GXWUh5F3CRNdu3iG68Kf7LZjNy5VCX9
 WDHGZo51LnSIG/L3Y0o0dEUozPWq/kKZtalTVSnkmO98bXSDBPYLcX6AIZBPqnaJUl1t
 U1Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=/R/FHV07JsHzibV0Il62r5tQF/BapS20vM5OprGQMRw=;
 b=g683nAx2O4fgllZ2IyrMaCnOf8lN8V7FJG41kK5M2Uujvkl8O2l6VfVfK0d5L9unRy
 TQKzMII9Htzqmb3El0DEFw35+qGarAKIgevcyq1PZfpILI0uMzrYFOa6+Bc9W6/PHNoE
 jaEs9dN8eI8fZ0Y2soSPtfGicHqtMEf2smdiCTjJuFci9ZxgIkuLv1NLwYFeTEuXyhsi
 hKuHatrxkNJ9N4ANIBs8Sqy3KXqUtEFytg3Mh4Qf+v9L8L9Kfp+m30O9B+7w6D/6XctL
 2ULNvczhEpntaw31fxjIVmHIaAijzFPSHNXxA5tx6Ioo3oWLakqBvB6YU46vQlWOzjtG
 CyXQ==
X-Gm-Message-State: ACrzQf0BV4bEJjaftuf1UNZGyIlgOIBkRGywH8of/fFq6uOaIfoyOVYZ
 kSc6BLi/SCQR8zxX2+xCnM8=
X-Google-Smtp-Source: AMsMyM4DveLiLIOfH4LfEY5cWSlpO35A8itpZRXEA3fDnaTh9KtheqdDB48A6AMe/+EI7jY2NlD6mw==
X-Received: by 2002:adf:d089:0:b0:236:558b:abc8 with SMTP id
 y9-20020adfd089000000b00236558babc8mr2042465wrh.231.1667041166424; 
 Sat, 29 Oct 2022 03:59:26 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 u7-20020a05600c19c700b003c6c2ff7f25sm1375551wmq.15.2022.10.29.03.59.25
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 29 Oct 2022 03:59:26 -0700 (PDT)
Message-ID: <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN>
Date: Sat, 29 Oct 2022 13:59:24 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87czab16em.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87czab16em.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 29.10.2022 09:38, Philip Kaludercic wrote:
>>                                             But if it were to work for
>> several projects at the same time, I suppose I could say it doesn't
>> belong to any particular one.
> In that case I think a kind of "project reference counter" should ensure
> that the server is only then killed when the last project using it is
> killed (and the right user options are set).

I suppose. But that kind of arrangement would require a project-specific 
hook.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 11:05:02 +0000
Resent-Message-ID: <handler.58839.B58839.166704144513143 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166704144513143
          (code B ref 58839); Sat, 29 Oct 2022 11:05:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:04:05 +0000
Received: from localhost ([127.0.0.1]:35033 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oojdF-0003Pv-7F
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:04:05 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:56182)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oojdD-0003PP-Fr
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:04:04 -0400
Received: by mail-wm1-f54.google.com with SMTP id t4so4535999wmj.5
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 04:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=KAp6Kqn3wzzCzGQdD8fPEm3LloIRZyT69+14aav0k9w=;
 b=pZIpEaWRotFS3Nk4MF/sBdRvc+3QII/qPtiGS1MObGfISP/xs1y52mK+3Wb9fy1Vvf
 KsiiiweOdhc8BRa1w7HhSdEFby//9ZeD5owCwdiA3Fcm2NxdX2Cyd1EBlpuao6n73OSO
 pw0EfiqBKmAwtJebYlUPVKymdYFyQlD2Q0ydfp155cN0oBtknXesB19rZBVnTLEyggfL
 KWJWw1azUGTJB3/fUfc584LGc2Lj3+Ds8EHY8NVJooqIWVa3swAQk3AJLtMslJs3hYD7
 PkerCVwuqEn6OEj0w57oBchDP/0Zd7jA/u5+YdPwMCJ1S1lX8xWBAevJQ/HDzHTwXA+M
 qXCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=KAp6Kqn3wzzCzGQdD8fPEm3LloIRZyT69+14aav0k9w=;
 b=Aq6tVxi96tpi73/tTvLTACyLHSxqYkiH++bUfBusdOuyGpcp/V7UGf7ysXK+vuOTXv
 KEq906wAcm3361vsRow7pR0XkzKc5IQXOziFATU52RmBgDxpvfEaSb88lBFKoWhci+VC
 3UOcgYxRTlv2tiwZqZTKh7QnWvr4ZO71h0hWpdlwWLDawfTFLwKzoBKCYmFfBerNx8So
 QyUXn1DRWJ0tswI6Xs2V0hqxHOaLb+EbHL4iCoaHjGafonaVG02ctUo9MJh89ED9SFxj
 P/mqkuUwq8alMYPUj0OnISvS4lzd9x9G4y12F0cVgjTCNcuXZcKXGaR+BHR9AtPjVvsS
 JQuA==
X-Gm-Message-State: ACrzQf0AywuZ/CnmnGE55UsiAmHP5San5qQBFE/rcPrMYYDMiAir8JPZ
 5mDQUpj+CFEyn74L2G6XzvU=
X-Google-Smtp-Source: AMsMyM5aqXr6GxRthvrdaP+WX22GE+f5e6VSOAXpQmDpgY19XI+48j3WNDdUCOCb3jzBL8f4FsiHUg==
X-Received: by 2002:a1c:f70f:0:b0:3cf:620f:fc4c with SMTP id
 v15-20020a1cf70f000000b003cf620ffc4cmr2155891wmh.168.1667041437637; 
 Sat, 29 Oct 2022 04:03:57 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
 by smtp.gmail.com with ESMTPSA id
 m17-20020a5d56d1000000b0022cc6b8df5esm1266704wrw.7.2022.10.29.04.03.56
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Oct 2022 04:03:57 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87czab16em.fsf@HIDDEN> (Philip Kaludercic's message of "Sat, 
 29 Oct 2022 06:38:09 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87czab16em.fsf@HIDDEN>
Date: Sat, 29 Oct 2022 12:05:07 +0100
Message-ID: <87mt9ex53w.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

> This is my perspective too.  I am under the impression that Jo=C3=A3o or
> looking at this from a too technical perspective, and is missing the way
> users perceive the situation.

You're not reading what I am writing.  Here's a summary again:

1. buffer is implementation detail.  Users don't see it any more than
   they see values of internal global variables.  In fact I think
   lsp-mode, perfectly legitimately, uses (or used to use) a process,
   but doesn't make use of its buffer at all.  It uses a special filter
   that processes and stores strings in global variables.  These
   variables also "service a project" and occupy resources but I doubt
   project.el has a claim to their ownership.  jsonrpc.el use buffers
   internally, just because that was deemed more convenient and
   efficient for parsing.

2. Users like you who are interested in controlling the RAM and CPU
   resources taken by the running a LSP server, even when Emacs is not
   visiting any files in a project should use the variable
   eglot-autoshutdown.  This variable is exactly what you want.  There
   is no other "user perception" here that I have been made aware of.

3. Even if we were to neglect point 1, as you seem to be, fixing things
   with kill-buffer-query-functions duplicates programming logic, which
   is very bad.  And most important of all, there's no place to put the
   reference to kill-buffer-query-functions short of many lines
   completely throwing away encapsulation and unique resource ownership.

If this is too technical, then I'm sorry: this is a technical mailing
list.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 11:12:01 +0000
Resent-Message-ID: <handler.58839.B58839.166704188913792 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166704188913792
          (code B ref 58839); Sat, 29 Oct 2022 11:12:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:11:29 +0000
Received: from localhost ([127.0.0.1]:35037 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oojkP-0003aO-4k
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:11:29 -0400
Received: from mail-ot1-f44.google.com ([209.85.210.44]:45667)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oojkN-0003aB-HK
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:11:28 -0400
Received: by mail-ot1-f44.google.com with SMTP id
 m5-20020a9d73c5000000b0066738ce4f12so4334467otk.12
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 04:11:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=wGKttaIpEohh81NSTR4BbhLEmFkhEhmEQDPfteoV32U=;
 b=VdBoSyzWtmSplvwWfmR83qwQiERoMpsbipC4sJAXArfXbmoNGVuGPNAhP91BOY3K/L
 BGz4Fkn8YHxGfOvCDbZp5LyzfabJi2vGMWaIVIPHewLykcloZI6NiZqVjH58mKF0wdnv
 w4NHHaHJZ7Z/fCfL/TLQ+TRovcFJcrdzVVA6a3y9E3O1Jd4k4ZaXFi7HhcjcqsO4EU3E
 BD0/0OTSLUWAQUY9Mm44dPDYv4a/LBEe3kG/4I1FOxsyAVPVnrldSi6/zXZjCT+q7xp2
 oZ7MezkkWvethabRjI4xZZ1ZLNehC84WTxU2Ky4V0qDLosSTGys3bLCgoh0ZAk56KNTd
 SrcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=wGKttaIpEohh81NSTR4BbhLEmFkhEhmEQDPfteoV32U=;
 b=MSfS/0Xd+Hx3X1uiV8xd1olnZybB0vPj/J6DI/EZpR+/10CKs/EFGtquWBCyfu68rQ
 gm220/Wm6pK4CipdeF/XUdvEgQOM35BNo0rSf0FXH09mgHV1QWwycUsWlNCZmrPyvB7q
 hE2Jqj5X10g+xSkXVNn9hOGZbO51dXWnpWtj+Br2qOTu8HOR/yUjYqP8OikQlG8kOnju
 bwvthZgeRv3EfKta4YLQf7+f4K5NEV0HrIChpX7PR1Uwq0yust4vPiKrHFWbI5TrfuvF
 4z8ry9a70dwUZkLircmePCcFDNTnXXR+VQuIKhveoBLL8nAf1D1BBxwcVe+arjjJ57L4
 5QFw==
X-Gm-Message-State: ACrzQf3RYlckBE6LjOakVNYEyoIHPJ4PtDM5LbgkFiyQswX4d4uMllva
 IhcPnkxC7HC2M+jkJqGJ3xwTomwNxZ9uJB4Glqo=
X-Google-Smtp-Source: AMsMyM48oGcAeXaFj8DwLGCADnM/Z5Onah4XI8a64JnH63UMYInCb4qIEfEXQqn05t0l6L4XNa4FNm4kkdwNrdBj9pQ=
X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id
 23-20020a9d0117000000b00666e09d577emr1865207otu.93.1667041881872; Sat, 29 Oct
 2022 04:11:21 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87czab16em.fsf@HIDDEN> <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN>
In-Reply-To: <5ea24d00-2461-7901-86d6-6bdb01f30020@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Sat, 29 Oct 2022 12:12:22 +0100
Message-ID: <CALDnm505G7NY+qWLiTA69D6FZZfX1L9OtTf=TGADBEqKDeHKOA@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000031db9105ec2a6f33"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000031db9105ec2a6f33
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 29, 2022 at 11:59 AM Dmitry Gutov <dgutov@HIDDEN> wrote:

> On 29.10.2022 09:38, Philip Kaludercic wrote:
> >>                                             But if it were to work for
> >> several projects at the same time, I suppose I could say it doesn't
> >> belong to any particular one.
> > In that case I think a kind of "project reference counter" should ensur=
e
> > that the server is only then killed when the last project using it is
> > killed (and the right user options are set).
>
> I suppose. But that kind of arrangement would require a project-specific
> hook.
>

There isn't any one-to-many correspondence between LSP servers
and projects. I don't envision adding that to Eglot anytime soon: it seems
completely useless. So what problem are you even solving with this
"reference counter" talk?

Jo=C3=A3o

--00000000000031db9105ec2a6f33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Sat, Oct 29, 2022 at 11:59 AM Dmitry Gutov &lt;<a href=3D"mailto:=
dgutov@HIDDEN">dgutov@HIDDEN</a>&gt; wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">On 29.10.2022 09:38, Philip Kaludercic wr=
ote:<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0But if it were to work for<br>
&gt;&gt; several projects at the same time, I suppose I could say it doesn&=
#39;t<br>
&gt;&gt; belong to any particular one.<br>
&gt; In that case I think a kind of &quot;project reference counter&quot; s=
hould ensure<br>
&gt; that the server is only then killed when the last project using it is<=
br>
&gt; killed (and the right user options are set).<br>
<br>
I suppose. But that kind of arrangement would require a project-specific <b=
r>
hook.<br>
</blockquote></div><div><br></div><div>There isn&#39;t any one-to-many corr=
espondence between LSP servers <br></div><div>and projects. I don&#39;t env=
ision adding that to Eglot anytime soon: it seems</div><div>completely usel=
ess. So what problem are you even solving with this</div><div>&quot;referen=
ce counter&quot; talk?<br></div><div><br></div><div>Jo=C3=A3o<br></div></di=
v>

--00000000000031db9105ec2a6f33--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 11:28:01 +0000
Resent-Message-ID: <handler.58839.B58839.166704286315280 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166704286315280
          (code B ref 58839); Sat, 29 Oct 2022 11:28:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 11:27:43 +0000
Received: from localhost ([127.0.0.1]:35043 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ook06-0003yN-Pe
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:27:43 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:54833)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1ook03-0003y5-7A
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 07:27:41 -0400
Received: by mail-wm1-f52.google.com with SMTP id t1so877760wmi.4
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 04:27:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=u5YgxzYMcnD81UP7fVRKXtSlFvPGLUkUz6hTa6UL/2A=;
 b=MuHuvpsNbJdE2oG8qnup87ioYOmFpLCWVd43OiTwG4ZCNIx+DqbJ5FHNYochHkm+pw
 iZjgWC2AOAGERGGxuVOeQPis4dIgabT32Oqr2lFG0U9SKE5AuxPAAfCvynZtSg9w5G6K
 kbtY2ES5hXTVoTRg0AKFqYMD0ps8mFr0nRA0Rs2TfAI7kd95Re+6Ml8VI7qbr9Gun/pr
 cXGYU+Zh1oDt362uwpruFsodV7odSaSGAM4bp45z1UOEqKpWgATLqGqbhCMfjQQtiXg5
 ILFLh2ZwiwVY1vgVUdNpERSguiqqLLAsT7+T3odJpCIvSfis6LtUFww7E58f6DsRIplU
 rdjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=u5YgxzYMcnD81UP7fVRKXtSlFvPGLUkUz6hTa6UL/2A=;
 b=K3DiTpj8dDcYiKbTfyprAqUHBFVZYBo8tbbhbpquwqg6ypXQZq/NQAh6UH0JmYJ7ln
 GH5HAqEwoOkkioGbDxt538Pt3UDy7xvpwKp5JjNXsYynWSmmr/zTXOWo34X5X7xnvfiw
 54Z8hfKDtb+PdGmZWDYy9rc8ST+y2fa8cG47g4SRFdnlbbjr4uHIaHUQfSbl0Cbi8Jzk
 dqHvAwfuyKZf8BDIZMflbxZb3saYWtvHSM1JjjbfYS1ctB1GumqSXySNFbWBLzHHibFD
 Mz8HKQr5oJ9FdwfmhuhxgjTCv4Spo4D2oodn+ma88Z4MwaNtjfdouOfgTKZTquwfZUJg
 9KBg==
X-Gm-Message-State: ACrzQf3fwIivgOBjrHxR/d+pwlf8g577vThhvlP/pInYyOudCPFaR1qf
 RnJbDpWFyliKm8aswE3DZxU=
X-Google-Smtp-Source: AMsMyM5DB+tUllkZzddfguEyP+2zIUBpaQmmlbgSv2LYSK3HbrWDyMdkVDhlQw77GF114VNRvPmwnA==
X-Received: by 2002:a05:600c:42c9:b0:3cf:69d4:72d9 with SMTP id
 j9-20020a05600c42c900b003cf69d472d9mr305765wme.93.1667042853255; 
 Sat, 29 Oct 2022 04:27:33 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 ck1-20020a5d5e81000000b002366553eca7sm1316589wrb.83.2022.10.29.04.27.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 29 Oct 2022 04:27:32 -0700 (PDT)
Message-ID: <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
Date: Sat, 29 Oct 2022 14:27:31 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87v8o3wgq1.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 29.10.2022 04:39, João Távora wrote:

> If you missed it, Eglot has been merged in lisp/progmodes/eglot.el.
> There's not much point in testing that your patch: I can tell you right
> away it doesn't work.

I was thinking that somebody motivated could easily update it to be 
functional.

>> I suppose. But the current criterion depends on the value of
>> default-directory, and that makes it a match.
> 
> This criterion is wrong.  It makes mistakes.  But a criterion that is
> "default-directory and is not hidden", though probably still not ideal,
> but is definitely better.

This whole discussion is about different shades of OCD. One party wants 
to clean up as much as possible, another says don't touch my things.

I don't think there is an objective "right" way to do things, only 
something we're able to agree on in the end. I don't really use this 
feature much myself: if you're able to come to an agreement with Philip 
(who took the initiative on adding that command), I'll be happy.

>>> If you agree that
>>> there are such cases, then it should become clear that the buffer in
>>> question must be at the top of that list.
>>
>> I'm not sure. Intuitively, I'd say that this buffer belongs to the
>> project because it "services" the project. But if it were to work for
>> several projects at the same time, I suppose I could say it doesn't
>> belong to any particular one.
> 
> It indeed indirectly services just that one project: but it's also just
> another object.  Eglot has lots of objects, variables etc., that
> "service the project" and project.el fortunately isn't crazy to to touch
> them.  The buffer in question is an implementation detail of jsonrpc.el.
> It's not a buffer of interest in any way for the user or project.el's
> manipulations.  And it's only a buffer because buffer's are Emacs'
> common way of communicating with external entities, and jsonrpc.el uses
> that technique.  But it could use some other way, say another
> process-filter or function calls into C code of a dynamic library.
> There would also be objects that indirectly "service" the project, but
> not buffers.

Most object types are garbage-collected when no live reference to them 
remains. That's not the case for buffers.

Is the buffer in question killed when the user calls 'M-x 
eglot-shutdown'? If so, consider that, after the user calls 
project-kill-buffers, there won't be any buffers remaining that belong 
to that project, that the user would be able to call 'M-x 
eglot-shutdown' from.

>>> There are more hints that the concept of "buffer belonging to a project"
>>> was not fully thought through, even in cases unrelated to this bug
>>> report.
>>> * Take the *scratch* buffer.  It has a default-directory.  Does this
>>>     also make *scratch* belong to a project?  It doesn't make any sense to
>>>     me that it would.  Yet it is caught by project-buffers.
>>
>> *scratch* is not that special - you can create similar buffers at
>>   will. So there are two ways of looking at that question. One can
>>   create a "scratch" for a project, and it will be part of that
>> project.
>>
>> If "~" (the usual value of default-directory in the original
>> *scratch*) belongs to a project, then *scratch* also does.
> 
> I M-x cd in *scratch* all the time.  It's a global scratch pad,
> now accessible via scratch-buffer everywhere.

And I don't have any projects that "~" belongs to.

>>> * project-buffers also catches the one-time *Completions* buffers, the
>>>     kind produced by hitting TAB after C-x p b.  If you type C-x p b
>>>     again, it quite comically offers the stale *Completions* buffer as a
>>>     candidate to switch to.
>>
>> We could make an exception for that too.
>>
>>> But back to *scratch*.  Somehow *scratch* is not killed by M-x
>>> project-kill-buffers.  I think it's because it doesn't have a
>>> buffer-file-name.  But then neither does the Eglot/Jsonrpc's "background
>>> buffers"!  It seems it is being targeted merely because it uses
>>> fundamental-mode, a most reasonable mode to use for exchanging messages
>>> via standard streams.
>>> I guess this means that the hack below is enough to fix the issue,
>>> but
>>> it is also decidedly silly.
>>
>> It's not much better than adding a function to
>> kill-buffer-query-functions that returns nil. And/or behaves
>> accordingly to eglot-autoshutdown.
> 
> You should think your solution through before comparing with the ones
> provided so far, which have been tested.  Where in the source code would
> you even set kill-buffer-query-functions?  Eglot code in jsonrpc.el??

Same place you changed the major mode in the last patch: jsonrpc.el. If 
jsonrpc.el doesn't want its buffers to be killed, it could set that up 
as described above, through kill-buffer-query-functions.

> Not to mention duplicating the eglot-autoshutdown check in unrelated
> places is pretty ugly.
> 
>>> So please consider fixing this in project.el.  As Manuel pointed out,
>>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
>>> buffers and handles this whole thing very well.  We should just take a
>>> hint from it.
>>
>> I'm unable to find that message.
> 
> In the original conversation:
> 
> https://github.com/joaotavora/eglot/discussions/822#discussioncomment-2053395

It's a reasonable approach too. Just not the one we took here. It would 
make sense to try to make it work first.

And if we're comparing different commands similar to this one, how does 
`projectile-kill-buffers' behave?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 12:16:02 +0000
Resent-Message-ID: <handler.58839.B58839.166704574428525 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166704574428525
          (code B ref 58839); Sat, 29 Oct 2022 12:16:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 12:15:44 +0000
Received: from localhost ([127.0.0.1]:35095 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ookka-0007Py-8L
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 08:15:44 -0400
Received: from mail-wm1-f53.google.com ([209.85.128.53]:35426)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ookkY-0007Pk-19
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 08:15:43 -0400
Received: by mail-wm1-f53.google.com with SMTP id
 m29-20020a05600c3b1d00b003c6bf423c71so8075235wms.0
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 05:15:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=JflwJd7AS12iBK+7GwmZL4ehrIH1iabfdwaZNuJowqE=;
 b=K0tBLKI/Vc718Re69xv6/R3e+uZ/YSMOwn0GqhKk7lSzNEj26vTzv4Im/3KLrgjT9V
 +WtVboBUGio6oE4aqZSbQZXsbl1aDdp1AJoZS1kRapC9cKu1Cab3JaIWz66xFuJijTmd
 Ax2CaH9LmuhaaM5tJsYylfObt/xxagxWY+ZNYoRHZ6JGZ9hwMOyJYoE1DuGrMVjXwctr
 fdXSJV/yOmxugNp4EmrmfTIOA/of3m5vypzR1fF/VMHoAkTp3CULwqTI17Ooz6w8QmqF
 jlOeUki65/udXhbiCF7UwbzJJl62DBePe2INs5ULUeB35RZXRmSw5ThXeJlyTcUhNm2O
 Z+cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=JflwJd7AS12iBK+7GwmZL4ehrIH1iabfdwaZNuJowqE=;
 b=wMEBmniNRC26nBrNQqfXR5FNKfyJ3yNlyfp5hzsdaEsAbChwgtBWndCYH7B3gg4qRl
 5ULIYk4P/advhn9gmotYIeVvD97sCjFqkdYIuo3hEMWuAYCPbu/iS3AH+qNph4NocYSj
 RxaztNlrdXKyzhRRBN+ToEGdvpSpf7inwgJS1Kzwb83HVNGdXPNafMfUJNX/q4Ip6T2d
 TAQXBeYoP2pSaChOVMRJkPV3VozMsLJ61eOS1iUBEb49LX8gGWDeQG8lD/Xam4gTFkEA
 ChyyXIlnlKtyiASTAuXl956RK9fvhyldtQbfstWT1ivhyzlZ9J+Ek7RswAVJ/vGy80RH
 uUSw==
X-Gm-Message-State: ACrzQf2lDz2fR34SO4l1Dy92BPOZ28FvRcxFOB0hn194QxP/GCL8HWwc
 PrjiJchJ7sGfDfYt9wegC1xTMccYJiA=
X-Google-Smtp-Source: AMsMyM4xlFrLbJqVeNMVYbslMfZPKtsaavdFzbAFds4qZd/p7K7xcvScfyREuqLdTEa5D3bcbfeSBw==
X-Received: by 2002:a05:600c:689b:b0:3c2:fd6e:1fe5 with SMTP id
 fn27-20020a05600c689b00b003c2fd6e1fe5mr2287764wmb.99.1667045735682; 
 Sat, 29 Oct 2022 05:15:35 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
 by smtp.gmail.com with ESMTPSA id
 bx7-20020a5d5b07000000b00228cbac7a25sm1367717wrb.64.2022.10.29.05.15.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Oct 2022 05:15:35 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> (Dmitry Gutov's
 message of "Sat, 29 Oct 2022 14:27:31 +0300")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
Date: Sat, 29 Oct 2022 13:16:45 +0100
Message-ID: <87ilk2x1si.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> This whole discussion is about different shades of OCD. One party
> wants to clean up as much as possible, another says don't touch my
> things.

I think this discussion is about mistaking resource access for resource
ownership.  Just because project.el or any Lisp package can access the
full list of buffers, doesn't mean it can do whatever it wants with
them.  Just like a routine in a C program can see the full memory
address space of the process, and possibly even form pointers to these
bytes, but it shouldn't rely on their values and certainly can't free()
what it didn't malloc().

> I don't think there is an objective "right" way to do things, only
> something we're able to agree on in the end. I don't really use this
> feature much myself: if you're able to come to an agreement with
> Philip (who took the initiative on adding that command), I'll be
> happy.

I think the command is pretty useful.  But perhaps, I'm just guessing
here, Philip is focusing too much it as if it were the only sanctioned
way for Emacs users to stop working on a given set of files in a
programming project and clean up.

So project-k-buffers is useful but it doesn't have that exclusive. If it
did (but I don't think it will ever have) then Eglot could indeed attach
connection management to it.

> Most object types are garbage-collected when no live reference to them
> remains. That's not the case for buffers.

Because there is always at least one live reference to them, obviously.
But why does this matter?  In this buffer's case there are probably even
more.  One of these references is the one that Eglot and Jsonrpc control
the program or network process.  This is held in global variable.  There
are no resource leaks, as far as I know.

> Is the buffer in question killed when the user calls 'M-x
> eglot-shutdown'? If so, consider that, after the user calls
> project-kill-buffers, there won't be any buffers remaining that belong
> to that project, that the user would be able to call 'M-x
> eglot-shutdown' from.

Are you sure?  Well you should actually try M-x eglot-shutdown and see
what happens then :-)

>> I M-x cd in *scratch* all the time.  It's a global scratch pad,
>> now accessible via scratch-buffer everywhere.
> And I don't have any projects that "~" belongs to.

Neither do I.  But when I M-x cd to other places, project.el thinks that
scratch belongs to that project.  It doesn't, I keep stuff of various
projects in it.

> Same place you changed the major mode in the last patch:
> jsonrpc.el. If jsonrpc.el doesn't want its buffers to be killed, it
> could set that up as described above, through
> kill-buffer-query-functions.

Why should resource owners go to the hassle of whitelisting themselves
from other packages' newfound disregard for private property?  Not to
mention jsonrpc.el wants its buffers to be killed in controlled
circunstances.  So now it would have to "unprotect itself" in those
places.  I can't even think of adjectifying this design, let alone deal
with the corner cases.

>>>> So please consider fixing this in project.el.  As Manuel pointed out,
>>>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills project
>>>> buffers and handles this whole thing very well.  We should just take a
>>>> hint from it.
>>> I'm unable to find that message.
>> In the original conversation:
>> https://github.com/joaotavora/eglot/discussions/822#discussioncomment-20=
53395
>
> It's a reasonable approach too. Just not the one we took here. It
> would make sense to try to make it work first.

Ibuffer understands ownership, so it comes with bug-free and
hassle-free.  Sounds more than "reasonable" to me.

Just commit the original tested patch I gave you that exempts hidden
buffers without buffer-file-name from project-buffers.  Philip's command
will keep working perfectly and we can close this bug.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 14:34:02 +0000
Resent-Message-ID: <handler.58839.B58839.166705399110408 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166705399110408
          (code B ref 58839); Sat, 29 Oct 2022 14:34:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 14:33:11 +0000
Received: from localhost ([127.0.0.1]:36304 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oomta-0002hn-HG
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 10:33:10 -0400
Received: from mout01.posteo.de ([185.67.36.65]:41713)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oomtV-0002hG-VZ
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 10:33:08 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id EE0C1240026
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 16:32:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667053980; bh=S2Rv0NtXlcFjdeTC3LBawUbreaRVfgYv67zAmJ0gFoY=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=gxElmpWRHJYBTzM2HV0/m755sROgtM/TgV68QtGLFYd8bu35+FXLu7EWuXZR6q4yt
 gGY4J9EIfUnX4F7RZMVQ8fiuHrtTmQJEh/27vpanCDqSPidmcNA66Z1mDT8I8/rRwL
 Zv6zG2ZbhHG3a7kN/jyPEe6Ti/LY6AmA7G7vt4SNUae5Of1mAtySoxam5uZgMqQ9xS
 69UoAMqDwrsufaL0lv7Rjb47TW2jBAuhfZUOaw669k1Bf6GAv8nl+KZqEtdlwwH9tY
 y+Kdu29WftQxEs8u5UezLHF8283ze0qEAGKGwmfrXtrr/DKwb3wy10cJuM5/M/I9RV
 c6RQawfsyqDbA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N022L4jLxz9rxF;
 Sat, 29 Oct 2022 16:32:56 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87ilk2x1si.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 29 Oct 2022 13:16:45 +0100")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Sat, 29 Oct 2022 14:32:50 +0000
Message-ID: <871qqq7l9p.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> This whole discussion is about different shades of OCD. One party
>> wants to clean up as much as possible, another says don't touch my
>> things.
>
> I think this discussion is about mistaking resource access for resource
> ownership.  Just because project.el or any Lisp package can access the
> full list of buffers, doesn't mean it can do whatever it wants with
> them.  Just like a routine in a C program can see the full memory
> address space of the process, and possibly even form pointers to these
> bytes, but it shouldn't rely on their values and certainly can't free()
> what it didn't malloc().

But to extend this metaphor, if I kill a programm that allocated malloc,
I would expect that memory to be cleaned up.

>> I don't think there is an objective "right" way to do things, only
>> something we're able to agree on in the end. I don't really use this
>> feature much myself: if you're able to come to an agreement with
>> Philip (who took the initiative on adding that command), I'll be
>> happy.
>
> I think the command is pretty useful.  But perhaps, I'm just guessing
> here, Philip is focusing too much it as if it were the only sanctioned
> way for Emacs users to stop working on a given set of files in a
> programming project and clean up.

Of course it isn't, it is just my prefered way and Eglot breaks it.

> So project-k-buffers is useful but it doesn't have that exclusive. If it
> did (but I don't think it will ever have) then Eglot could indeed attach
> connection management to it.
>
>> Most object types are garbage-collected when no live reference to them
>> remains. That's not the case for buffers.
>
> Because there is always at least one live reference to them, obviously.
> But why does this matter?  In this buffer's case there are probably even
> more.  One of these references is the one that Eglot and Jsonrpc control
> the program or network process.  This is held in global variable.  There
> are no resource leaks, as far as I know.
>
>> Is the buffer in question killed when the user calls 'M-x
>> eglot-shutdown'? If so, consider that, after the user calls
>> project-kill-buffers, there won't be any buffers remaining that belong
>> to that project, that the user would be able to call 'M-x
>> eglot-shutdown' from.
>
> Are you sure?  Well you should actually try M-x eglot-shutdown and see
> what happens then :-)
>
>>> I M-x cd in *scratch* all the time.  It's a global scratch pad,
>>> now accessible via scratch-buffer everywhere.
>> And I don't have any projects that "~" belongs to.
>
> Neither do I.  But when I M-x cd to other places, project.el thinks that
> scratch belongs to that project.  It doesn't, I keep stuff of various
> projects in it.

I agree, this is bad, but that can easily be solved by adding
`lisp-interaction-mode' to the list of major modes that are not killed.

>> Same place you changed the major mode in the last patch:
>> jsonrpc.el. If jsonrpc.el doesn't want its buffers to be killed, it
>> could set that up as described above, through
>> kill-buffer-query-functions.
>
> Why should resource owners go to the hassle of whitelisting themselves
> from other packages' newfound disregard for private property?  Not to
> mention jsonrpc.el wants its buffers to be killed in controlled
> circunstances.  So now it would have to "unprotect itself" in those
> places.  I can't even think of adjectifying this design, let alone deal
> with the corner cases.
>
>>>>> So please consider fixing this in project.el.  As Manuel pointed out,
>>>>> the venerable ibuffer.el's ibuffer-kill-filter-group also kills proje=
ct
>>>>> buffers and handles this whole thing very well.  We should just take a
>>>>> hint from it.
>>>> I'm unable to find that message.
>>> In the original conversation:
>>> https://github.com/joaotavora/eglot/discussions/822#discussioncomment-2=
053395
>>
>> It's a reasonable approach too. Just not the one we took here. It
>> would make sense to try to make it work first.
>
> Ibuffer understands ownership, so it comes with bug-free and
> hassle-free.  Sounds more than "reasonable" to me.
>
> Just commit the original tested patch I gave you that exempts hidden
> buffers without buffer-file-name from project-buffers.  Philip's command
> will keep working perfectly and we can close this bug.

So if I understand correctly, with `eglot-autoshutdown' enabled as soon
as all the buffers have been killed, the server will also shut down,
right?

Regarding the patch itself, I think it would be better to use
`project-kill-buffer-conditions', so that if a project.el backend
defines a new implementation for `project-buffers', the issue doesn't
pop up again.

> Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 20:38:01 +0000
Resent-Message-ID: <handler.58839.B58839.166707582532063 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166707582532063
          (code B ref 58839); Sat, 29 Oct 2022 20:38:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 20:37:05 +0000
Received: from localhost ([127.0.0.1]:36772 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oosZk-0008L3-KA
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 16:37:05 -0400
Received: from mail-wr1-f50.google.com ([209.85.221.50]:45941)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oosZh-0008KR-Rk
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 16:37:02 -0400
Received: by mail-wr1-f50.google.com with SMTP id y16so10782466wrt.12
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 13:37:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=;
 b=qNLd4EcNO40+O9AYVps0Plyp88JHPRIt/zmoJCBXWfrmf1AddzGykFwwtjJjXGewDk
 212BMldZ/3/W/YQ4sfamBq1RUq+l3cX4Jaa4hAvkfa86YqBS9Tj6BfOVh7BIs5CyWOb+
 AB2zXR7uEg5BhW1wvCk9vQEnawLaDm8DdRmF9vHShfWrdW46cJlrcznpdDhh1NsrbNCy
 O447yepAKQXSnVbhY5N+8CfO2ek3xFwNh7Wx3bvXrkHOJ/8DI57p8mO0q18dKZhIb+rs
 1iCYiTxgcfggJPxMISwNrjyhb9xO2ySQHDRf/TLO+V7I9SyjGtEJbFMX9ifYfAfZFkS1
 48oQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=S0ouhzMDaqav1T/5iCcQZG2iVhgyQDI0e+eQU6vfY9E=;
 b=FtU6RFiDXlARz/OzC9SYs43MCi6klMMkGlMrtVm9NkkNW0lfQ6hpINhvOJrCWHhSLr
 wcgE2rI4xpGa1ghYSFcq45077fjO0iheC3KEaXcHjePk/RkHJVk4MhVMkELWyeftUn4W
 TUhHb4nsjyjE01siM+yBDwMM9N9p04Sxe8+axOrZckiOW6sZQ5pNvWum14sp4H2vprI2
 /otA0hKszgiLG2TimzhTx7m5LuYY0hVO9T3V+/h2JgE77bLSkKnyyRZ+lN9uduI38pO8
 bxn1gSfRTBpIcHLFUzajlFZB8aRh0+6j4/Mr4/cbCrnjFhb+1Ebaey2yvOqwEwo8WUIH
 QSzw==
X-Gm-Message-State: ACrzQf0vBp2xPtJgu9SlcUNdMaExOEnZQVk5i2ftuePxNNYzDmyUSsTC
 pUv9moZfXtf1VSPK12OW/ALV5p9hgDg=
X-Google-Smtp-Source: AMsMyM4968E4aLqNhVg/dPP61yor3/c0YSPlmXhACQh813mOGgCX39DrRH7W0/imzue6gyQozzKtYQ==
X-Received: by 2002:adf:e385:0:b0:236:91a6:bd1b with SMTP id
 e5-20020adfe385000000b0023691a6bd1bmr3230197wrm.278.1667075815494; 
 Sat, 29 Oct 2022 13:36:55 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
 by smtp.gmail.com with ESMTPSA id
 bj29-20020a0560001e1d00b002366b241cf3sm2352665wrb.35.2022.10.29.13.36.54
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Oct 2022 13:36:54 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <871qqq7l9p.fsf@HIDDEN> (Philip Kaludercic's message of "Sat, 
 29 Oct 2022 14:32:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
Date: Sat, 29 Oct 2022 21:38:04 +0100
Message-ID: <87eduqwekz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

>> bytes, but it shouldn't rely on their values and certainly can't free()
>> what it didn't malloc().
> But to extend this metaphor, if I kill a programm that allocated malloc,
> I would expect that memory to be cleaned up.

Yes, but to kill a process you have to own it.  project.el is not the
owner (not even a co-owner) of Eglot LSP internal buffers, and so it
can't kill them.

>> I think the command is pretty useful.  But perhaps, I'm just guessing
>> here, Philip is focusing too much it as if it were the only sanctioned
>> way for Emacs users to stop working on a given set of files in a
>> programming project and clean up.
> Of course it isn't, it is just my prefered way and Eglot breaks it.

I don't think we should play the who-broke-what game.  It doesn't help,
and if we decided to look up the dates of introduction of your
project-kill-buffers way and eglot's process management, we might reach
a different conclusion.

>> Neither do I.  But when I M-x cd to other places, project.el thinks that
>> scratch belongs to that project.  It doesn't, I keep stuff of various
>> projects in it.
>
> I agree, this is bad, but that can easily be solved by adding
> `lisp-interaction-mode' to the list of major modes that are not
> killed.

Also *ielm*, the global Elisp repl created by M-x ielm. has the same
problem.  And *Completions*.  I'm quite sure that *sly-scratch* in the
SLY CL IDE would also be targeted.  And the CIDER Clojure IDE, as
someone has already reported.  And probably many more.  This blanket
default-directory heuristic is practical in some common cases but flawed
in many others.

>> Just commit the original tested patch I gave you that exempts hidden
>> buffers without buffer-file-name from project-buffers.  Philip's command
>> will keep working perfectly and we can close this bug.
>
> So if I understand correctly, with `eglot-autoshutdown' enabled as soon
> as all the buffers have been killed, the server will also shut down,
> right?

Yes! This is exactly what the docstring says:

   eglot-autoshutdown is a variable defined in `eglot.el'.

   If non-nil, shut down server after killing last managed buffer.

> Regarding the patch itself, I think it would be better to use
> `project-kill-buffer-conditions', so that if a project.el backend
> defines a new implementation for `project-buffers', the issue doesn't
> pop up again.

Your concern is quite valid.  Fortunately, CLOS generic functions have
us covered.  This is even simpler than the first patch:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..f8190eb1fc 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -362,6 +362,13 @@ project-buffers
         (push buf bufs)))
     (nreverse bufs)))
 
+(cl-defmethod project-buffers :around (_project)
+  "Ensure hidden/private buffers do not belong to PROJECT."
+  (cl-remove-if-not (lambda (b)
+                      (and (string-prefix-p " " (buffer-name b))
+                           (not (buffer-file-name b))))
+                    (cl-call-next-method)))
+
 (defgroup project-vc nil
   "Project implementation based on the VC package."
   :version "25.1"


Note this still leaves the *scratch* and *ielm* and other things
uncovered.  It addresses this specific bug and most importantly doesn't
blow up in the users.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 22:02:01 +0000
Resent-Message-ID: <handler.58839.B58839.16670808798099 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16670808798099
          (code B ref 58839); Sat, 29 Oct 2022 22:02:01 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:01:19 +0000
Received: from localhost ([127.0.0.1]:36838 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oottH-00026Z-0a
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:01:19 -0400
Received: from mout02.posteo.de ([185.67.36.66]:59873)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oottF-00026L-AQ
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:01:18 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 6976A240107
 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 00:01:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667080871; bh=nip3pJXsfQZt8en4sN8DUdAH/1hERr5BIur8uZXdTG4=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=Wk2VWnj+pbmxa1y/Bi/OApj9Ac6c0NGSxvVGKbacxh6sZAYjXDxb3wvD7L0pvCMGF
 0JzqTeDrQx58teJyxV5d08LhiaWsYsCGXtQd2Bw5JvmdlyyNSgjwJ8TKf83WWQPpKT
 yeGQyZjGwbpxSR+0O+Ghx5+OsOEwJ5WVg1gdaJgcJXsXbZDWVyU07PYPLRxb9uRN7I
 II/R9U4Bx6RSPpPa7Q1ZIFcB86WR7JfvjkCFg82xBYGQKS7JMQTbd80+L0+zMzEpPS
 K6XGNxfWBcC6+9fC/Qt7IUlOHGUQKk1cnvJU1USLKGh+ix3+VvyCuKv+TP1FooskxG
 owdz+FLJqm6Tg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N0CzS08Gkz6tpL;
 Sun, 30 Oct 2022 00:01:06 +0200 (CEST)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87eduqwekz.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 29 Oct 2022 21:38:04 +0100")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Sat, 29 Oct 2022 22:01:06 +0000
Message-ID: <87wn8invbx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>>> bytes, but it shouldn't rely on their values and certainly can't free()
>>> what it didn't malloc().
>> But to extend this metaphor, if I kill a programm that allocated malloc,
>> I would expect that memory to be cleaned up.
>
> Yes, but to kill a process you have to own it.  project.el is not the
> owner (not even a co-owner) of Eglot LSP internal buffers, and so it
> can't kill them.

What would be a co-owner?

My view is that project.el is a manager of buffers, but that isn't
relevant anymore.

>>> I think the command is pretty useful.  But perhaps, I'm just guessing
>>> here, Philip is focusing too much it as if it were the only sanctioned
>>> way for Emacs users to stop working on a given set of files in a
>>> programming project and clean up.
>> Of course it isn't, it is just my prefered way and Eglot breaks it.
>
> I don't think we should play the who-broke-what game.  It doesn't help,
> and if we decided to look up the dates of introduction of your
> project-kill-buffers way and eglot's process management, we might reach
> a different conclusion.

I really just meant "break" as in works until Eglot is enabled, and
nothing more than that.

>>> Neither do I.  But when I M-x cd to other places, project.el thinks that
>>> scratch belongs to that project.  It doesn't, I keep stuff of various
>>> projects in it.
>>
>> I agree, this is bad, but that can easily be solved by adding
>> `lisp-interaction-mode' to the list of major modes that are not
>> killed.
>
> Also *ielm*, the global Elisp repl created by M-x ielm. has the same
> problem.  And *Completions*.  I'm quite sure that *sly-scratch* in the
> SLY CL IDE would also be targeted.  And the CIDER Clojure IDE, as
> someone has already reported.  And probably many more.  This blanket
> default-directory heuristic is practical in some common cases but flawed
> in many others.

Project.el uses the same condition format like `buffer-match-p', which
is quite flexible.  Maybe all earmuffed buffers should be spared
("\\`\\*.+\\*\\'"), but in my experience that can be too lenient.

>>> Just commit the original tested patch I gave you that exempts hidden
>>> buffers without buffer-file-name from project-buffers.  Philip's command
>>> will keep working perfectly and we can close this bug.
>>
>> So if I understand correctly, with `eglot-autoshutdown' enabled as soon
>> as all the buffers have been killed, the server will also shut down,
>> right?
>
> Yes! This is exactly what the docstring says:
>
>    eglot-autoshutdown is a variable defined in `eglot.el'.
>
>    If non-nil, shut down server after killing last managed buffer.

Ok, great.

>> Regarding the patch itself, I think it would be better to use
>> `project-kill-buffer-conditions', so that if a project.el backend
>> defines a new implementation for `project-buffers', the issue doesn't
>> pop up again.
>
> Your concern is quite valid.  Fortunately, CLOS generic functions have
> us covered.  This is even simpler than the first patch:
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..f8190eb1fc 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -362,6 +362,13 @@ project-buffers
>          (push buf bufs)))
>      (nreverse bufs)))
>=20=20
> +(cl-defmethod project-buffers :around (_project)
> +  "Ensure hidden/private buffers do not belong to PROJECT."
> +  (cl-remove-if-not (lambda (b)
> +                      (and (string-prefix-p " " (buffer-name b))
> +                           (not (buffer-file-name b))))
> +                    (cl-call-next-method)))
> +
>  (defgroup project-vc nil
>    "Project implementation based on the VC package."
>    :version "25.1"

I have to still admit that I am uncertain if the general ignoring of all
hidden buffers is justified.  I have certainly used hidden buffers
frequently enough but never assumed that they were outside of anyone's
control.  They are just regular buffers with a special kind of name
after all.

We ought to be able to define a cleaner way of clarifying what buffers
can and cannot belong to projects.  Personally I think a buffer-local
variable/predicate would be a better approach.

> Note this still leaves the *scratch* and *ielm* and other things
> uncovered.  It addresses this specific bug and most importantly doesn't
> blow up in the users.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Oct 2022 22:49:02 +0000
Resent-Message-ID: <handler.58839.B58839.166708368315574 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166708368315574
          (code B ref 58839); Sat, 29 Oct 2022 22:49:02 +0000
Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:48:03 +0000
Received: from localhost ([127.0.0.1]:36849 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ooucU-000435-Te
	for submit <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:48:03 -0400
Received: from mail-wr1-f45.google.com ([209.85.221.45]:39541)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ooucQ-00041p-Pv
 for 58839 <at> debbugs.gnu.org; Sat, 29 Oct 2022 18:48:02 -0400
Received: by mail-wr1-f45.google.com with SMTP id o4so11056134wrq.6
 for <58839 <at> debbugs.gnu.org>; Sat, 29 Oct 2022 15:47:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=qVNF66lFvDjk//LcSLa+Ehje1C6F43ERHyWekT2QQ5g=;
 b=NKP2k6ub7V1oWehtZ1HkqnwXyuCmuXIuJJh7oe1UqRQtrNfnxlWVYP4YHtG8jIVDOJ
 bKh+/5yNuij2zZMO7MGCfOqtAC/pqt978i28VtinG+pnv9KpBgLAmKQ1Ua3rj9DQm+ia
 0PtyAW7Wdjyqa2O04Mzl2IU3XW4mhKkuHLThUG7rlQ5NXxsvq1UcibokDGq/RN4XQLyu
 ClmUG9pT9XvBckpfF5k1Nayczo0Ql4eyAzkitKrtAX68+R+i3byQqAXNQwqiDAX+mD0K
 IKCGyM4xNmFyKhUFFhi62blHunZZbIvXd1LHsj4mZ+WaNVJlirXMxdStiw/gtyw4/bYH
 X+Hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=qVNF66lFvDjk//LcSLa+Ehje1C6F43ERHyWekT2QQ5g=;
 b=CMjuOyPluknQl+uOJqtz88Fkp2oBmtsAV1tiT0mRV2qi2uYrE6CpxwXyfWTMxWXKam
 lWX/TG4sggRlI4zyMySAN01h1daFaeiYFwEFbRG0xENBKqmsv4si2dajopWP/Ra9A5f5
 sfpSPCrlOPNYIXM2QVR7qjb8dMouAx5UgIjM2/hHDeNyiC77jLXpSMok5CgcXhScVhEE
 UFngxwy4P4BWUd2oKSfJ9eB1VqZcBi9WYck6cD5FpGld3fSNWLMRjEiL2L/5TABoBLpK
 6VCESf49Ycx0s1dAr0snkSIYXsEpI9i8IOXTecB9+fXRmdwAliFgZ0WIwY2AwM0oNfu7
 ZeCg==
X-Gm-Message-State: ACrzQf2LZH3SAreQikAdML3AMG0EABZrJtvG+rlAljCK/iN15bkJ5aJS
 rPpJcDgxrq+/xXnnZtBRP6FWPnsMeP0=
X-Google-Smtp-Source: AMsMyM5c2JiMFiu17s8RkkC0RJb8reKWmHjY/DWZrXOFZS7XZdzTP8UXaynUIcIjV2a3fb1pSUSeKg==
X-Received: by 2002:a05:6000:1d83:b0:22c:aa0a:12 with SMTP id
 bk3-20020a0560001d8300b0022caa0a0012mr3334456wrb.471.1667083672552; 
 Sat, 29 Oct 2022 15:47:52 -0700 (PDT)
Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id
 i10-20020adffdca000000b00236674840e9sm2563463wrs.59.2022.10.29.15.47.51
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Oct 2022 15:47:51 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87wn8invbx.fsf@HIDDEN> (Philip Kaludercic's message of "Sat, 
 29 Oct 2022 22:01:06 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
Date: Sat, 29 Oct 2022 23:49:01 +0100
Message-ID: <877d0iw8iq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

> What would be a co-owner?
>
> My view is that project.el is a manager of buffers, but that isn't
> relevant anymore.

You almost answered the question.  There is more than one manager of
buffers.  Ibuffer manages buffer, M-x buffer-list, the user.  Eglot
manages some normal source code buffers in a co-owned way.

In contrast, the JSONRPC stdout and stderr hidden buffers are managed by
no-one else other than jsonrpc.el: they're not co-owned.

> Project.el uses the same condition format like `buffer-match-p', which
> is quite flexible.  Maybe all earmuffed buffers should be spared
> ("\\`\\*.+\\*\\'"), but in my experience that can be too lenient.

Yes, I think some earmuffed buffers can clearly belong to projects.
Others probably not.  You haven't seen me complain about
project-kill-buffers killing the *EGLOT events* buffer, for example ;-)

That is not a hidden/private buffer, so I accept that other buffer
managers kill it.

> I have to still admit that I am uncertain if the general ignoring of all
> hidden buffers is justified.

Notice that the patch is more tame: only hidden buffers without
buffer-file-names are exempted from project-buffers.

> I have certainly used hidden buffers
> frequently enough but never assumed that they were outside of anyone's
> control.

What have you used them for?

> They are just regular buffers with a special kind of name
> after all.

I don't know any "irregular" buffers, but yes, that is their
representation.  This representation is an old convention in Emacs for
"out of bounds" and "out of sight".

> We ought to be able to define a cleaner way of clarifying what buffers
> can and cannot belong to projects.

Agreed.

> Personally I think a buffer-local variable/predicate would be a better
> approach.

You can think about new conventions and protocols but you force it down
existing package's throats.  That doesn't go well as this bug shows.
That's because there are many diverse packages out there, that you can't
possibly know about and they likely aren't tracking your developments
and your thinking.

Have you considered the converse approach which is to be conservative?
It doesn't have these drawbacks.  In your project buffer's bucket put
only non-earmuffed, non-hidden, file-visiting buffers automatically.
Those are relatively safe.  Then have a buffer-local variable for
packages to opt into -- not opt out of -- your scheme.

As project.el and its new commands gain popularity (I hope it does) then
more and more packages, major-modes, etc will want to buy into its API
and add a little (setq-local project-owned t) when they setup their
helper buffers.  It takes a bit more marketing work, but in the end it's
better.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 06:30:02 +0000
Resent-Message-ID: <handler.58839.B58839.166711134529858 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, dgutov@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166711134529858
          (code B ref 58839); Sun, 30 Oct 2022 06:30:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 06:29:05 +0000
Received: from localhost ([127.0.0.1]:37167 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1op1of-0007lW-4d
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 02:29:05 -0400
Received: from eggs.gnu.org ([209.51.188.92]:43170)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1op1ob-0007l0-Kw
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 02:29:03 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1op1oV-0008UV-4s; Sun, 30 Oct 2022 02:28:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=kM4jVeQ3x0H/D98VhajCCAqPfRHzAwqF1dzf/ODDKNA=; b=sRJvWpntpk0XfSP5cb2+
 GHZ1aKe30+R4ogxVLmE6jy3ngZe0l60HqvPi0bVctNBObkUqg9azU5IAPNkrfcfVJcFGmtg/0q+J3
 fpi4ltUeM6XBSQMhIdD/JAIBLf8ZSWE8wGI7miNC+Y92MT63tKFbNi9GVPdyGnREaPXj2HSSCqwB+
 s6Fdhq3BrMXILCLaxc98EuqNMxFKK9ERvfmw283JmB5y8lw+c3pqiAkDLGdLOZfR7z3bqn6tqI2M+
 pi44M+Ey/Yu1LSQBy2uPCC9QNQmrhjpyd/BtCW0NerVQAm7kZaZN5eLCgGo7R77pigTtnd2HAAOlR
 OV1cXgrokfcWVA==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1op1oR-0003IS-W9; Sun, 30 Oct 2022 02:28:54 -0400
Date: Sun, 30 Oct 2022 08:28:33 +0200
Message-Id: <837d0hhlke.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <877d0iw8iq.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 29 Oct 2022 23:49:01 +0100)
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: Manuel Uberti <manuel.uberti@HIDDEN>, 58839 <at> debbugs.gnu.org,
>  Dmitry Gutov <dgutov@HIDDEN>
> From: Jo�o T�vora <joaotavora@HIDDEN>
> Date: Sat, 29 Oct 2022 23:49:01 +0100
> 
> Have you considered the converse approach which is to be conservative?
> It doesn't have these drawbacks.  In your project buffer's bucket put
> only non-earmuffed, non-hidden, file-visiting buffers automatically.
> Those are relatively safe.  Then have a buffer-local variable for
> packages to opt into -- not opt out of -- your scheme.

I believe I made a similar argument with Dmitry back when project.el
was added to Emacs.  Dmitry didn't like my suggestion back then, and I
have doubts that he changed his mind.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 12:40:02 +0000
Resent-Message-ID: <handler.58839.B58839.166713357929608 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, dgutov@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166713357929608
          (code B ref 58839); Sun, 30 Oct 2022 12:40:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 12:39:39 +0000
Received: from localhost ([127.0.0.1]:37494 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1op7bH-0007hU-2Z
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 08:39:39 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:37779)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1op7bF-0007hH-Kn
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 08:39:38 -0400
Received: by mail-wr1-f46.google.com with SMTP id bs21so12447242wrb.4
 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 05:39:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=Tp6/f3GBOWH9Uk6fZ275wnjaxpeWBB8inbFG1kqVO/U=;
 b=pnSaXGVcvtZtdv5Ze0+TBFKDpjBUOhRrEk02h7hvHJkMr9gdVS4s1PxNAvTBz+41HA
 0S2z4GTgqaMQTHMxb4ZR1F+yL2sA8gMMqq0OqU4mDNi3E9xR9I3r2WElk1oppX8K+Scg
 AuUNObO82PRW1gIldedf6kYc6DcQzP6VV34PiG1qRj3eI6txybqd6zp6svcPDW4ZEPix
 JLSpLebjKqlH3W09Pqjxfw6MbYX8xx/CAto9fW0wsLpSyvoJZUu9N4ogDEG2kmDeS/V4
 5AAY43tqlJmRcgacdQWgJdowSyA/1tvGmj/nqi9aQJVNj1Zgg1wv2z+/YbVN3UscTnxX
 Qh2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=Tp6/f3GBOWH9Uk6fZ275wnjaxpeWBB8inbFG1kqVO/U=;
 b=zG7gGXYvT8UxR7id7gfDGY+xckIkxVFJMnBB6YWrCjDww+yRwWs8BDOo+fuhk4l06t
 cPLsSV/FfBdziGT5uLsux83Zs+rSN210kDZVEU5iTWwkLLPbQVpqjSdEziomcWfzSAzH
 TAooohYAEo5ShQhtA6TUinngiM/V5evMFI4+zF9pJ1QHR69f4QXjkzjh788EjNxEI4/W
 ZczIyQ3nv6j4I+/aH+K9TLS9ve2ovrq7p1jBj83XLe/8mNOjreDuq2oi8GmFKg/5XdVe
 mZmbNMK8z5NGmiL0w++gfw4vo/hEgE4mqJLSBHjMxpFPCTefMjp4po1wSL0BlND4Pevw
 h0UA==
X-Gm-Message-State: ACrzQf2NfduNvHwHzeA1RFkmrk94jpJIuHuEgCEK7DKo1pbPMzz8mcRz
 NSivfCg3JvvMDFtJw8aQDZk=
X-Google-Smtp-Source: AMsMyM7Oe/WDEGfvs3j/zsQnT/o3nffkl1VI5RtfZ7/sGm4CieItvPO+Uy101JnNJ/8uC0Ihz+hhaA==
X-Received: by 2002:a5d:6485:0:b0:236:4ed2:409c with SMTP id
 o5-20020a5d6485000000b002364ed2409cmr4868788wri.110.1667133571672; 
 Sun, 30 Oct 2022 05:39:31 -0700 (PDT)
Received: from krug ([87.196.74.89]) by smtp.gmail.com with ESMTPSA id
 s12-20020a5d6a8c000000b002364c77bcacsm4099098wru.38.2022.10.30.05.39.30
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 30 Oct 2022 05:39:31 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <837d0hhlke.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 30 Oct
 2022 08:28:33 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
Date: Sun, 30 Oct 2022 12:40:41 +0000
Message-ID: <8735b5wkl2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Have you considered the converse approach which is to be conservative?
>> It doesn't have these drawbacks.  In your project buffer's bucket put
>> only non-earmuffed, non-hidden, file-visiting buffers automatically.
>> Those are relatively safe.  Then have a buffer-local variable for
>> packages to opt into -- not opt out of -- your scheme.
> I believe I made a similar argument with Dmitry back when project.el
> was added to Emacs.  Dmitry didn't like my suggestion back then, and I
> have doubts that he changed his mind.

I'd just like state, if there was any doubt, that project.el is a
fantastic and long-awaited addition to Emacs.  The design is generally
great and for one it enabled Eglot to integrate very well.  So I am
quite thankful to Dmitry and its maintainer.  The new project-wide
commands (project-find-file, project-switch-to-buffer,
project-kill-buffers) are really very useful, and I'm learning to use
them.  But this point of "which buffers belong to projects" seems off.
Not by a terrible lot, but definitely off the way it is.  This
discussion has revealed some of its flaws.  There's still time to adjust
the design before Emacs 29.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 15:59:02 +0000
Resent-Message-ID: <handler.58839.B58839.166714550925878 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166714550925878
          (code B ref 58839); Sun, 30 Oct 2022 15:59:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 15:58:29 +0000
Received: from localhost ([127.0.0.1]:38877 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opAhg-0006jK-Nz
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 11:58:29 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:41580)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opAhe-0006j6-QS
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 11:58:27 -0400
Received: by mail-wr1-f54.google.com with SMTP id w14so12813482wru.8
 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 08:58:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=nOfVDluq/MsMQYBVzTPeDrml2PPyay8VXo8d56s/djk=;
 b=IbcBkH2GWXtebIOjtIQlsjy+SWzhUIlGzOwyyN4wlPtjJMmlB7xtfsy8zHb9QuIt2h
 Nmb6sBmwNkeyrtUjJ3qQxGF8Ic5nnxWkqUgZOi/Y+z/og8oGSMvo7lXA10vOjlXxLSl2
 Kq72KTaxVoPSp/TLxvutHmwpUIH2a4tOfsNZqCXtv9yrQx1i4RySdF2KhAslebjIbNym
 cMS4F0AI0fFwVbDlCqkZnXYkBpheuVNUu4yY81Bs7963IDweorSYwwFp58cqclhyRR+D
 /7pwuYA5wrIXgb9djOPEsC7ICmIllAbVWq7HYXVhZjJbXz8kvPTrq+gH3a/UxaQojyFW
 gblg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=nOfVDluq/MsMQYBVzTPeDrml2PPyay8VXo8d56s/djk=;
 b=s2ff8cqe0rp0HbRD+C/egv5zhzxU0V+d61JRpbjwd/TjUEF2gFN7nq7rvIvKXjLivY
 gub/JQ87WWh2Qhou/+niPftTqEhYkZHkVDtBFLGyK3RuHtAJ5TXC8pfUIRd3Ci8jx0w4
 XTkkrS32QqCLnOa30gS8LbRaDsPL9XTGZM8jGxcFgRepLeRlXSLW9YlNu7ZBQNKYT+Ra
 IvrfYXPMWgmUkTJ6tP9SPO5IuLf9RyN8dVF2D7kEysBUFKoLzvJyUbtXWnSgY7kcY9ag
 epsCplyVIyCFEUVkPoNkq/2aykuPYLuDsUjEMeyCHecWBGTTs/llMlaIGXr7lqeFtWxg
 4+BA==
X-Gm-Message-State: ACrzQf3BuV/II3GC0hfQRxiWFk8xkKxeekSxd/p5cy2QSiDXo4etUulK
 URrX4gifq3zBkXB3nR7J2L0=
X-Google-Smtp-Source: AMsMyM4r1Dfr+Pl/kOfH+gZHHq69n5J673BQg6uf7wsuLxbsYZRnUU2mmtpoNZninTcopFsV+JgfFQ==
X-Received: by 2002:a05:6000:100c:b0:235:6980:aa24 with SMTP id
 a12-20020a056000100c00b002356980aa24mr5361186wrx.238.1667145500513; 
 Sun, 30 Oct 2022 08:58:20 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 c6-20020a056000104600b0022e344a63c7sm4534090wrx.92.2022.10.30.08.58.19
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Oct 2022 08:58:20 -0700 (PDT)
Message-ID: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
Date: Sun, 30 Oct 2022 17:58:18 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <837d0hhlke.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 30.10.2022 08:28, Eli Zaretskii wrote:
>> Cc: Manuel Uberti<manuel.uberti@HIDDEN>,58839 <at> debbugs.gnu.org,
>>   Dmitry Gutov<dgutov@HIDDEN>
>> From: João Távora<joaotavora@HIDDEN>
>> Date: Sat, 29 Oct 2022 23:49:01 +0100
>>
>> Have you considered the converse approach which is to be conservative?
>> It doesn't have these drawbacks.  In your project buffer's bucket put
>> only non-earmuffed, non-hidden, file-visiting buffers automatically.
>> Those are relatively safe.  Then have a buffer-local variable for
>> packages to opt into -- not opt out of -- your scheme.
> I believe I made a similar argument with Dmitry back when project.el
> was added to Emacs.  Dmitry didn't like my suggestion back then, and I
> have doubts that he changed his mind.

Do you have a link to that message? Details matter.

Anyway, if we do decide to flip the switch, it should be through 
project-kill-buffer-conditions, so the user can make a different choice 
through customization.

So far we have 2:1 votes against that, though.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 16:41:01 +0000
Resent-Message-ID: <handler.58839.B58839.16671480135955 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16671480135955
          (code B ref 58839); Sun, 30 Oct 2022 16:41:01 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 16:40:13 +0000
Received: from localhost ([127.0.0.1]:38913 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opBM4-0001Xz-IW
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 12:40:12 -0400
Received: from eggs.gnu.org ([209.51.188.92]:36018)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1opBM3-0001Xi-C2
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 12:40:11 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1opBLx-0005RH-C5; Sun, 30 Oct 2022 12:40:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
 mime-version; bh=+dUKtceSVd1qBYPUPOyM81hwaxj15Krqx27rEe8uTks=; b=ou0dmKs6nJIL
 OIWpZNCkNCLtFmCC4ZAZd+kOVQiyukC7e1CcdxT9hF0wHH20H3Ri7N1repqlHzBqVZcZ7hTFXmjM+
 DVEdsQgKTkRn5SSalodW1aHFPpeMldlNoPwgZbSCR0FN2a0k6+HBiqmaoYdbqxcE6gK5oERE7ZOrp
 ptn1jPBBL9OK/pMyUgdtMvAtEonG6iCqeJIFu5CTXhiDf4zjU+WS2oMVSTihS0xSLdRLAyzh9GBzt
 4ZCq6RJpLBAycpmGL/Bt4eXlxzYBUvcS7j9of1hgcKe9Fz+gOOI44HuiLWnNrmoZ5ocHhnwLyygGh
 r/tcDXN6RjGs3v+hMdsL3A==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1opBLv-0008Qs-LP; Sun, 30 Oct 2022 12:40:03 -0400
Date: Sun, 30 Oct 2022 18:39:46 +0200
Message-Id: <838rkxfep9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> (message from
 Dmitry Gutov on Sun, 30 Oct 2022 17:58:18 +0200)
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 30 Oct 2022 17:58:18 +0200
> Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> 
> On 30.10.2022 08:28, Eli Zaretskii wrote:
> >> Those are relatively safe.  Then have a buffer-local variable for
> >> packages to opt into -- not opt out of -- your scheme.
> > I believe I made a similar argument with Dmitry back when project.el
> > was added to Emacs.  Dmitry didn't like my suggestion back then, and I
> > have doubts that he changed his mind.
> 
> Do you have a link to that message? Details matter.

Not anymore, sorry.  It doesn't really matter, if you are now okay
with making buffers that don't visit files by default not belong to a
project, regardless of their default-directory.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 19:15:02 +0000
Resent-Message-ID: <handler.58839.B58839.166715724220621 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166715724220621
          (code B ref 58839); Sun, 30 Oct 2022 19:15:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 19:14:02 +0000
Received: from localhost ([127.0.0.1]:39019 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opDkv-0005MJ-S2
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:14:02 -0400
Received: from mail-wm1-f50.google.com ([209.85.128.50]:53194)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opDkt-0005M5-Nd
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:14:00 -0400
Received: by mail-wm1-f50.google.com with SMTP id l32so6072143wms.2
 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 12:13:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=bIIjv5oTgAJFmWnpB2kEzeKUDgoaKEB5Wb0ZOJslAw0=;
 b=ZjgsmgiR7hkuYLnKfXQhPF4vC15+FRXlt+RQyuTyethi84GbmPma1KK5gcsv7uHEH5
 JPxEGBQ+U3pwcVOpI+78wzgMBAV9zkPbzqiTmG6tyRK0uMRUjasnLg80iEJWZqLnpkuB
 T6u4BDMcZx9y/PfJ5h82QSBh7ZOFhP/mShHMRPUPOrhy8Hvhb44rKGg+nCGoB7BTPZ2X
 q0Etrv1d69KzjdsQokyGiujldCiNdiUv7879N87jU4Y8DPUfrfLgR1dqR+LYvD+294Tp
 4OXGssxjclPyXuEfe9rU5zA36uJFQjliIdzTwXsa3fe3nIFRl2oJU47yW9DcL88BGLlm
 yjuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=bIIjv5oTgAJFmWnpB2kEzeKUDgoaKEB5Wb0ZOJslAw0=;
 b=FYEbahzpeEPY2QohJRvKbABSRU2notmJsoqfvnZNh8LNIH2JQ+HR9PmGmCyLP+GSZO
 cYWuXB9nr/CDGnogJpgg3roa4Ds1ey6+pCGqcLYPhxkBD14NIP70lbqDpLuQKKKXjsBi
 8Aq11F1+jBTCW9psBol2fXMQwrf8s75FPcd7oGUffjDlvYGxymu5jMgmtnouGsxSpfjD
 54UjUfjQos1aWZTAlegEyVVA2UtvGBZCvC5q9L8l6Ky/L4KcNc4u7cHQwaCpxUTZvA09
 fYBWizlzRh/H3/C8UE8g9vP4H0AoqoPU2hgIEDjtQLGY3evNRwEAbRjzXTIiLJtiOGBf
 tuQA==
X-Gm-Message-State: ACrzQf1hBZ9BdFfy8HTVNRmghgB+wWPqxrglixqMA6ngVCFdd7uDucFI
 7kqDHYJqKof1oJ6rV4wqp40=
X-Google-Smtp-Source: AMsMyM4KU94J9dSV229BoV2KvmD9t1uF7vgt1GgloJss5l+WhXfWKkLBn4ABviU09Ik+oxmVVVxZuA==
X-Received: by 2002:a1c:448b:0:b0:3cf:6fcd:e171 with SMTP id
 r133-20020a1c448b000000b003cf6fcde171mr1690689wma.163.1667157233625; 
 Sun, 30 Oct 2022 12:13:53 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 k3-20020a05600c1c8300b003c6b7f5567csm19859877wms.0.2022.10.30.12.13.52
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Oct 2022 12:13:53 -0700 (PDT)
Message-ID: <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN>
Date: Sun, 30 Oct 2022 21:13:51 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <838rkxfep9.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 30.10.2022 18:39, Eli Zaretskii wrote:
>> Date: Sun, 30 Oct 2022 17:58:18 +0200
>> Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN
>> From: Dmitry Gutov <dgutov@HIDDEN>
>>
>> On 30.10.2022 08:28, Eli Zaretskii wrote:
>>>> Those are relatively safe.  Then have a buffer-local variable for
>>>> packages to opt into -- not opt out of -- your scheme.
>>> I believe I made a similar argument with Dmitry back when project.el
>>> was added to Emacs.  Dmitry didn't like my suggestion back then, and I
>>> have doubts that he changed his mind.
>>
>> Do you have a link to that message? Details matter.
> 
> Not anymore, sorry.  It doesn't really matter, if you are now okay
> with making buffers that don't visit files by default not belong to a
> project, regardless of their default-directory.

It would help remind you of the original explanation, instead of putting 
me on the defensive. And recall the supporting voices from the others in 
the same discussion. And maybe add the explanation to the docs, if it 
looks that non-obvious.

To reiterate: we usually want to consider VC-Dir, Diff, Dired and 
Compilation buffers as part of the project. Even though they are not 
associated with a file. Because 'C-x p b' can be handy to switch to 
particular one, and 'C-x p k' can clean them up (when you're "closing" 
the project).

People who think differently, can use project-ignore-buffer-conditions 
and/or use some special backend (probably defined by themselves) that 
overrides 'project-buffers' with a different logic.

The issue Joao is having, however, is with particular "hidden" 
non-file-visiting buffers (in fundamental-mode). And here the argument 
could be made both ways.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 19:56:02 +0000
Resent-Message-ID: <handler.58839.B58839.166715973924701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166715973924701
          (code B ref 58839); Sun, 30 Oct 2022 19:56:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 19:55:39 +0000
Received: from localhost ([127.0.0.1]:39055 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opEPD-0006QK-AD
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:55:39 -0400
Received: from eggs.gnu.org ([209.51.188.92]:41316)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1opEPB-0006Q8-BF
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 15:55:37 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1opEOq-0006Mu-J5; Sun, 30 Oct 2022 15:55:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=yi20182JLmgS8czNrddhWJ6mbx69JxkTfgdQSPZDwlM=; b=hodTeXXMhIdZaCWuSbRc
 wbNrtemxKDcGLrsWvCK1DfHrLo0tmTxrGgeEK70R/Uao9ANnFDQwnpDgroWsIkzuD3qBoWIWqU/Uw
 Q0mJ1ucZkg5WCZGDhNeFlNEFW1Lh+/fQzdQJhaXHaCY3PYh2m0NcEuy4n3H/L+rQvkrsDC6kLeZeJ
 T3bWxG4Ng2vYTPVcCxHwPKCQhkmgkZV2ONFW02SzWFvXBUGJxLfun6SeYWTnS51UWsYeXm+2ldAd5
 QFe16q5AErtKBr1rL1M0jsqe9eNBXf90dDuCFiz3GcocHmiCfCE6hlFT4Fby/frgTYrc4YEa1spvI
 yqQZSgb00aIK3w==;
Received: from [87.69.77.57] (helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
 id 1opEOj-0006OR-Qo; Sun, 30 Oct 2022 15:55:15 -0400
Date: Sun, 30 Oct 2022 21:54:51 +0200
Message-Id: <834jvlf5o4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> (message from
 Dmitry Gutov on Sun, 30 Oct 2022 21:13:51 +0200)
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN>
 <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 30 Oct 2022 21:13:51 +0200
> Cc: joaotavora@HIDDEN, philipk@HIDDEN, 58839 <at> debbugs.gnu.org,
>  manuel.uberti@HIDDEN
> From: Dmitry Gutov <dgutov@HIDDEN>
> 
> >> Do you have a link to that message? Details matter.
> > 
> > Not anymore, sorry.  It doesn't really matter, if you are now okay
> > with making buffers that don't visit files by default not belong to a
> > project, regardless of their default-directory.
> 
> It would help remind you of the original explanation, instead of putting 
> me on the defensive.

You don't need to be defensive, I did not intend to restart the
argument.  I just wanted to inform João that your opinion was and
remains that non-file visiting buffers should be part of the project,
that's all.

> The issue Joao is having, however, is with particular "hidden" 
> non-file-visiting buffers (in fundamental-mode). And here the argument 
> could be made both ways.

He was making a more general argument about buffers that don't visit
files, AFAIU.  I wanted to inform him that this idea was already
considered in the past.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Oct 2022 21:16:02 +0000
Resent-Message-ID: <handler.58839.B58839.166716452532300 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, joaotavora@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166716452532300
          (code B ref 58839); Sun, 30 Oct 2022 21:16:02 +0000
Received: (at 58839) by debbugs.gnu.org; 30 Oct 2022 21:15:25 +0000
Received: from localhost ([127.0.0.1]:39086 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opFeP-0008Ot-80
	for submit <at> debbugs.gnu.org; Sun, 30 Oct 2022 17:15:25 -0400
Received: from mail-wr1-f43.google.com ([209.85.221.43]:34304)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opFeN-0008Oh-3B
 for 58839 <at> debbugs.gnu.org; Sun, 30 Oct 2022 17:15:23 -0400
Received: by mail-wr1-f43.google.com with SMTP id k8so13555911wrh.1
 for <58839 <at> debbugs.gnu.org>; Sun, 30 Oct 2022 14:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=s66vI+iGALnCuUXaDP3IW2oUHV+PT9mgDpsnLSTdD8U=;
 b=GvPII1hXmlut2RKJrBsETWRkrdP7j/X+6oPUMoaOokNR/TtaOl5UZ3pEVQOIi394qA
 2gGxtn+MPHRNxilpH3wItj7XV0Pc8vbD5nxnGfZyJWlcxqrHI17N/Bq4u/y6KCaAkFy8
 BcN4WSL39scHA4ZquW9TJJiJ9A7VLmhgsWLjXccZRsvGrTps++Rn06wFooWBatxWAWck
 uGW9mgE08r6A9R5QrGHG6K/k2qza+kw1ioKwcDbrtp2TytC8P5vmbPPDzfsCqpuodaM7
 9ufZ/hFzrUmh5dUIobSWL3JfBD4uTyfWJMacrs4sb4mdxIvMcytrh43sXNSi6xJqXBWz
 tJPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=s66vI+iGALnCuUXaDP3IW2oUHV+PT9mgDpsnLSTdD8U=;
 b=tCO69SusOXUg7/TXIykDg0aroHRurmMbRdEi3kTZ+nY14qbQoVizUhWitl+SWNhRic
 +oltV4ZQEc0/RCG1ZRC1zYQXxKcehRUNaZ+wHw7QB9O9KslB9T4dtjEurIqkgQMYViir
 3E3eWogUvtTiMcio3iNiOyDLgwdqOAm+saw/19cNi6eEoA1+TIfMEBIdiYFGE5NoQZ9M
 hY/Qct3JHmijRNOyekQRRLG5XxmmwnYQZl/FpRkA5Q7rVsRScDa0tihuUGqWISEVjVZR
 x0K86QOCkv/lClSXi+reL7+93LhIe+K3HxTzKg0MGyYTsjDUjKrSAUVxThh/EmwMxr5e
 13ig==
X-Gm-Message-State: ACrzQf0qvkAzXYpfaRMVe4ikiT7YnP6OVLw+nJ3jKqgrQHXiNOS5Ka/I
 C0kgT5/raOozZecGzERzwdg=
X-Google-Smtp-Source: AMsMyM7DZ5EbLllAJm1r91BM+Q/0TKabNevgfbW/hGJ3jtbWjgMbeGFJPefkw5807TMpU+Wr6pnE+Q==
X-Received: by 2002:a5d:58d7:0:b0:236:6c53:6123 with SMTP id
 o23-20020a5d58d7000000b002366c536123mr6004607wrf.719.1667164517200; 
 Sun, 30 Oct 2022 14:15:17 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 g4-20020a5d5544000000b002366fb99cdasm5097725wrw.50.2022.10.30.14.15.16
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Oct 2022 14:15:16 -0700 (PDT)
Message-ID: <f9fb2e3e-e9b2-33cb-469b-3e61176c2e65@HIDDEN>
Date: Sun, 30 Oct 2022 23:15:15 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <838rkxfep9.fsf@HIDDEN>
 <b463dedf-af69-c051-771e-97dacfb7e2ec@HIDDEN> <834jvlf5o4.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <834jvlf5o4.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 30.10.2022 21:54, Eli Zaretskii wrote:
> You don't need to be defensive, I did not intend to restart the
> argument.  I just wanted to inform João that your opinion was and
> remains that non-file visiting buffers should be part of the project,
> that's all.

Thanks.

>> The issue Joao is having, however, is with particular "hidden"
>> non-file-visiting buffers (in fundamental-mode). And here the argument
>> could be made both ways.
> He was making a more general argument about buffers that don't visit
> files, AFAIU.  I wanted to inform him that this idea was already
> considered in the past.

I don't know if that was his point. To quote:

   Yes, I think some earmuffed buffers can clearly belong to projects.
   Others probably not.  You haven't seen me complain about
   project-kill-buffers killing the *EGLOT events* buffer, for example 😉

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 09:53:02 +0000
Resent-Message-ID: <handler.58839.B58839.166720997217173 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, philipk@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166720997217173
          (code B ref 58839); Mon, 31 Oct 2022 09:53:02 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 09:52:52 +0000
Received: from localhost ([127.0.0.1]:39586 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opRTP-0004Sv-WD
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 05:52:52 -0400
Received: from mail-wr1-f47.google.com ([209.85.221.47]:34635)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opRTM-0004Sf-R5
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 05:52:50 -0400
Received: by mail-wr1-f47.google.com with SMTP id k8so15193314wrh.1
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 02:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=2F0/j7sytqCwyqPb67kDkK0cw5qtV+3clP5lHm1eOA8=;
 b=LacIoYt+c0wmFz7oDopBo2VrCKfsKdaNaM+wLPG0jiAVHjTGr93Gsg4DfUHR3I2jv+
 stFEEpqwXpJhebVqTXiWyCirbE9GaseauC5HWUgnMlvW7muRA4roKR113yub6VgZQXbj
 Wr38mnO0ta9AvbTdV+b0eCcGqiwvghj6reZ4XBfxg9SNQ6sh803AukrIQz6l+UlCTFJd
 5J3ewp/WjXDgzagyRHwhknXRjbUiM+PgmhZIOEXlqncs02pHm5h26H7hElLa4l29PMs8
 Q1qqvmB2UwdxCl4yf7UpMY9lvf5wVHFjPP6viMpwnLZ7yYDszhaKRhdqOFLcS5MJ+Ncf
 w8jQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=2F0/j7sytqCwyqPb67kDkK0cw5qtV+3clP5lHm1eOA8=;
 b=5oxEnizm9gElPv9PiRPBbypSaJRR/y1GOdpgv8yxnHJ1rQB46mX66ysblfdmG8xgkU
 A7rPhkI20FkcNCy8+ohLdLoRZCT8yisVyNVGy6Uytq9gxbtCxGAIZYWeOyzH/KjeOZ0Z
 2VRu7ZvsHxYsSMJ6yOmAQCbYLvwULDxYOwXpV1h7IlwpRQ7pn88aMOTERAqF/ucGBfwe
 t0MDoTOpVBAJexLqKxTcQipAc091a7yW3otojb7ZZ2aU6QoAQXP97dR2/Mv4FqgBd/Gd
 8wehgQ1dft/u8TAZGym4s6o79EFXoDYpy/iuYfrmZJl4vLhAJut/6q+N5znRBn2mpsQd
 bb6w==
X-Gm-Message-State: ACrzQf2d0AGz+op6QNDQHhuawBx9dkC4153Z0+VMO98ViuZblAodfilf
 1MmEWJtq6GjNHmboFMGMuOo=
X-Google-Smtp-Source: AMsMyM7xBkeZ9tN/eS4yv8T1aNB9UZ1TGy0/aVWnUZaYFhz4sCacHME3D11Q+fBrqcBbtKOHE5198Q==
X-Received: by 2002:a05:6000:1f1a:b0:236:ce27:230a with SMTP id
 bv26-20020a0560001f1a00b00236ce27230amr1868531wrb.469.1667209962631; 
 Mon, 31 Oct 2022 02:52:42 -0700 (PDT)
Received: from krug (87-196-74-89.net.novis.pt. [87.196.74.89])
 by smtp.gmail.com with ESMTPSA id
 m17-20020a5d56d1000000b0022cc6b8df5esm6621063wrw.7.2022.10.31.02.52.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Oct 2022 02:52:42 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> (Dmitry Gutov's
 message of "Sun, 30 Oct 2022 17:58:18 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
Date: Mon, 31 Oct 2022 09:53:50 +0000
Message-ID: <87v8o0uxn5.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> Anyway, if we do decide to flip the switch, it should be through
> project-kill-buffer-conditions, so the user can make a different
> choice through customization.

project-kill-buffer-conditions doesn't work, I've tried it, it has this
fundamental-mode thing there that makes it impossible.  Supposedly it is
there to serve some purpose that no-one seems to be able to find a
argumentative basis for.

It's quite clear that _some_ non-file-visiting buffers can be considered
as belonging to a project's working set.  But it's very very easy to
come up with many that cannot be considered so.

Because "killing buffers" is a destructive operation, being greedy here
is a really bad design decision, as it catches an arbitrary number of
unsuspecting extensions off-guard, which have been using earmuffed
buffers for many years.=20=20

All in all, it's like you're making a gun that only backfires 5% of the
time.

In the little time I've used this feature since the start of this
discussion I have discovered it backfires no small number of occasions:
Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
even *ibuffer* itself is targeted by this.

Project-kill-buffers is off. Its intention pretty useful, but its
implementation is a blunder.  The root cause is this overgreedy
project-buffers.  When "killing a project" the echo area asks me if I
want to kill a number of buffers that I didn't even know I had, because
of hidden buffers.  This cannot be logical and the only way the
"argument can be made both ways" is out of stubborness.

JSONRPC's buffers are hidden implementation details: the argument that
they are somehow under the responsibility of project.el just because it
can see them through (buffer-list) is blind tiranny.

The mini-languages invented in project-kill-buffers-conditions and
project-ignore-buffer-conditions are abominations.  If project-buffers
just been conservatively designed, we'd need nothing more than the
existing hooks for the exceptions.  *earmuffed* buffers interested in
opting in could declare if it belonged or not in one line.  Just like

diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index dc3ed52650..718bebc7cd 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -179,6 +179,7 @@ vc-setup-buffer
   (let ((camefrom (current-buffer))
 	(olddir default-directory))
     (set-buffer (get-buffer-create buf))
+    (setq-local project-owned t)
     (let ((oldproc (get-buffer-process (current-buffer))))
       ;; If we wanted to wait for oldproc to finish before doing
       ;; something, we'd have used vc-eval-after.

To name one.  The above is just the converse of the solution proposed by
Philip before.

Anyway, I've now suggested and presented 2 actually tested, actually
working patches to project.el.  I don't have anything more to add.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 11:56:02 +0000
Resent-Message-ID: <handler.58839.B58839.166721734813875 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, philipk@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166721734813875
          (code B ref 58839); Mon, 31 Oct 2022 11:56:02 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 11:55:48 +0000
Received: from localhost ([127.0.0.1]:39667 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opTOO-0003bi-Hl
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 07:55:48 -0400
Received: from mail-oa1-f54.google.com ([209.85.160.54]:37670)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opTOM-0003bW-Mu
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 07:55:47 -0400
Received: by mail-oa1-f54.google.com with SMTP id
 586e51a60fabf-12c8312131fso13182078fac.4
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 04:55:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=7aHktoahfqgBVsEg2YhVX+M+qA+YJ+pbz73mCDa2Nrw=;
 b=jJ1NMRF3GLrCHdiqynjse9yGjrhAU+oOY7/AI6NIcisRUTL3CTci/nRm+mNtjaEVGT
 K3G7x+TM6UYj6lZuIE7pIcEj8EndlEGXuVaZpLqyZ/MbG/RTqvBUiL3SzLmZDkODa+Yx
 lIlm3NJ3odbxeKAJH4IgGp+8rAQS2jdDAwHfyLMN6T9/NIhRinBRXcZSg443QErsrrix
 9JsT0yk+08H8i2+8Plw2t5gm6WIUazXAfELt3K6IVTeL5OEZFRUpfsnTlwrEMqZC+p11
 ne03EKukxA3/FZY11NuTfkmxvXJFB2fobsMH6pZOW9wuWktA5USKqghHjsbQwWOUrbrp
 7c5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=7aHktoahfqgBVsEg2YhVX+M+qA+YJ+pbz73mCDa2Nrw=;
 b=li+xPzKXt4ePsGyfFDDLGE/MuLCX529XGoErrqQ5I3Xsd8jjuBxiMipsqAHsfLPz4N
 GBrnHGD8yvImRUuJAKHf6/N1t2xofEOQt4daUiNRz72t5yinHAzq2juRp2L0RMXoWEIG
 HeLHTUW101+rlcIjJmGDEiIC+o9jz6y64qu5laa1rKe+YmZaXb/r0J9Mr2amJ4LnEhID
 CE2j6yio4FpCHPEGyikaKvDw+XIgfQS1jXiyLRzc2gFd074V3sE3L7szc1QuqYGlFlWb
 GCXcH2QxGyxLhG6pLLj+UAjYoF2HK32ARY08R+FHhpHYoz7q+ylAQPB6mr5Q9NiO2QJJ
 jVSg==
X-Gm-Message-State: ACrzQf3oQIWt10VWdWknP5P419XTyXIqlYtk16b8fP4DCxeU6YAo08K/
 0JclcAGPFKDOce5N5rXHyoyLsw7nTVEkJlLNhfI=
X-Google-Smtp-Source: AMsMyM5UuTOp+NxrNdqjubRcY+dfHJmV0Ow18iig7Dyv62eT7nteFYxuno+tuihHJPwvZdXRw29U2QBH13JkRdGeB5w=
X-Received: by 2002:a05:6870:2155:b0:13c:8db1:2446 with SMTP id
 g21-20020a056870215500b0013c8db12446mr8252504oae.171.1667217340648; Mon, 31
 Oct 2022 04:55:40 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
In-Reply-To: <87v8o0uxn5.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 31 Oct 2022 11:56:39 +0000
Message-ID: <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000005a503705ec534932"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000005a503705ec534932
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN=
> wrote:

> In the little time I've used this feature since the start of this
> discussion I have discovered it backfires no small number of occasions:
> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
> even *ibuffer* itself is targeted by this.

And you can add the gnus mail buffers to this list. If you are unlucky
enough to start M-x gnus from a project file to read your email, then
closing that project in the future will take your gnus session, your
summary buffers, messages, etc. with it.  This can't possibly be considered
an exotic use case, and can't be right.

Jo=C3=A3o

--0000000000005a503705ec534932
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora &lt;=
<a href=3D"mailto:joaotavora@HIDDEN">joaotavora@HIDDEN</a>&gt; wrote:=
<br><br>&gt; In the little time I&#39;ve used this feature since the start =
of this<br>&gt; discussion I have discovered it backfires no small number o=
f occasions:<br>&gt; Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Compl=
etions*,...=C2=A0 Heck<br><div>&gt; even *ibuffer* itself is targeted by th=
is.</div><div><br></div><div>And you can add the gnus mail buffers to this =
list. If you are unlucky <br></div><div>enough to start M-x gnus from a pro=
ject file to read your email, then <br></div><div>closing that project in t=
he future will take your gnus session, your <br></div><div>summary buffers,=
 messages, etc. with it.=C2=A0 This can&#39;t possibly be considered<br></d=
iv><div>an exotic use case, and can&#39;t be right.<br></div><div><br></div=
><div>Jo=C3=A3o<br></div></div>

--0000000000005a503705ec534932--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 14:36:01 +0000
Resent-Message-ID: <handler.58839.B58839.166722693415132 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166722693415132
          (code B ref 58839); Mon, 31 Oct 2022 14:36:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 14:35:34 +0000
Received: from localhost ([127.0.0.1]:41466 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opVsz-0003vz-Hm
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 10:35:33 -0400
Received: from mout02.posteo.de ([185.67.36.66]:45545)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opVsx-0003vm-CY
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 10:35:32 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 7421F240108
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:35:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667226925; bh=MZlxZc0JHQ+eftJCj5ZFUoUGhtdFEKT4qSATCFIXgLU=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=r9S5l5e0vT7u4w/pvBXfF/sdNg6awTU5fv2u6rUPn1BwuogGCVG/uarzUDnGUIgbE
 IhrJfmjnK7RnTBjZDikT/NTS2l2BxU2Lg71Tsw46BDCg2Z79i9RbZJ/sa420P+QlIN
 rKkEV3Q3xzXeQ7C7wyv6BIaFjz4EQppvGF0dyYieuL7+Nkl3yaaEqzLs0ba7QCEAUt
 /pP8KaugVnPYEy2MF/TgtvsIpvk4JbHdRG5i6FYS2mxXe1CstQJ1Tz3MBZgv2a3j79
 +piBo/l5cEXlwSvaAutg6E94vfqOT/ta5uFSkTqJ2/yZBBa/6fJXzId1Inf0pGEkFK
 hGj7TWPBKn24w==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1G086zMtz9rxF;
 Mon, 31 Oct 2022 15:35:20 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87v8o0uxn5.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 31 Oct 2022 09:53:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Mon, 31 Oct 2022 14:35:19 +0000
Message-ID: <87k04ggixk.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> Anyway, if we do decide to flip the switch, it should be through
>> project-kill-buffer-conditions, so the user can make a different
>> choice through customization.
>
> project-kill-buffer-conditions doesn't work, I've tried it, it has this
> fundamental-mode thing there that makes it impossible.  Supposedly it is
> there to serve some purpose that no-one seems to be able to find a
> argumentative basis for.

The condition can be written entirely, if we are willing to accept a
breaking change.  In the case of `project-kill-buffer', this ought to be
acceptable if fewer buffers are killed.

> It's quite clear that _some_ non-file-visiting buffers can be considered
> as belonging to a project's working set.  But it's very very easy to
> come up with many that cannot be considered so.

I have to admit that I am more and more inclined to make the list a
opt-in thing, where  we explicitly mark those major modes that are tied
to a project.

> Because "killing buffers" is a destructive operation, being greedy here
> is a really bad design decision, as it catches an arbitrary number of
> unsuspecting extensions off-guard, which have been using earmuffed
> buffers for many years.=20=20
>
> All in all, it's like you're making a gun that only backfires 5% of the
> time.
>
> In the little time I've used this feature since the start of this
> discussion I have discovered it backfires no small number of occasions:
> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
> even *ibuffer* itself is targeted by this.
>
> Project-kill-buffers is off. Its intention pretty useful, but its
> implementation is a blunder.  The root cause is this overgreedy
> project-buffers.  When "killing a project" the echo area asks me if I
> want to kill a number of buffers that I didn't even know I had, because
> of hidden buffers.  This cannot be logical and the only way the
> "argument can be made both ways" is out of stubborness.
>
> JSONRPC's buffers are hidden implementation details: the argument that
> they are somehow under the responsibility of project.el just because it
> can see them through (buffer-list) is blind tiranny.
>
> The mini-languages invented in project-kill-buffers-conditions and
> project-ignore-buffer-conditions are abominations.  If project-buffers
> just been conservatively designed, we'd need nothing more than the
> existing hooks for the exceptions.  *earmuffed* buffers interested in
> opting in could declare if it belonged or not in one line.=20=20

What existing hooks?

>                                                             Just like
>
> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
> index dc3ed52650..718bebc7cd 100644
> --- a/lisp/vc/vc-dispatcher.el
> +++ b/lisp/vc/vc-dispatcher.el
> @@ -179,6 +179,7 @@ vc-setup-buffer
>    (let ((camefrom (current-buffer))
>  	(olddir default-directory))
>      (set-buffer (get-buffer-create buf))
> +    (setq-local project-owned t)
>      (let ((oldproc (get-buffer-process (current-buffer))))
>        ;; If we wanted to wait for oldproc to finish before doing
>        ;; something, we'd have used vc-eval-after.
>
> To name one.  The above is just the converse of the solution proposed by
> Philip before.

I would be fine with this in principle, my only worry is backwards
compatibility for those who use project.el from ELPA.

> Anyway, I've now suggested and presented 2 actually tested, actually
> working patches to project.el.  I don't have anything more to add.
>
> Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 17:12:01 +0000
Resent-Message-ID: <handler.58839.B58839.166723630414582 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166723630414582
          (code B ref 58839); Mon, 31 Oct 2022 17:12:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:11:44 +0000
Received: from localhost ([127.0.0.1]:41663 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opYK8-0003n7-D7
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:11:44 -0400
Received: from mail-wr1-f50.google.com ([209.85.221.50]:35755)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opYK6-0003ms-Hd
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:11:42 -0400
Received: by mail-wr1-f50.google.com with SMTP id l14so16927903wrw.2
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:11:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=LyVOzv8QeL/S6QgA061ar44GGunnx7lR1gbf/9ieroY=;
 b=S5JT9XNYGn7Qp9lg6l4FlpZNrWZ+4LexSrezoJKRrgcui9kmNOtc0lcfpgWXh26Y2d
 2xHBIIe/GsMyqHDnTIq/h3cMmtewO2n0i6l2vAFnMfhNV9FNBFqqMTehwJpLNvcZlpic
 KApT1wFVjgnKHs+eRukInVZdlB792zDELmUtLH42pKWV2KBbSWvRg2s7XjgEqneybj6W
 cI02CX8rsA0WgtWoHYJgq9Ya5OBD1lshKceyCxTxW8aqM6is3nY2mPvVG0PTJaZpka4u
 2ZFSwpC5LXGKCVjLDo2HLS77aU/AkZgR+WZDLwgvjPhSNDhM373KAwNvC8nhW/y8Vxp6
 hA2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=LyVOzv8QeL/S6QgA061ar44GGunnx7lR1gbf/9ieroY=;
 b=cs2ngiPT13AT6XeO3BEHrJi71tqogTzSc8ldQDH0OjHIoor7jkO0rKPmOsOEvUhf9Y
 AIEhgE0dAebZTNbM+vMD51PV4qt09fZmpiVuBnlcjQLSJ+2hb2IvC1V7ceaz5iKHISJE
 9L0PjLOdMGcFipFEbj0bYkZiHKoiMQdz4+7w6UmL2IVIhy/NcrNyQ4DXt2Acnq022GiP
 IK5iZuLcwI5LpjuLBE90W2FN4SWbYGiK1XyPDt5sd+S0QTEd/qxuiLaO37F8cQG1sIl1
 EM3Jg4sdQlfpU+LGXDtPNtd//tbrwCgQl+eyJRcuuN7gwPRVitslicUja9sI2aou0B64
 HTcQ==
X-Gm-Message-State: ACrzQf0qjxWf710xFiI8FDMi/z8vK2cM/+QP8dl+/sAun2MEPeaFrAbL
 lNJ4wMACVsnHaM41LwGDq9o=
X-Google-Smtp-Source: AMsMyM5xDBrLd1m1e3uR1MWgi+EqnMy9WiQCMh4dVEtGtAajkJ5QvX1Y02oAtkkfmAAzP5VHYf980A==
X-Received: by 2002:adf:dd12:0:b0:236:6ef7:dacf with SMTP id
 a18-20020adfdd12000000b002366ef7dacfmr8712454wrm.204.1667236296505; 
 Mon, 31 Oct 2022 10:11:36 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 n25-20020a05600c181900b003b95ed78275sm7452283wmp.20.2022.10.31.10.11.35
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Oct 2022 10:11:35 -0700 (PDT)
Message-ID: <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN>
Date: Mon, 31 Oct 2022 19:11:33 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 31.10.2022 13:56, João Távora wrote:
> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN 
> <mailto:joaotavora@HIDDEN>> wrote:
> 
>  > In the little time I've used this feature since the start of this
>  > discussion I have discovered it backfires no small number of occasions:
>  > Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
>  > even *ibuffer* itself is targeted by this.
> 
> And you can add the gnus mail buffers to this list. If you are unlucky
> enough to start M-x gnus from a project file to read your email, then
> closing that project in the future will take your gnus session, your
> summary buffers, messages, etc. with it.  This can't possibly be considered
> an exotic use case, and can't be right.

Does Gnus use fundamental-mode for some of its important buffers?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 17:25:01 +0000
Resent-Message-ID: <handler.58839.B58839.166723705415716 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, philipk@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166723705415716
          (code B ref 58839); Mon, 31 Oct 2022 17:25:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:24:14 +0000
Received: from localhost ([127.0.0.1]:41668 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opYWD-00045Q-Mk
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:24:14 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:44554)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opYWB-00045C-EO
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:24:11 -0400
Received: by mail-wm1-f48.google.com with SMTP id
 bg9-20020a05600c3c8900b003bf249616b0so8451468wmb.3
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:24:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=Ta2WQZhnjG0Uso3my7ceKcuo6U8JLjjVMTlWcFbr45g=;
 b=m+it+D5cDrtyrhvPZ/ekjiRLo2G3f+/mzzvSNP3g41LJabyUH5zR+49leZo1RgMO78
 6QLXBVb4NW0FwWkXhTnGD3BiKK0ykKx954hp3TXDczOaoEJ5/pA28zkUdAQCuezdKXRz
 2YKTM3Nww93VxCYRhxx/vhiO2CA3jfcXFt43ENuwLKRxhCU50R5HzvjfOH8fb5V5djdj
 nUV0h34YccG8eSI3SUZKE9hsnHmZ3JJrEnV4iywNQ5XGDezQ+OP0ZVyEPb3UydQUVF4S
 IDZfcIE/VNcRnbxiLNX4iijqMQaqbDuslqiRnUiP0HTuNbO+WLUQb+Tq6OCp6Ppp+f33
 ya3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=Ta2WQZhnjG0Uso3my7ceKcuo6U8JLjjVMTlWcFbr45g=;
 b=ndj+7gAaxITYRcmGuuE92C3UXvTdZCGqpOUaGU4gbbK5WUjcarffR3qvgFUxF6z5dV
 i1UqX1NDsTilHdLYv0Su8btaJXYvGMPUp1JwAlTK6qLfXhJ9bQyExHff8MAXCaNJzZo+
 0SJbCEw1hmSAYbLB/wNmVacg3QGGbCwtXzucOYaZCq2rivl0DIJZJgudfaLG6xSu3pzV
 UUx94p4k3fp66Dj9qERBsp7++BtVS4ZCYiukJmmf4iDYyXacysa6mQ2UqGN/ZIxwDKF3
 vZOtwmfNKrvHwNzeVBrzqwHSStXON52BXe7FoC4ely/bbuKAl4q+NeJ44UHQk5eI2Kjl
 WIWg==
X-Gm-Message-State: ACrzQf3K9yLm3ITWHqrzENsm6LUIp9HjtAzvanAElcc9sWuTmLHEeFxR
 WjfM5X0C9BDuMCNlfWzNAM8=
X-Google-Smtp-Source: AMsMyM7swsttZIPLfpBG/DqT5CcHxjKWCeWcPoB9/C3eflvtYmMXcycCfm6a6Qwul9oSyS6mcXlvKw==
X-Received: by 2002:a1c:5454:0:b0:3cf:7521:3543 with SMTP id
 p20-20020a1c5454000000b003cf75213543mr2713287wmi.172.1667237045157; 
 Mon, 31 Oct 2022 10:24:05 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 y10-20020a5d620a000000b0023657e1b97esm7744171wru.11.2022.10.31.10.24.04
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Oct 2022 10:24:05 -0700 (PDT)
Message-ID: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
Date: Mon, 31 Oct 2022 19:24:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87v8o0uxn5.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 31.10.2022 11:53, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> Anyway, if we do decide to flip the switch, it should be through
>> project-kill-buffer-conditions, so the user can make a different
>> choice through customization.
> 
> project-kill-buffer-conditions doesn't work, I've tried it, it has this
> fundamental-mode thing there that makes it impossible.  Supposedly it is
> there to serve some purpose that no-one seems to be able to find a
> argumentative basis for.

What have you tried?

This should take care of the specific complaint about unknown 
"invisible" buffers:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..1e7573c740 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
  (defcustom project-kill-buffer-conditions
    '(buffer-file-name    ; All file-visiting buffers are included.
      ;; Most of the temp buffers in the background:
-    (major-mode . fundamental-mode)
+    (and
+     (major-mode . fundamental-mode)
+     (not "\\` "))
      ;; non-text buffer such as xref, occur, vc, log, ...
      (and (derived-mode . special-mode)
           (not (major-mode . help-mode)))


> It's quite clear that _some_ non-file-visiting buffers can be considered
> as belonging to a project's working set.  But it's very very easy to
> come up with many that cannot be considered so.
> 
> Because "killing buffers" is a destructive operation, being greedy here
> is a really bad design decision, as it catches an arbitrary number of
> unsuspecting extensions off-guard, which have been using earmuffed
> buffers for many years.
> 
> All in all, it's like you're making a gun that only backfires 5% of the
> time.

Yours is the first instance so far.

> In the little time I've used this feature since the start of this
> discussion I have discovered it backfires no small number of occasions:
> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
> even *ibuffer* itself is targeted by this.

Of course it is targeted: we want ibuffer buffers to be killed just as 
well when killing a project. And sly-scratch, and etc.

> Project-kill-buffers is off. Its intention pretty useful, but its
> implementation is a blunder.  The root cause is this overgreedy
> project-buffers.  When "killing a project" the echo area asks me if I
> want to kill a number of buffers that I didn't even know I had, because
> of hidden buffers.  This cannot be logical and the only way the
> "argument can be made both ways" is out of stubborness.
> 
> JSONRPC's buffers are hidden implementation details: the argument that
> they are somehow under the responsibility of project.el just because it
> can see them through (buffer-list) is blind tiranny.
> 
> The mini-languages invented in project-kill-buffers-conditions and
> project-ignore-buffer-conditions are abominations.

This is the point where I'd normally blacklist you again.

> diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
> index dc3ed52650..718bebc7cd 100644
> --- a/lisp/vc/vc-dispatcher.el
> +++ b/lisp/vc/vc-dispatcher.el
> @@ -179,6 +179,7 @@ vc-setup-buffer
>     (let ((camefrom (current-buffer))
>   	(olddir default-directory))
>       (set-buffer (get-buffer-create buf))
> +    (setq-local project-owned t)
>       (let ((oldproc (get-buffer-process (current-buffer))))
>         ;; If we wanted to wait for oldproc to finish before doing
>         ;; something, we'd have used vc-eval-after.
> 
> To name one.  The above is just the converse of the solution proposed by
> Philip before.
> 
> Anyway, I've now suggested and presented 2 actually tested, actually
> working patches to project.el.  I don't have anything more to add.

They are not much better than the "patch" I showed for Eglot, 
correctness-wise.

And mine would make it safe against any kill-buffer calls, including 
ones issued by the user.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 17:34:01 +0000
Resent-Message-ID: <handler.58839.B58839.166723762516633 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166723762516633
          (code B ref 58839); Mon, 31 Oct 2022 17:34:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 17:33:45 +0000
Received: from localhost ([127.0.0.1]:41678 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opYfR-0004KC-6H
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:33:45 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:40901)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opYfO-0004Jx-Uq
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 13:33:43 -0400
Received: by mail-wm1-f52.google.com with SMTP id
 v124-20020a1cac82000000b003cf7a4ea2caso664691wme.5
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 10:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=N9XlXDeVAZEYgERBqO5Kk0aGERaP1YucMRandt0Cpdk=;
 b=HTAoFcejJTdlUa3/kBROsfq9b0ftuSdudfekyAp6v9zoghHu5HhCFCXvSvJOvpT1Us
 NxF85YLeJdDonTdi8I02WcXmBjSsTcyuZREm4CMHfKByVxhun8PA0CvfqjMZr7W17okR
 uY7OnUKkOfTjh5c2P2CJvLhlACXGtUVqC8eaNCxl4hzm3HJkRUnD90fwCxkZh8tWHhU4
 vKIQZrp8iVEv3uUSeuwt7nUPY6FuvGSH6peYCtDc0A7MF3s9DSLncGcvEajmUFJyRFfI
 gHf/7vm/tjTJvfrVHYJZ2bECM2yNsPFpm2hCSeaAv18wNwXpeMckat+Vq68fv9PyqqoJ
 KmwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=N9XlXDeVAZEYgERBqO5Kk0aGERaP1YucMRandt0Cpdk=;
 b=PlAqwIy3WJUiam6EVd8tEwZsngYjjwZYAFaVMQedJCF+Zq7b94o2OeUXbz403sCpts
 LHo9op2hKXwEaTS0deiprGEhJiyaEJK2N4+MNEkbbcCzzEBnAAjBTX17b5BffWvCo6NB
 LutwgZdz97F1SErg7hdbd2rYDeWtRuVtSJCNouYZKP4zFKe1RZ0W9G+J9XXXeU0uHxG9
 q6VuTjEovvSE39BECb9nUskhu6K4UEDoZd4z1MZB8i3SMtF/adzgSi7aE1tJBF6pkL+l
 DAWWn6IoW3VIiE9JrrjjFB65HNBvoSNE39x/DHDJE2V+dneHr4CEGY1KU3zdLvGYyD2q
 D+pg==
X-Gm-Message-State: ACrzQf3vKaA1yIoPa1q9/iA4y459IBejYs62EKWivYh8hb05koKOx3LW
 hnWSA/r5pxEOrlxGc1K99LI=
X-Google-Smtp-Source: AMsMyM7FYffK1MSN46erx+1Wxe2rBcrr1EUa0asr73IM5Wz5VmDDDsXOg7VXaOdQrIyAWnG3yLn9iw==
X-Received: by 2002:a05:600c:26cb:b0:3cf:6265:ddc6 with SMTP id
 11-20020a05600c26cb00b003cf6265ddc6mr9271523wmv.195.1667237617195; 
 Mon, 31 Oct 2022 10:33:37 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 r2-20020adfe682000000b002365b759b65sm7775476wrm.86.2022.10.31.10.33.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Oct 2022 10:33:37 -0700 (PDT)
Message-ID: <83071f7d-db56-5017-c47c-e5b069dcf2bf@HIDDEN>
Date: Mon, 31 Oct 2022 19:33:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <87k04ggixk.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87k04ggixk.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 31.10.2022 16:35, Philip Kaludercic wrote:
>> It's quite clear that_some_  non-file-visiting buffers can be considered
>> as belonging to a project's working set.  But it's very very easy to
>> come up with many that cannot be considered so.
> I have to admit that I am more and more inclined to make the list a
> opt-in thing, where  we explicitly mark those major modes that are tied
> to a project.

The current contents of project-kill-buffer-conditions are more or less 
that already.

With the exception of the 'fundamental-mode' entry which creates an 
open-ended set. That one we could remove, or tweak by adding a buffer 
name condition, or a variable lookup.

My guess is that nobody will bother with setting the new variable, 
though (call it 'project-owned' or whatever), because killing project 
buffers is not an essential need for any 3rd party package, just 
something nice to have.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 20:36:01 +0000
Resent-Message-ID: <handler.58839.B58839.16672485435327 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16672485435327
          (code B ref 58839); Mon, 31 Oct 2022 20:36:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 20:35:43 +0000
Received: from localhost ([127.0.0.1]:41946 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opbVW-0001Nr-Mn
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:35:42 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:36592)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opbVV-0001Nd-3b
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:35:41 -0400
Received: by mail-wm1-f43.google.com with SMTP id
 c3-20020a1c3503000000b003bd21e3dd7aso11553846wma.1
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 13:35:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=dAaX2t/8dsMjjBc30G7/9YJxBbyydyqCZIrzdVt2xL0=;
 b=OeRQ2xrkJA8W/5bMW8Y5mudts0D9DdatytCkKb9BPuqX4C2aj6vJFHE6fQV0qwC/zy
 JC39CGLZQCZSPw5JlqEXVwe//Pch+DBp8B6b6kCua+wuq1IXLFWIVksKPg7Udt4JwGro
 rRS7+ObJD+0j77giRZ1Z1ipZ5M5zRbm2pLtnhJCmdqT12K40ZyZbcjBx/MG6AZtZYohh
 vp43z2dr9kOsl0Ij0MEQtS3IZJ3o3Z0SrKfwouxQB43IuaFsqstoZ2oStKOevjHVDZkR
 cqn22uhEKkP4+6iTkJyxMCTKjB87+kDqHkX+0OGp11zzwSfPKp/JhvqCkLY6/pOuQ7n6
 G2nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=dAaX2t/8dsMjjBc30G7/9YJxBbyydyqCZIrzdVt2xL0=;
 b=NxIpq3zPdnI/6hoH53x3PThoujCzYWT5wrtUT6mDU6dPch664ZITPIHh91yenrUWQq
 zWEnNs/0Cx2Wl/UCf67mMR86IbTS/lTo51nyqrcw8lTcdE39O1S0z2xUP6YhyyMFLNTr
 zAv+y4NkUTUgnUl+wUKNUUPpyDUROQ33P+0uI2Sa31/aLez0+2YxsxTBOrN8Gqi5k+xK
 TdwYNFgkENN3BO7biEYq1/yuMDd+fI+mMj0mK3jeD/MkB2CihjzgYM+zaoueA7+wmiL3
 TJjP8NV19eI47OYaf5BXISYm/NAwW+prj9mDjNIxZmgqawFQFDIZg3bN2iJOCPuwBsq4
 H9DA==
X-Gm-Message-State: ACrzQf0BUrGpBjINmY53gK3fUtlFlh9255zZ5kgAy/PsECWX/VUqryDq
 x6mIBPfJJRb5YjtObSalGME=
X-Google-Smtp-Source: AMsMyM7/JrwaY1Jbw+xDKqgMGy2PA8eDmOTWL7UxAHHWNdRKaTrX5sxeav4wPaVaOJLdWgSzWKf7nQ==
X-Received: by 2002:a05:600c:21d7:b0:3cf:7d8a:42e2 with SMTP id
 x23-20020a05600c21d700b003cf7d8a42e2mr242171wmj.202.1667248534969; 
 Mon, 31 Oct 2022 13:35:34 -0700 (PDT)
Received: from krug ([87.196.74.163]) by smtp.gmail.com with ESMTPSA id
 w24-20020a1cf618000000b003cf4d99fd2asm8290915wmc.6.2022.10.31.13.35.33
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Oct 2022 13:35:34 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Oct 2022 19:11:33 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
 <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN>
Date: Mon, 31 Oct 2022 20:36:43 +0000
Message-ID: <87k04fvig4.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Dmitry Gutov writes: > On 31.10.2022 13:56, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
   wrote: >> On Mon, Oct 31, 2022 at 9:52 AM =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN
    >> <mailto:joaotavora@HIDDEN>> wrote: >> > In the little time I've used
    this featu [...] 
 
 Content analysis details:   (3.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.128.43 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.128.43 listed in list.dnswl.org]
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Dmitry Gutov writes: > On 31.10.2022 13:56, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
   wrote: >> On Mon, Oct 31, 2022 at 9:52 AM =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN
    >> <mailto:joaotavora@HIDDEN>> wrote: >> > In the little time I've used
    this featu [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.128.43 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.128.43 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 31.10.2022 13:56, Jo=C3=A3o T=C3=A1vora wrote:
>> On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.=
com
>> <mailto:joaotavora@HIDDEN>> wrote:
>>  > In the little time I've used this feature since the start of this
>>  > discussion I have discovered it backfires no small number of occasion=
s:
>>  > Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...=C2=
=A0 Heck
>>  > even *ibuffer* itself is targeted by this.
>> And you can add the gnus mail buffers to this list. If you are
>> unlucky
>> enough to start M-x gnus from a project file to read your email, then
>> closing that project in the future will take your gnus session, your
>> summary buffers, messages, etc. with it.=C2=A0 This can't possibly be co=
nsidered
>> an exotic use case, and can't be right.
>
> Does Gnus use fundamental-mode for some of its important buffers?

No idea.  gnus-summary-modes is one of the modes

Try:

emacs -Q
C-x C-f some/file/in/a/project/foo.c
M-x  gnus ; Remember to check your email
; read mail, make searches, etc
C-x b foo.c ; go back to the file
C-x p k ; Get preposterous confirmation prompt about tens of buffers about =
to be killed
        ; say yes, bye all those emails=20

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 20:58:01 +0000
Resent-Message-ID: <handler.58839.B58839.16672498777925 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, philipk@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16672498777925
          (code B ref 58839); Mon, 31 Oct 2022 20:58:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 20:57:57 +0000
Received: from localhost ([127.0.0.1]:42039 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opbr3-00023l-0V
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:57:57 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:45634)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opbr0-00023X-QH
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 16:57:55 -0400
Received: by mail-wr1-f53.google.com with SMTP id y16so17635657wrt.12
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 13:57:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=lsn3XQe7Ji5EgsyBMz3YSrRqnULH2tUMqWo2j9RseZE=;
 b=g12U5DJh2JEbSwR3kZ5cv81YV5lFwM//1OX7oz1BnWfKqCoAtLg77OZTVQqRxNwBSU
 mt4jQZCJbjPMUMwXewPitd+R6n6vYyVL2ql0yYeq0LajUrPMQeiD7cmyuoK1oSFW5WZ0
 kAL9FYhE+xzOFBfn9HZS2BSUh0iotp2u3MdJdpAKfaJX/840u9WFBn3H5g7XYGiZnOTS
 rVqKKbxIY0JBcFmlKlDdlCBKKCGUEG+bca6SaqwG8rsCqhcZInB+18b7hkOutWmO61h7
 HLrwO8JB+5QOYz9lOvXarJfY6OoCMbu6hlVnX0hsnr+jwhJBiZBVcW8LoZfe+XDod8e2
 fE4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=lsn3XQe7Ji5EgsyBMz3YSrRqnULH2tUMqWo2j9RseZE=;
 b=FxSJF9hU3u7CR8Uwar5xzlIbL6doVwDWZnXgitrCCr0PztUVssF9CHK9HXKmIf5clg
 /P8+i9AkOGIvl115FJ/HjstJGgKxcGonGP9xPb9wsWmaQXMD7m5434RIMG/ex1bYA21j
 l+RMDNJXImPOA/GNRYEbN2lP+FZAMMV6kU/OPmIGxxwVug69KuFRkcwsYqijG9GCXG//
 pAFF7VVpCNTKNAtKXa89FdhRWjeaIVaxCC+BWgW1bwfTjgiQ4dGMn+vC4095mHH/5bUc
 fuYLmVOV1ikpvxTjeOLU2hKBk4hqRHTXSNG0JY8/5mFWgGksMHPRGo+ItRewWXUuvmPD
 /99w==
X-Gm-Message-State: ACrzQf2n5Za8sKAyX+2FF2Rw1lccstvT+Pc9pvAgFMJY8U9yCHzyWcXt
 8aOVAbUoq03waP66RSlAbyA=
X-Google-Smtp-Source: AMsMyM6rYjIniTz20tqNcgcPRZ5G6txt3YpLAOrQw1OfglCh6aWJbxJ3rA4+/3RPwmbl3ZK6fYporw==
X-Received: by 2002:a5d:494f:0:b0:236:a691:676c with SMTP id
 r15-20020a5d494f000000b00236a691676cmr9624087wrs.51.1667249868669; 
 Mon, 31 Oct 2022 13:57:48 -0700 (PDT)
Received: from krug ([87.196.74.163]) by smtp.gmail.com with ESMTPSA id
 k18-20020adfe3d2000000b00236705daefesm8005441wrm.39.2022.10.31.13.57.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Oct 2022 13:57:48 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Oct 2022 19:24:02 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
Date: Mon, 31 Oct 2022 20:58:57 +0000
Message-ID: <87edunvhf2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Dmitry Gutov writes: > diff --git a/lisp/progmodes/project.el
 b/lisp/progmodes/project.el > index ac278edd40..1e7573c740 100644 > ---
 a/lisp/progmodes/project.el
 > +++ b/lisp/progmodes/project.el > @@ -1223,7 +1223,9 @@ p [...] 
 Content analysis details:   (3.6 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [209.85.221.53 listed in list.dnswl.org]
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (joaotavora[at]gmail.com)
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [209.85.221.53 listed in wl.mailspike.net]
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Dmitry Gutov writes: > diff --git a/lisp/progmodes/project.el
    b/lisp/progmodes/project.el > index ac278edd40..1e7573c740 100644 > --- a/lisp/progmodes/project.el
    > +++ b/lisp/progmodes/project.el > @@ -1223,7 +1223,9 @@ p [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.221.53 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.221.53 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Dmitry Gutov <dgutov@HIDDEN> writes:

> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..1e7573c740 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
>  (defcustom project-kill-buffer-conditions
>    '(buffer-file-name    ; All file-visiting buffers are included.
>      ;; Most of the temp buffers in the background:
> -    (major-mode . fundamental-mode)
> +    (and
> +     (major-mode . fundamental-mode)
> +     (not "\\` "))
>      ;; non-text buffer such as xref, occur, vc, log, ...
>      (and (derived-mode . special-mode)
>           (not (major-mode . help-mode)))

Thanks.  If that works, go ahead and push it.

This should work around this specific bug and then we can open another
one to follow up on all the disaster that has unfolded since.

>> In the little time I've used this feature since the start of this
>> discussion I have discovered it backfires no small number of occasions:
>> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
>> even *ibuffer* itself is targeted by this.
> Of course it is targeted: we want ibuffer buffers to be killed just as
> well when killing a project. And sly-scratch, and etc.

No, we don't want.  *sly-scratch* is a global scratchpad for the Common
Lisp connection that can "service" many Common Lisp projects, to use
your own terminology.

Do you know what M-x ibuffer does? It's a manager for all the buffers in
all the projects in Emacs.  In the earmuffed *ibuffer*, it gives you an
overview of all visited buffers, sorted and organized by various
criteria.  Again, *ibuffer* can't possibly be taken to "service a
project".  Destroying this buffer's state because the user decided to
kill a project is simply wrong.  It's very plain to see that.

And *Shell Command Output* where it is impossible to know in advance if
the contents refer to a specific project or not.  It depends on what the
user typed after M-|!

And the Gnus buffers?  And the CIDER report?

>> you're making a gun that only backfires 5% of the time.
> Yours is the first instance so far.

We seem to use different algebraic systems.

>> The mini-languages invented in project-kill-buffers-conditions and
>> project-ignore-buffer-conditions are abominations.
> This is the point where I'd normally blacklist you again.

I had no idea who authored those variables.  If you are among the
authors, I'm very sorry, I was referring merely to code.  I said before
I'm quite happy with project.el, but this (small) part of it is very
badly done.

> They are not much better than the "patch" I showed for Eglot,
> correctness-wise.

Of course they are, they are opt-in.  So project.el's C-x p k doesn't
destroy packages' essential buffers just because of some overly greedy
heuristic.  Using this idea, we make a conservative heuristic better, on
a case by case basis.

> And mine would make it safe against any kill-buffer calls, including
> ones issued by the user.

Should I really to explain again that a hidden buffer is hidden from the
user and thus he can't reasonably M-x kill-buffer on it?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 22:27:02 +0000
Resent-Message-ID: <handler.58839.B58839.166725521516637 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166725521516637
          (code B ref 58839); Mon, 31 Oct 2022 22:27:02 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:26:55 +0000
Received: from localhost ([127.0.0.1]:42169 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opdF8-0004KG-It
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:26:54 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:41550)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opdF5-0004K2-Sr
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:26:52 -0400
Received: by mail-wm1-f52.google.com with SMTP id
 fn7-20020a05600c688700b003b4fb113b86so8926714wmb.0
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:26:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=1CdgKWJzXveRpuLFg0+GM8NRAgO0dmhgdGzC7o6qaF8=;
 b=g7LE4PCKoUpVkZt3QK333jUVjSA5G7R+JymqUelosqTAXZXHIfo33lSzYCBCYr5E38
 XNEaA9hD80V9a6VSh0UrtcPW7dutmG37iIGBGFzHIEJHTqAkwDlwGMrbf6NBwEqEmmEp
 DEffvTBY+9YQdiqBmjlMs+NmrPMh9MGWxMtQ/8OLhImEV8UM++1XmlpT+NIGHBNloazs
 E74FR/GOLTgrT9xZvSOjWZFjsFUIk2F6DMdOWUXmcATHPHxKdiR9s67rEew4lo804DLa
 q4lMtJ/062UAau1O2uDLVuciASDUhuiCKIK8D7197xkoWsfbRReOtBmVEabwuP3J/GyK
 8rgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=1CdgKWJzXveRpuLFg0+GM8NRAgO0dmhgdGzC7o6qaF8=;
 b=fIsjQXQNJullghF1Ou0PMEADpiPlNqicQ9n/nOUiQfOXverdiZbTfDQ5WxuLfkEe8u
 nWDjzOuE/4hTyZa+kMgM0icH+4wcA7dV9BsV5OEFvuIZu8vVxIKcyBXW7AaHU4+0bbNh
 7u+kbIf8AGdIw3R6pJ+7ZNIHEXL6rd0IL82QdspjeLZhVgdByLxbD5llnXMhx5tFrp4O
 p2OFxMKCZaGDrP+IkYyzZa5Khabq3azbQ71kcrAEusvZBnFGCzN6whu3BNo34j4l44k9
 YOibe4unlhFazN1wc0e3z+GDVBsmjO3X4XkRW2GkaqSe38Pz9asCuFDiZYIHJ391cR55
 Xq3g==
X-Gm-Message-State: ACrzQf0COM1BZM6w5LSQadF1yNWAJFAKgqr1dHv1ikgDBLFve4iun4JE
 ZKCjyMr2LZJIuFlI+4NeJTw=
X-Google-Smtp-Source: AMsMyM7gSNYFE9clmccbkdb8WBNNAGWr8HHj5zTfmML1M/rH4WYqR57z/AwEftQdtpxlN6eX7KFLQw==
X-Received: by 2002:a05:600c:2287:b0:3cf:4dfb:c223 with SMTP id
 7-20020a05600c228700b003cf4dfbc223mr17753265wmf.19.1667255205872; 
 Mon, 31 Oct 2022 15:26:45 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 q8-20020a5d5748000000b0023677081f3asm8213400wrw.42.2022.10.31.15.26.44
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Oct 2022 15:26:45 -0700 (PDT)
Message-ID: <5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN>
Date: Tue, 1 Nov 2022 00:26:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
 <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN> <87k04fvig4.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87k04fvig4.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 31.10.2022 22:36, João Távora wrote:
> Dmitry Gutov<dgutov@HIDDEN>  writes:
> 
>> On 31.10.2022 13:56, João Távora wrote:
>>> On Mon, Oct 31, 2022 at 9:52 AM João Távora <joaotavora@HIDDEN
>>> <mailto:joaotavora@HIDDEN>> wrote:
>>>   > In the little time I've used this feature since the start of this
>>>   > discussion I have discovered it backfires no small number of occasions:
>>>   > Eglot, CIDER,*scratch*,*ielm*,*sly-scratch*,*Completions*,...  Heck
>>>   > even*ibuffer*  itself is targeted by this.
>>> And you can add the gnus mail buffers to this list. If you are
>>> unlucky
>>> enough to start M-x gnus from a project file to read your email, then
>>> closing that project in the future will take your gnus session, your
>>> summary buffers, messages, etc. with it.  This can't possibly be considered
>>> an exotic use case, and can't be right.
>> Does Gnus use fundamental-mode for some of its important buffers?
> No idea.  gnus-summary-modes is one of the modes
> 
> Try:
> 
> emacs -Q
> C-x C-f some/file/in/a/project/foo.c
> M-x  gnus ; Remember to check your email
> ; read mail, make searches, etc
> C-x b foo.c ; go back to the file
> C-x p k ; Get preposterous confirmation prompt about tens of buffers about to be killed
>          ; say yes, bye all those emails

I suppose it might match

   (and (derived-mode . special-mode)
        (not (major-mode . help-mode)))

then.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 22:51:02 +0000
Resent-Message-ID: <handler.58839.B58839.166725665819040 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166725665819040
          (code B ref 58839); Mon, 31 Oct 2022 22:51:02 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:50:58 +0000
Received: from localhost ([127.0.0.1]:42204 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opdcP-0004x1-Pn
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:50:58 -0400
Received: from mail-wr1-f52.google.com ([209.85.221.52]:36406)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opdcO-0004wo-Mh
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:50:57 -0400
Received: by mail-wr1-f52.google.com with SMTP id j15so17989083wrq.3
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:50:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=HfDjTwcYtq2bAiely7jwUrRiOLW3bm8lz0i+fgxZiDw=;
 b=MbQ8j4+UL3RYx/7vApv/pOb0CASx0/1t4S5tfhx1yh/P3LssVjvlfImPcrXuQqH4bz
 XiNR4zoNhbAm9j5A28F5C1WMHHd+j8ifk6sR27N3wX9AiU82FQRGQEUBIaQwhp1DLSAm
 5kYzlmqMNfzb+QrqZFuUmBC2STqEZvD1Q92C+cV4HJGb6g85otE4VDoIjoYp0GNHNVIF
 oYtqVH5uckhITx53qQ0c9yMAfK4diy3bw8QahaYK/kzWDq7Xb4ScBRwvkaNyUzSnXXPO
 8wXWQTmbakQHUDaj0SYQXOXYPLyhotPr8ReR8R6lSzOVoMxWSNWEL9R2bzi5/JlPlfDP
 7GCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=HfDjTwcYtq2bAiely7jwUrRiOLW3bm8lz0i+fgxZiDw=;
 b=UD3eJTCl81Azm7U8NEVXOx2BFh+rqvJA/5KKuShKhT1NWfnuwVikJ2gY4rlIZeXQWP
 D2BtLxxbaXMkODLxoWN42tOf1WyRT7yo2ehg8tx6OnJOemkwE6kPFwg0LuXqWCFcNc6e
 hE0df0frtdwPleulWlY4GF3xbOSR2aDJVRD1KdA5jjdFQ6KnBBT6fwqLgrk6Q/rZP98L
 +j8O670m19jQD7L3r8BgYLB2JYM9eRAqqcYiMWfqZr928Cd8swDIRj9aoHhT7SYHdSnw
 5etdHgD3zwQcuXgeM6iMNEeE2q7m6SsFb5Inb+cl/7x7GUM17fc1ZNrSugpYGrPyDCSg
 oGEw==
X-Gm-Message-State: ACrzQf0u+0ERJKdhCDiHZ8Y4XywdMABUNoQKu63Zc6XTC6+WtYM38QH3
 Z+S8Col2BwnwyZHA4bcl5xlIG5p1xGo=
X-Google-Smtp-Source: AMsMyM7izrjgEO7Jr6qYFMn1HxK4JrLZurzvOkgM8fxSocbS+vhKiwgRHckEuGaK9CgkVunHuVRa5A==
X-Received: by 2002:a5d:4889:0:b0:22b:214:38dd with SMTP id
 g9-20020a5d4889000000b0022b021438ddmr10117009wrq.32.1667256650679; 
 Mon, 31 Oct 2022 15:50:50 -0700 (PDT)
Received: from krug (87-196-74-163.net.novis.pt. [87.196.74.163])
 by smtp.gmail.com with ESMTPSA id
 u6-20020a05600c19c600b003c6f8d30e40sm8942207wmq.31.2022.10.31.15.50.49
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Oct 2022 15:50:50 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Nov 2022 00:26:43 +0200")
References: <87sfj8umwb.fsf@HIDDEN> <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <CALDnm50JAShuyzBn_cCCKo+sESk+Y6bhYjS7F_PWiV7YDyK3Fw@HIDDEN>
 <49cf7edf-afa7-9fce-f4ff-e3af7ad1c02d@HIDDEN>
 <87k04fvig4.fsf@HIDDEN>
 <5afc446b-3843-8bfc-f51d-713445a9d30f@HIDDEN>
Date: Mon, 31 Oct 2022 22:51:59 +0000
Message-ID: <87a65bvc6o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Dmitry Gutov writes: > On 31.10.2022 22:36, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
   wrote: >> Dmitry Gutov writes: >> >>> On 31.10.2022 13:56, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= wrote:
    >>>> On Mon, Oct 31, 2022 at 9:52 AM =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN
   >>>> <mai [...] 
 
 Content analysis details:   (3.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.221.52 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.221.52 listed in wl.mailspike.net]
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Dmitry Gutov writes: > On 31.10.2022 22:36, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
   wrote: >> Dmitry Gutov writes: >> >>> On 31.10.2022 13:56, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= wrote:
    >>>> On Mon, Oct 31, 2022 at 9:52 AM =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN
   >>>> <mai [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.221.52 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.221.52 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 31.10.2022 22:36, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry Gutov<dgutov@HIDDEN>  writes:
>>=20
>>> On 31.10.2022 13:56, Jo=C3=A3o T=C3=A1vora wrote:
>>>> On Mon, Oct 31, 2022 at 9:52 AM Jo=C3=A3o T=C3=A1vora <joaotavora@gmai=
l.com
>>>> <mailto:joaotavora@HIDDEN>> wrote:
>>>>   > In the little time I've used this feature since the start of this
>>>>   > discussion I have discovered it backfires no small number of occas=
ions:
>>>>   > Eglot, CIDER,*scratch*,*ielm*,*sly-scratch*,*Completions*,...=C2=
=A0 Heck
>>>>   > even*ibuffer*  itself is targeted by this.
>>>> And you can add the gnus mail buffers to this list. If you are
>>>> unlucky
>>>> enough to start M-x gnus from a project file to read your email, then
>>>> closing that project in the future will take your gnus session, your
>>>> summary buffers, messages, etc. with it.=C2=A0 This can't possibly be =
considered
>>>> an exotic use case, and can't be right.
>>> Does Gnus use fundamental-mode for some of its important buffers?
>> No idea.  gnus-summary-modes is one of the modes
>> Try:
>> emacs -Q
>> C-x C-f some/file/in/a/project/foo.c
>> M-x  gnus ; Remember to check your email
>> ; read mail, make searches, etc
>> C-x b foo.c ; go back to the file
>> C-x p k ; Get preposterous confirmation prompt about tens of buffers abo=
ut to be killed
>>          ; say yes, bye all those emails
>
> I suppose it might match
>
>   (and (derived-mode . special-mode)
>        (not (major-mode . help-mode)))
>
> then.

Whatever it's doing, it's completely wrong and must be fixed.  It
probably break other email clients too.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 22:53:01 +0000
Resent-Message-ID: <handler.58839.B58839.166725672519191 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166725672519191
          (code B ref 58839); Mon, 31 Oct 2022 22:53:01 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 22:52:05 +0000
Received: from localhost ([127.0.0.1]:42210 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opddU-0004zS-BT
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:52:04 -0400
Received: from mail-wm1-f50.google.com ([209.85.128.50]:44957)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opddS-0004yx-6q
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 18:52:02 -0400
Received: by mail-wm1-f50.google.com with SMTP id
 bg9-20020a05600c3c8900b003bf249616b0so8939470wmb.3
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 15:52:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=+45H8LbZ0x7DUGVyAk4acA3gSCW5RKrP6pZg7ztxMSs=;
 b=kvavcqMDTHjq7Mj/8IgdxPuokayyIz2vdMMtr+g1NncTi0MSl42VXw6npf3s/ACVHv
 giSp+kem0qx4LifH13QIShajWu3rflD/WsPgAN8e8/s99CwzKvi1hhLuVN6Bc2lgSoYh
 7q6RrawvtfSRZL8T43JeBMWkU616S5ZQ9+fdKTpry6ACPOhj2nYeMTY2lD9MxG52Afi3
 fnonWMABfJ63DWkmGAyij/g5fOcURmcc8jotuGH24Ett2ydIJ7hRMZlVuVT8esiQaOad
 lq7fOwrstR6wFVrwHew3eObHtljWj4/q/QHBSVrZrUzDmZyamQNX/8UXw5WwoPQE6shv
 H5FA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=+45H8LbZ0x7DUGVyAk4acA3gSCW5RKrP6pZg7ztxMSs=;
 b=MBceVCnAlCs7IaUnZiUKGfFLGluou45hdI5cs/iJYtm9nxG5dGE1LLwU1FvnBlOfXb
 D0TIedypBRQjSSpsQeGUkJyRKcO9lt6mGzc0UwMpnsF0mCaMkahkrX5pClPuJCukGAfF
 MEzxHO2YCyqUurNl5DJvAcUw8KzDKRB7IrlsUXNZEAlQr/qvSJWxGwKkqx8AEO4ivAAI
 XivwbRW7rj3dewWPtOZTuHD+IMwoPaszynF5/k+iEswwWH5RyLS5nXigBPKGEmqn32R5
 wzM9vDBk5V3+43M9L/I5LNrHNhdK0vtF8peDnZ8be2tA3YESk13bzzY7LMr1UEVe4Grg
 vC4w==
X-Gm-Message-State: ACrzQf24+f++0BlvZEFLKGh8vqyDUtXRbONtwrI6kcNTMV10BvYV3p5+
 ckhOBavct9bHiNE4TRIkYOs=
X-Google-Smtp-Source: AMsMyM57hpk9nIlTB7L3luEJaoTHhpq+Lx1sDf8mRoQcBCCOSQ3A9NAcSXAPW7tUegBQnUoZ4KL//A==
X-Received: by 2002:a05:600c:21a:b0:3cf:6e78:8e89 with SMTP id
 26-20020a05600c021a00b003cf6e788e89mr6055012wmi.46.1667256716454; 
 Mon, 31 Oct 2022 15:51:56 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 bx10-20020a5d5b0a000000b0022e47b57735sm8431352wrb.97.2022.10.31.15.51.55
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Oct 2022 15:51:56 -0700 (PDT)
Message-ID: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
Date: Tue, 1 Nov 2022 00:51:53 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87edunvhf2.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 31.10.2022 22:58, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index ac278edd40..1e7573c740 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
>>   (defcustom project-kill-buffer-conditions
>>     '(buffer-file-name    ; All file-visiting buffers are included.
>>       ;; Most of the temp buffers in the background:
>> -    (major-mode . fundamental-mode)
>> +    (and
>> +     (major-mode . fundamental-mode)
>> +     (not "\\` "))
>>       ;; non-text buffer such as xref, occur, vc, log, ...
>>       (and (derived-mode . special-mode)
>>            (not (major-mode . help-mode)))
> 
> Thanks.  If that works, go ahead and push it.

I suggest you try it first.

Last time I launched Eglot was around several months ago.

> This should work around this specific bug and then we can open another
> one to follow up on all the disaster that has unfolded since.

Disaster, really?

>>> In the little time I've used this feature since the start of this
>>> discussion I have discovered it backfires no small number of occasions:
>>> Eglot, CIDER, *scratch*, *ielm*, *sly-scratch*, *Completions*,...  Heck
>>> even *ibuffer* itself is targeted by this.
>> Of course it is targeted: we want ibuffer buffers to be killed just as
>> well when killing a project. And sly-scratch, and etc.
> 
> No, we don't want.  *sly-scratch* is a global scratchpad for the Common
> Lisp connection that can "service" many Common Lisp projects, to use
> your own terminology.

Okay, you're probably right about at least some of those.

> Do you know what M-x ibuffer does? It's a manager for all the buffers in
> all the projects in Emacs.  In the earmuffed *ibuffer*, it gives you an
> overview of all visited buffers, sorted and organized by various
> criteria.  Again, *ibuffer* can't possibly be taken to "service a
> project".  Destroying this buffer's state because the user decided to
> kill a project is simply wrong.  It's very plain to see that.

I must have been thinking about project-* or projectile-* counterparts.

Like projectile-ibuffer or the homemade version for project.el made by a 
user in a bug report nearby.

> And *Shell Command Output* where it is impossible to know in advance if
> the contents refer to a specific project or not.  It depends on what the
> user typed after M-|!
> 
> And the Gnus buffers?  And the CIDER report?

Do you know whether CIDER will be satisfied by the same patch I sent 
previously?

>>> you're making a gun that only backfires 5% of the time.
>> Yours is the first instance so far.
> 
> We seem to use different algebraic systems.

This is literally the first bug report on the subject.

>>> The mini-languages invented in project-kill-buffers-conditions and
>>> project-ignore-buffer-conditions are abominations.
>> This is the point where I'd normally blacklist you again.
> 
> I had no idea who authored those variables.  If you are among the
> authors, I'm very sorry, I was referring merely to code.  I said before
> I'm quite happy with project.el, but this (small) part of it is very
> badly done.

I'm not the only author. Regardless, it's not a good language to use no 
matter who wrote it.

What you are doing is pressuring all other participants into your POV by 
means of an insult. That usually works better if the offending code was 
written by somebody who already left (the project/the discussion/the 
company/etc), or is a little younger.

>> They are not much better than the "patch" I showed for Eglot,
>> correctness-wise.
> 
> Of course they are, they are opt-in.  So project.el's C-x p k doesn't
> destroy packages' essential buffers just because of some overly greedy
> heuristic.  Using this idea, we make a conservative heuristic better, on
> a case by case basis.
> 
>> And mine would make it safe against any kill-buffer calls, including
>> ones issued by the user.
> 
> Should I really to explain again that a hidden buffer is hidden from the
> user and thus he can't reasonably M-x kill-buffer on it?

They can, though, even if odds are low. It can also happen through some 
other automation, which Emacs lets the users do freely.

I'm fairly sure that the solution I offered would be easy enough 
implement, to actually protect the vulnerable buffer.

I suppose we are not doing that, however.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Oct 2022 23:19:02 +0000
Resent-Message-ID: <handler.58839.B58839.166725830321900 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166725830321900
          (code B ref 58839); Mon, 31 Oct 2022 23:19:02 +0000
Received: (at 58839) by debbugs.gnu.org; 31 Oct 2022 23:18:23 +0000
Received: from localhost ([127.0.0.1]:42236 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ope2w-0005hA-Qo
	for submit <at> debbugs.gnu.org; Mon, 31 Oct 2022 19:18:23 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:39510)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1ope2u-0005gv-UV
 for 58839 <at> debbugs.gnu.org; Mon, 31 Oct 2022 19:18:21 -0400
Received: by mail-wr1-f53.google.com with SMTP id o4so18045510wrq.6
 for <58839 <at> debbugs.gnu.org>; Mon, 31 Oct 2022 16:18:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=Ah3ZhypLZ18loyzr9hJvDM6P63xasxK8+Pz9+ZVhwYU=;
 b=UQKrHiDSAg9LYyN+icLL+0EGUoI5DcKIhJqmO6FZYfmtxJr72TvVCmdnS5RjADDNXM
 A+D/yhzVLB6NujbPUlSq80LQ4fHI8g0NNQLS0s8BO6nq2jEVJilczUjV+Larx+F3wxMk
 T8J9WyJ+NsK2B9/3vixAlRglKCBJIAIDrQtsVJhQQ4Ex2TqaChr8evS4P+wqLJHRYyhP
 eYuzqH7MrDV5TPR44NF3L70rqFzMtLK+2FhIeTOdO6zJTAnyYIyWx0RmCVdNKYx4mQuc
 0afHpO1rD2+HDhPXV6k3YY43hZnPe7wBA7PdoFx6qtnbhJql+jv+QLrdcAf8r+BiyS6H
 vNug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=Ah3ZhypLZ18loyzr9hJvDM6P63xasxK8+Pz9+ZVhwYU=;
 b=d6RDpe6luWmsWScpgKAX2EVzpln7mj75zRpvYp4a5XY1Wl6/+Pm5rRRZ0P2VaFwCXb
 j72lAG3QoWag7/vu/Y2U+u3RqA3bY40hMnGCgzCWxAPCULVVq8n8v/Q3/mDbS/x+sPmW
 p3Vr56FqY4637v5ZPWFDHmFjSEQ/AGERfnkpiDqH2LyTJOlAcd+EA45GEj2dNVH48Y6f
 xhwTY/Z6yZrkP/k36Id4gb8XoGagki+fgZa86pw6RUuORG3vm8D5imfYY/6mIWFmhTab
 PlCU/SpQs/odfDvt6vnlED87AnkawV72X2l2suhzAqNiqkn7fEhnRTcNueQHnGelWQNq
 qFrg==
X-Gm-Message-State: ACrzQf0hZLWK/9Ae9gfcbTvnZlSYrZIZ2O2E6gjvyY9v8dcD6dZJOEDH
 SsOxI6phsD3CGxxnSprsNdE=
X-Google-Smtp-Source: AMsMyM41gWNRPSPjm2YzVwUl5d4b0XjZzIMLWIyUiNGmCGUZvfn7rGzCc9OVNnY93Sm7LByuEmy8Ig==
X-Received: by 2002:a5d:4351:0:b0:236:c820:97b8 with SMTP id
 u17-20020a5d4351000000b00236c82097b8mr5665053wrr.699.1667258294884; 
 Mon, 31 Oct 2022 16:18:14 -0700 (PDT)
Received: from krug (87-196-74-163.net.novis.pt. [87.196.74.163])
 by smtp.gmail.com with ESMTPSA id
 k5-20020a05600c0b4500b003c6c4639ac6sm8518661wmr.34.2022.10.31.16.18.13
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Oct 2022 16:18:14 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87k04ggixk.fsf@HIDDEN> (Philip Kaludercic's message of "Mon, 
 31 Oct 2022 14:35:19 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN>
Date: Mon, 31 Oct 2022 23:19:24 +0000
Message-ID: <875yfzvawz.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Philip Kaludercic writes: > =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= writes: > What existing
    hooks? 
 
 Content analysis details:   (3.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.221.53 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.221.53 listed in list.dnswl.org]
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Philip Kaludercic writes: > =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= writes: > What existing
    hooks? 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.221.53 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.221.53 listed in list.dnswl.org]
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [87.196.74.163 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (joaotavora[at]gmail.com)
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Philip Kaludercic <philipk@HIDDEN> writes:

> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> What existing hooks?

The major-mode hooks, naturally.

Using major-mode hooks and buffer-local variables is the standard Emacs
way of attaching characteristics to buffers.  The Elisp required is
trivial and there are thousands of examples for doing it out there.
There's no need to introduce new less powerful and more awkward
languages in variables.

>> It's quite clear that _some_ non-file-visiting buffers can be considered
>> as belonging to a project's working set.  But it's very very easy to
>> come up with many that cannot be considered so.
>
> I have to admit that I am more and more inclined to make the list a
> opt-in thing, where  we explicitly mark those major modes that are tied
> to a project.

Yes, and we can always later overhaul project-owned to be function for
doing more complex calculations based on the name of the buffer, for
example.  But a simple boolean would probably suffice for vc buffers,
and other earmuffed buffers created by packages in Emacs.

>> To name one.  The above is just the converse of the solution proposed by
>> Philip before.
>
> I would be fine with this in principle, my only worry is backwards
> compatibility for those who use project.el from ELPA.

We can try to make some backward compatible way, but this seems like the
perfect occasion to activate this most reasonable header in project.el:

    ;; NOTE: The project API is still experimental and can change in major,
    ;; backward-incompatible ways.  Everyone is encouraged to try it, and
    ;; report to us any problems or use cases we hadn't anticipated, by
    ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.

It sure seems like there were things that project.el's authors didn't
anticipate.  A mistake is a mistake there should be no shame in
rectifying it.

In practice, I doubt many people are setting these variables.  A GitHub
code search, where it is normally easy to find customizations of
variables since users version their configurations there, turns up 0
results for customizations of project-ignore-buffer-conditions and not
more than a handful for project-kill-buffer-conditions, for example.  In
contrast you can see hundreds of people setting things like
eglot-autoshutdown or ibuffer-filter-groups (and settings of
scroll-bar-mode are in the thousands).  So I'd say the risk is minimal
and the benefit considerable.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 10:49:02 +0000
Resent-Message-ID: <handler.58839.B58839.166729972814021 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166729972814021
          (code B ref 58839); Tue, 01 Nov 2022 10:49:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:48:48 +0000
Received: from localhost ([127.0.0.1]:42830 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opop6-0003e5-69
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:48:48 -0400
Received: from mout02.posteo.de ([185.67.36.66]:56209)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opop4-0003dn-5T
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:48:46 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 9F87D240108
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 11:48:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667299720; bh=C2l4nFq11iu9wU5lcwQLKk2+PLCKj2RaNHvGdbebmtU=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=nO37SwuqqzsK61uk1C0g1y8TSoeQ2Y/AuwXvE1qxk8mN9rggvlKzfirpX48hQcTte
 gl308k3kVcGv0LZqbQkSckbeb89uDEArU5MXy+2TTyIAcAo1pQyAIWzXkPeY4++QKQ
 pzJgrTELKFlj2x0bZdQpXpn2C1gtMu7o/znvE7ikRAeAsBXN4cmyZ3Q+EV0z82WX8h
 08jSTTftJmNh9SHp2eGk3Ez57T2d+4Z47Lvb+YfqhI1EsCarzvc7LptFCb1KZR1rwZ
 u5sPl+AMgE3LS3D+Qct4VuK0tIDDNw1+Y7YYj04ZazlOIW1+zeQAEYLhgmk8qwykT6
 eGL3A8fw917/g==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1mw45nX4z9rxV;
 Tue,  1 Nov 2022 11:48:36 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Nov 2022 00:51:53 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 10:48:36 +0000
Message-ID: <87tu3jgdbv.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

>>>> The mini-languages invented in project-kill-buffers-conditions and
>>>> project-ignore-buffer-conditions are abominations.
>>> This is the point where I'd normally blacklist you again.
>> I had no idea who authored those variables.  If you are among the
>> authors, I'm very sorry, I was referring merely to code.  I said before
>> I'm quite happy with project.el, but this (small) part of it is very
>> badly done.
>
> I'm not the only author. Regardless, it's not a good language to use
> no matter who wrote it.

I believe that was me...

BTW, if there are major objections to the language, I should point out
that the new `buffer-match-p' in Emacs 29 uses the same language and has
already found usage in a number of spots in core Emacs.  There would
still be time to address any issues you might have, and avoid a
long-term mistake.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 10:53:02 +0000
Resent-Message-ID: <handler.58839.B58839.166729992214429 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166729992214429
          (code B ref 58839); Tue, 01 Nov 2022 10:53:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:52:02 +0000
Received: from localhost ([127.0.0.1]:42834 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oposD-0003kS-Pz
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:52:02 -0400
Received: from mout02.posteo.de ([185.67.36.66]:42379)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oposB-0003kD-Ua
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:52:00 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 6974D240101
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 11:51:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667299914; bh=9W3kVx4UOPrL/fc5FYsR1UnBHRmZAEbt1vGqOqT6AJw=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=dJtPvcqxYkBEG50a/TNBp0zr18t9lYxjg0Y4K1VeuI+8pF2YnRhVyh3eC6NO6sgFg
 pSdEogL1rxJp/XfhZikwBPyQDDOgrnpVCKoCx4U593EZr7YKR4n6OjRaZHHNx9lWdh
 GwzXrcXp750R8RYMvToYBqfhNrOps/Aiz72907dx7UyQb3Ry/nCDaTUZaIG7aNJZxq
 KH1+Ql2PkHnlxq9KG7ocPMfc1YB0SomBSIYpEVq5KJ92e5Yqvp0wSJ1GgeDVD+liXF
 +UjYXVNHJg1FriugOfqI/oqO9N8BB25lodzLQVVw0kAr5g4Jq2tp6TgXSQi+Rb8jfn
 C48F9ENaCFv5Q==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1mzs5R4rz9rxF;
 Tue,  1 Nov 2022 11:51:53 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <875yfzvawz.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 31 Oct 2022 23:19:24 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <87k04ggixk.fsf@HIDDEN>
 <875yfzvawz.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 10:51:53 +0000
Message-ID: <87pme7gd6e.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> In practice, I doubt many people are setting these variables.  A GitHub
> code search, where it is normally easy to find customizations of
> variables since users version their configurations there, turns up 0
> results for customizations of project-ignore-buffer-conditions and not
> more than a handful for project-kill-buffer-conditions, for example.  In
> contrast you can see hundreds of people setting things like
> eglot-autoshutdown or ibuffer-filter-groups (and settings of
> scroll-bar-mode are in the thousands).  So I'd say the risk is minimal
> and the benefit considerable.

If people are customising the variable everything is fine, the issue I
was thinking about were those who are relying on the default behaviour
that might change without them expecting it to.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 10:59:01 +0000
Resent-Message-ID: <handler.58839.B58839.166730033015168 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730033015168
          (code B ref 58839); Tue, 01 Nov 2022 10:59:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 10:58:50 +0000
Received: from localhost ([127.0.0.1]:42843 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opoyo-0003wZ-1r
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:58:50 -0400
Received: from mail-ot1-f52.google.com ([209.85.210.52]:44863)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opoym-0003wL-Cv
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 06:58:48 -0400
Received: by mail-ot1-f52.google.com with SMTP id
 p8-20020a056830130800b0066bb73cf3bcso8253466otq.11
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 03:58:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=Jqw/+wWtuUFY0a7+SPLJy5pwOWdg+HbRhUJaqXs86sk=;
 b=D/c62oRULiQ40SHUYHKMDzziFNQkGRmJumtN0f4DmYePGxOS5EbdgZgPl3iFCvx1Wt
 ScXyAfgHybMNdHwtXUFccvS7NOJt/UwtCz3Ekc0BPvxjiRFiB0hmSLOruYkFUATnKHFU
 q5uMxgSN+O3kBqthrVIbpiWTBGpJBmXZDc90MWftJTrrQv1Dnh2+lyTdCAqlnnGaWXVq
 61X92E8NW+ifKDioXz5WLsFhrYwoyccT0KlMx8mADQOA1WcIckGGPRTSxCD3ZOxfb6tS
 3xcUMg11HtC0HGLYiTLZGhQ2YEA1FxnHPZyTLAJXbt4+Z0PIHSfPhlOAujn7amWCZeVM
 s1WQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=Jqw/+wWtuUFY0a7+SPLJy5pwOWdg+HbRhUJaqXs86sk=;
 b=N+8QKRmLPDOKigaVaRCzu/d8UWMJF29I0rIDE2thB31qKGGYysbRjn/k2bPYfYMr9k
 emzmXJ5uUjFTIHEVw0xEFMEDa2qasUIfMEp+6d+DptUkm7mpyYScBd8mFZ9sCQn+FtS/
 KE3pA7nLKdRCiSQCRRx/dC49c6p08Kruiqafr4gfwgVFbcuIUg8oyn8Z5JTCneWDcEKl
 NyodaMUEtEPaeitYht7GmslicLkp0pEHM5UkEYR8Ifsqchvo3m28xvDkdEAivonZMlvd
 jn80r0pqAYMd3in0jPP61Q6AWeAAsN05angFTT/5dPP3QU69ufKKi5QLAd93Y2PTVWOA
 foDA==
X-Gm-Message-State: ACrzQf3eFxnv/WFQ8/Yag625L+QAfqXmqboQrCUWaULg2F58uwOiD845
 RJwwhndi2gSSF1MFzpe+m7FhyqqEUAwNctlhkpM=
X-Google-Smtp-Source: AMsMyM7XUrlegFYeeAlyZVYSXH/m65c5G9vCKDI8KpTqLgd9RjBeS06xxcONHKxPtJCyB7j5LegxjCNDSyhitiQ03OQ=
X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id
 23-20020a9d0117000000b00666e09d577emr9366168otu.93.1667300322666; Tue, 01 Nov
 2022 03:58:42 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
In-Reply-To: <87tu3jgdbv.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 10:59:41 +0000
Message-ID: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000776cca05ec669ba7"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000776cca05ec669ba7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk@HIDDEN>
wrote:

>
> BTW, if there are major objections to the language, I should point out
> that the new `buffer-match-p' in Emacs 29 uses the same language and has
> already found usage in a number of spots in core Emacs.  There would
> still be time to address any issues you might have, and avoid a
> long-term mistake.
>

For me, it looks like match-buffers is reinventing
cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
function of a buffer?

I'm not fond of these mini-languages because they're less expressive, they
end up being only minimally less complicated and bug-prone, they can't
automatically be byte-compiled for efficiency, and they can't automatically
be byte-compiled for correctness/diagnostics.  If one makes a mistake,
the backtrace is much more complicated.

So these mini-languages may make sense to define filters in thunderbird or
something, but throwing Elisp away here generally doesn't make sense to me.

But there may be exceptions (although this project.el one doesn't seem one
of them) so why don't you show examples of use of these new helpers and
so we can compare side by side with the Elisp-only alternative.

Jo=C3=A3o

--000000000000776cca05ec669ba7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic &lt;<a href=3D"mai=
lto:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex"><br>
BTW, if there are major objections to the language, I should point out<br>
that the new `buffer-match-p&#39; in Emacs 29 uses the same language and ha=
s<br>
already found usage in a number of spots in core Emacs.=C2=A0 There would<b=
r>
still be time to address any issues you might have, and avoid a<br>
long-term mistake.<br>
</blockquote></div><div><br></div><div>For me, it looks like match-buffers =
is reinventing<br></div><div>cl-remove-if-not and match-buffer-p is reinven=
ting ... unary predicate <br></div><div>function of a buffer?<br></div><div=
><br></div><div>I&#39;m not fond of these mini-languages because they&#39;r=
e less expressive, they</div><div>end up being only minimally less complica=
ted and bug-prone, they can&#39;t</div><div>automatically be byte-compiled =
for efficiency, and they can&#39;t automatically</div><div>be byte-compiled=
 for correctness/diagnostics.=C2=A0 If one makes a mistake, <br></div><div>=
the backtrace is much more complicated.</div><div><br></div><div>So these m=
ini-languages may make sense to define filters in thunderbird or</div><div>=
something, but throwing Elisp away here generally doesn&#39;t make sense to=
 me.</div><div><br></div><div>But there may be exceptions (although this pr=
oject.el one doesn&#39;t seem one <br></div><div>of them) so why don&#39;t =
you show examples of use of these new helpers and <br></div><div>so we can =
compare side by side with the Elisp-only alternative.</div><div><br></div><=
div>Jo=C3=A3o<br></div></div>

--000000000000776cca05ec669ba7--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 11:24:01 +0000
Resent-Message-ID: <handler.58839.B58839.166730182617970 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730182617970
          (code B ref 58839); Tue, 01 Nov 2022 11:24:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:23:46 +0000
Received: from localhost ([127.0.0.1]:42857 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oppMv-0004fm-MC
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:23:45 -0400
Received: from mail-wm1-f42.google.com ([209.85.128.42]:37623)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1oppMt-0004fW-TZ
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:23:44 -0400
Received: by mail-wm1-f42.google.com with SMTP id
 ay14-20020a05600c1e0e00b003cf6ab34b61so3212047wmb.2
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:23:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=lG60s7Pd9RolxnP2DFBavjgUhldYVcDGqzI6EPhi0bQ=;
 b=bzRrRQWiK1E+Cyodaf+Ul1v6tDlTkTzp7eSxMMEqT6cntF/qxLPPPZxXzTwq5YNdiQ
 bp8WK3fwGT8yJjNdb0tGlBeUAQsL09cQYoZiifhf9p+g1J510Y/1AO1s2MI5rK6oKgH5
 cMZaYQnnky5lpKhS4gBlgFGG1RV+aLJXour+VFqnBqvgseI8AeIeFfxHuks/HKMDTBOn
 ZjbL1h4s4YhG4l97FAkStIPGTZ1Q7ZSldk30TcG0T5O8AYkqKgqywBwOOCdAkCKAKMqV
 rBkVdGB6rYlm/2g/ZgYNzvhGwD4ZfNs6z1EL46i0kPQk9Y4U4F0jR0vQR4z0GKlch5mn
 H+jA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=lG60s7Pd9RolxnP2DFBavjgUhldYVcDGqzI6EPhi0bQ=;
 b=IlAkwg7W6xL1XVVdYYdxIwdZ6pz7H6ezV7fbe+WktI91JH3VVMeHDCBTAjJvdvKMvb
 bYbXLqqnkyrYCBdpV2GTs3xyiOyaUzLhNipKFB+dtZ9nWoM1xpZjAeiXdDc8DM+fXlSZ
 wj5+sLzjyOAM6yyTsnskFKlelIibiN7qtvrpw0Fw0bn1fLApIlhISx+lQ563abUOSWXW
 Yy3Au3mpfseH5cjoiyPhwF8NtZw/mZTonPEXLS5eyuytJp4rcvtrJ7vpnb1fwn8e8Nj2
 gHPaLj8MLxLH42RFN9eJXoJtjR+8WW+A4kXGFkaoKV5F2Tgqzzse+pCWdoRnIfMbj7ZZ
 uQxw==
X-Gm-Message-State: ACrzQf3Cdu4jiN6inghBjG8uqFQkRmVNDatboBC8vDY3dr+U2SUDqnyU
 u2Vdve12jbX1QoRi8/xpy7Y=
X-Google-Smtp-Source: AMsMyM7WKNeJn0GYlUgyRDiY3eNuLvTvJ7t/1b+MxTzb6yVL9kASoSR3D/jIsffWRhWEj/94IOVI3g==
X-Received: by 2002:a05:600c:2314:b0:3cf:6b2a:7d93 with SMTP id
 20-20020a05600c231400b003cf6b2a7d93mr8491991wmo.33.1667301817855; 
 Tue, 01 Nov 2022 04:23:37 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 m23-20020a05600c3b1700b003b4ff30e566sm1474348wms.3.2022.11.01.04.23.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 04:23:37 -0700 (PDT)
Message-ID: <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
Date: Tue, 1 Nov 2022 13:23:35 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 12:59, João Távora wrote:
> For me, it looks like match-buffers is reinventing
> cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
> function of a buffer?

And Eglot is reinventing url-http.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 11:28:02 +0000
Resent-Message-ID: <handler.58839.B58839.166730205218401 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730205218401
          (code B ref 58839); Tue, 01 Nov 2022 11:28:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:27:32 +0000
Received: from localhost ([127.0.0.1]:42862 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oppQa-0004mg-8e
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:27:32 -0400
Received: from mout01.posteo.de ([185.67.36.65]:42545)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oppQY-0004mP-8O
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:27:31 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 7F33B240026
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 12:27:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667302044; bh=HL9xnZhzIT055WSzsrYrsZTjAKiUULttndU5fbMF5Rs=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=qlU61K/fextzQMqdFnoZzIOhfGe4ZbCEEAXq5Z5hiEKftn3TTCeADoT7T+R1GwavW
 S9+flxUE1aWLph3QPfJ+tj4BCdHP0Pl35+Phj3aikQKLGnbZdneVBH9a/0yq1WdpjO
 EmdLdX5Fw9G4HIxKrjwQXjHj9fD1fMsJu29o5Ic+aWintVRILlYxpIkm6l9pqO5Jt2
 cAXlSoZn70mD8dtoXFiO0hxc/3zp/rE8WJ/g2cf2uQkvXYf4uSnr11ZqWLdaoojZQV
 3OqZkRoCLVspw+UVk1rMbmSqDoxNqVmyfpAuG5NUY5cE/qVJ6lSxmB61BVjGCztt9Q
 jazZv9c3jPlNQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1nmp1w35z6tpn;
 Tue,  1 Nov 2022 12:27:22 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 1 Nov 2022
 10:59:41 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 11:27:21 +0000
Message-ID: <87h6zihq3q.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> On Tue, Nov 1, 2022 at 10:48 AM Philip Kaludercic <philipk@HIDDEN>
> wrote:
>
>>
>> BTW, if there are major objections to the language, I should point out
>> that the new `buffer-match-p' in Emacs 29 uses the same language and has
>> already found usage in a number of spots in core Emacs.  There would
>> still be time to address any issues you might have, and avoid a
>> long-term mistake.
>>
>
> For me, it looks like match-buffers is reinventing
> cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
> function of a buffer?

You could say that, though I would argue it is an easier way to express
common predicates, while not making anything else more complicated.

E.g. `display-buffer-alist' makes use of it to associate display-buffer
rules with buffers.  Now you can add

      ((major-mode . help-mode) display-buffer-in-side-window)

instead of trying to match being a regular expression to catch all
*Help* buffer names of a function along the lines of

      (lambda (buf _alist)
        (with-current-buffer buf
          (derived-mode-p 'help-mode)))

> I'm not fond of these mini-languages because they're less expressive, they
> end up being only minimally less complicated and bug-prone, they can't
> automatically be byte-compiled for efficiency, and they can't automatical=
ly
> be byte-compiled for correctness/diagnostics.  If one makes a mistake,
> the backtrace is much more complicated.

I agree in principle, but this should be alleviated by using a lambda
function as a predicate.  The above check still works and can be used
anywhere you would use `buffer-match-p'.

> So these mini-languages may make sense to define filters in thunderbird or
> something, but throwing Elisp away here generally doesn't make sense to m=
e.
>
> But there may be exceptions (although this project.el one doesn't seem one
> of them) so why don't you show examples of use of these new helpers and
> so we can compare side by side with the Elisp-only alternative.

I am biased, but I believe that the language could even find more use in
project.el, by having `project-buffers' just call `match-buffers' with a
special `buffer-match-p' predicate.  Here is a sketch of how that could
look like (I haven't tested it yet):


--=-=-=
Content-Type: text/plain
Content-Disposition: inline

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index ac278edd40..b55c245368 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -352,15 +352,28 @@ project--remote-file-names
                 (concat remote-id file))
               local-files))))
 
+(defun project-includes-buffer-p (buffer dir)
+  "Return non-nil if the `default-directory' of BUFFER is below DIR."
+  (file-in-directory-p
+   (buffer-local-value 'default-directory buffer)
+   dir))
+
+(defcustom project-buffer-conditions
+  '(and (or buffer-file-name
+            (derived-mode . compilation-mode)
+            (derived-mode . dired-mode)
+            (derived-mode . diff-mode)
+            (derived-mode . comint-mode)
+            (derived-mode . eshell-mode)
+            (derived-mode . change-log-mode))
+        project-includes-buffer-p)
+  "A buffer predicate for matching what buffers belong to a project."
+  :type 'buffer-predicate)
+
 (cl-defgeneric project-buffers (project)
   "Return the list of all live buffers that belong to PROJECT."
-  (let ((root (expand-file-name (file-name-as-directory (project-root project))))
-        bufs)
-    (dolist (buf (buffer-list))
-      (when (string-prefix-p root (expand-file-name
-                                   (buffer-local-value 'default-directory buf)))
-        (push buf bufs)))
-    (nreverse bufs)))
+  (let ((root (expand-file-name (file-name-as-directory (project-root project)))))
+    (match-buffers project-buffer-conditions nil root)))
 
 (defgroup project-vc nil
   "Project implementation based on the VC package."
@@ -679,7 +692,7 @@ project-buffers
                      (project--git-submodules))))
          dd
          bufs)
-    (dolist (buf (buffer-list))
+    (dolist (buf (cl-call-next-method))
       (setq dd (expand-file-name (buffer-local-value 'default-directory buf)))
       (when (and (string-prefix-p root dd)
                  (not (cl-find-if (lambda (module) (string-prefix-p module dd))

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

DQo+IEpvw6NvDQo=
--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 11:36:02 +0000
Resent-Message-ID: <handler.58839.B58839.166730251227747 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730251227747
          (code B ref 58839); Tue, 01 Nov 2022 11:36:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:35:12 +0000
Received: from localhost ([127.0.0.1]:42866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oppXz-0007DT-Ar
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:35:11 -0400
Received: from mail-oa1-f51.google.com ([209.85.160.51]:39620)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oppXx-0007D8-3R
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:35:10 -0400
Received: by mail-oa1-f51.google.com with SMTP id
 586e51a60fabf-13c569e5ff5so16063927fac.6
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:35:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=ySz54CLs/75+7kqT7Vdy0f4+HMq5N3vdhin5y98k0sw=;
 b=aBaZWynci95xK6wzq/dsn0sBTtOHfsfR8+ByFrHS0M9W/MKHPdMHftyct5f3BGKTqM
 dd4InUo4TtOw3NmF6HyLoagw7XDw2NgKYXfV3eN09briJz+wFAeyJMsi5/KglOA88V9I
 AdPHeEHIMF5I2DDvyVoZ6QnFyx6e3h5cUx2UlDm1qfMALlnwPP6u0Ms/ZjHT420v5sQs
 r32o2OwOyJs3GuhzNNyFBBE/iIpKKxFgKLIynn3Vu+qaanIyzm1BsnAZdX6v0KgCmf1E
 2ek3wXtWx/xBCZeK14Ek9BkZ53FS/L+csP4jfmAOzioexGQqQF9V1XVkI8gOlmcyp072
 /+SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=ySz54CLs/75+7kqT7Vdy0f4+HMq5N3vdhin5y98k0sw=;
 b=WzExmbK9SAxnoOhsCmAIgvVjseDh9A/ANEU7ZKKTlfYkviiP+b6cO2giPDLhfB5A1t
 ZH+wBLgOLYzKeNp8hvAUqQItd6/aF4z8lhwHK/0VGCsm09CVglghDNpMzEKW50sBRhJH
 x9B7v2giPnspPV9h6ASushx+hlcXGxKoCyt8M16PNPZwe+0GEA7Nwhqfm4oVcCLAtoqt
 BuYp8uMbQMQ0q8G2oeuQRrJXdVLNnB0t16q9iqIQFmfWIQbB0iJ8W5KVfmXKf2RsCVK8
 HOdIlyG8jtOOlYPLIO8TUczz++kuUUPXWphwyw1kp8Q4itlHRF90g519cLdiil0ykpfe
 lgng==
X-Gm-Message-State: ACrzQf2hsQTLDW0QY5dmAklpYO6ZcQYgGhhQd+wFQ/pUqaUYxmeaykCn
 Uzgn0sx9gav17+g/GOcBxpN0MRVPjN5LKXFinR0=
X-Google-Smtp-Source: AMsMyM7uL4L0WNBNya/dP+QD/PJDfAcZVaU570ONXmfKqEgCZgEGlg2APwbAr8LGW3bO++6hQbBD/4Yo90eQSy/4YDU=
X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id
 d2-20020a056870e24200b0013bd561ad02mr10936686oac.215.1667302503461; Tue, 01
 Nov 2022 04:35:03 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
In-Reply-To: <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 11:36:02 +0000
Message-ID: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000073b88c05ec671d8e"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000073b88c05ec671d8e
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <dgutov@HIDDEN> wrote:

> I suggest you try it first.

It works in my test

> Disaster, really?

The reason I came about the Gnus problem was when using it
to reply to some emails here and trying out the C-x p k and finding out
all my Gnus buffers were gone.

> Do you know whether CIDER will be satisfied by the same patch I sent
> previously?

No.  I don't use it. You should ask Manuel, who reported this in
the original discussion.

> >>> you're making a gun that only backfires 5% of the time.
> >> Yours is the first instance so far.
> > We seem to use different algebraic systems.
> This is literally the first bug report on the subject.

It's Philip's bug report.  I don't use C-x p k, in fact I learned about it
here.  It's then I started trying it, because in principle it is very
useful,
that I found out how broken it is for many other situations: ibuffer,
*gnus*,
and it's a shame we can't use it.

> what you are doing is pressuring all other participants into your POV by
> means of an insult. That usually works better if the offending code was
> written by somebody who already left (the project/the discussion/the
> company/etc), or is a little younger.

You are attributing ill-intent to me from a moral high-ground you can't
really
claim.  I had no idea as to the authorship, so I can't have been engaging
in those
perfidious tactics.  But do I apologize for the word "abomination". If it
helps
I'll show you round to plenty such things written by myself in the past.

I've explained to Philip objective reasons why I think evaluated
mini-languages are almost always inferior to a decent Lisp such as Elisp.
You could perfectly reasonably deprecate these two variables.

> They can, though, even if odds are low. It can also happen through some
> other automation, which Emacs lets the users do freely.

That automation is just as buggy as C-x p k, and should be fixed, but
the only such automation we know is C-x p k.

> I'm fairly sure that the solution I offered would be easy enough
> implement, to actually protect the vulnerable buffer.
> I suppose we are not doing that, however.

You sketched an untested code-less idea and I explained how flawed it was.
Not to mention it's just [insert acceptably derogatory word here] to protect
implementation details from misbehaving code that is under our control
and can just be fixed.

--00000000000073b88c05ec671d8e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov &lt;<a href=
=3D"mailto:dgutov@HIDDEN">dgutov@HIDDEN</a>&gt; wrote:<br><br>&gt; I =
suggest you try it first.<br><br>It works in my test<br><br>&gt; Disaster, =
really?<br><br>The reason I came about the Gnus problem was when using it<b=
r><div>to reply to some emails here and trying out the C-x p k and finding =
out <br></div><div>all my Gnus buffers were gone.=C2=A0 <br></div><div><br>=
</div>&gt; Do you know whether CIDER will be satisfied by the same patch I =
sent<br>&gt; previously?<br><br><div>No.=C2=A0 I don&#39;t use it. You shou=
ld ask Manuel, who reported this in <br></div><div>the original discussion.=
<br></div>=C2=A0<br>&gt; &gt;&gt;&gt; you&#39;re making a gun that only bac=
kfires 5% of the time.<br>&gt; &gt;&gt; Yours is the first instance so far.=
<br>&gt; &gt; We seem to use different algebraic systems.<br>&gt; This is l=
iterally the first bug report on the subject.<br><div><br></div><div></div>=
It&#39;s Philip&#39;s bug report.=C2=A0 I don&#39;t use C-x p k, in fact I =
learned about it<br>here.=C2=A0 It&#39;s then I started trying it, because =
in principle it is very useful,<br><div>that I found out how broken it is f=
or many other situations: ibuffer, *gnus*, <br></div><div>and it&#39;s a sh=
ame we can&#39;t use it.</div>=C2=A0<br>&gt; what you are doing is pressuri=
ng all other participants into your POV by<br>&gt; means of an insult. That=
 usually works better if the offending code was<br>&gt; written by somebody=
 who already left (the project/the discussion/the<br>&gt; company/etc), or =
is a little younger.<br><br><div>You are attributing ill-intent to me from =
a moral high-ground you can&#39;t really <br></div><div>claim.=C2=A0 I had =
no idea as to the authorship, so I can&#39;t have been engaging in those <b=
r></div><div>perfidious tactics.=C2=A0 But do I apologize for the word &quo=
t;abomination&quot;. If it helps</div><div>I&#39;ll show you round to plent=
y such things written by myself in the past.<br></div><div><br></div><div>I=
&#39;ve explained to Philip objective reasons why I think evaluated</div><d=
iv>mini-languages are almost always inferior to a decent Lisp such as Elisp=
.</div><div>You could perfectly reasonably deprecate these two variables.<b=
r></div><br>&gt; They can, though, even if odds are low. It can also happen=
 through some<br>&gt; other automation, which Emacs lets the users do freel=
y.<br><br>That automation is just as buggy as C-x p k, and should be fixed,=
 but<br>the only such automation we know is C-x p k.<br><br>&gt; I&#39;m fa=
irly sure that the solution I offered would be easy enough <br>&gt; impleme=
nt, to actually protect the vulnerable buffer.<br>&gt; I suppose we are not=
 doing that, however.<br><br><div>You sketched an untested code-less idea a=
nd I explained how flawed it was. <br></div><div>Not to mention it&#39;s ju=
st [insert acceptably derogatory word here] to protect</div><div>implementa=
tion details from misbehaving code that is under our control <br></div><div=
>and can just be fixed.<br></div></div>

--00000000000073b88c05ec671d8e--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 11:39:02 +0000
Resent-Message-ID: <handler.58839.B58839.166730271028105 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730271028105
          (code B ref 58839); Tue, 01 Nov 2022 11:39:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:38:30 +0000
Received: from localhost ([127.0.0.1]:42870 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oppbC-0007JF-6I
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:38:30 -0400
Received: from mail-ot1-f43.google.com ([209.85.210.43]:43732)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oppbA-0007Iw-6Y
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:38:28 -0400
Received: by mail-ot1-f43.google.com with SMTP id
 k59-20020a9d19c1000000b0066c45cdfca5so3889329otk.10
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=jOLjSHgH0pH7J8bvpsykwETDk/uvXbPgL6h5D0rdFgo=;
 b=e78S+biNk/o7TcrUGUT8Mouc/jwttHgiqtBjpjYRrnxSJNB00V0lL18+Zfm+k/jppq
 HU9sy6U+SAkxJRqbPHS6Hxch4wQagj5R0E2hplCX1nQEXnIDw/PTSL5c7hS+TiU8DTHM
 yGyU4S073l/lfkKngnGlrfqiMLmWVPCQuM/na3i8g4zp/4WRRLdXk/mTcUm7YGQQe7zi
 9DZo0pt8uvuXyRD9ZaN5cMJu+R2/RppZd44vsGr6tzAz/jJHA409w3UmgiKSmEYlFP/u
 b9qoihZYAcjdB04rEz2z0ictg1EJwQySi6VOrxh4czhvEOKtpPYA0X/MUa5QekJNqmjf
 ba+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=jOLjSHgH0pH7J8bvpsykwETDk/uvXbPgL6h5D0rdFgo=;
 b=hK71gfvGuUYrmewe3f+c9FczNa7upB1wtx4wbrmkvkM77YhVvO5ueQiPGss+/1/CN5
 1aSYJ/FAFsNNccG6RzccPBWzVvkjl4KtBtvFErWLhMLjVV93I0UvWVU6FxVLzWgZ1VbB
 +i+DXyBrE0H8dMCeScQOOwpF9Gk2VB9Pq3U0ewRemuoU66aI3CnEt+TfvmeMqIita/hj
 rLIcXDSvas/Q8cuELs91kA2oDoi07yVrAjGuCPKYEVt+Rqr6g1dFzKOxTXX4q1F7PGx/
 gM0RMKDPvSEf/WhKHqC1dKSBCh4MCHSHX24Y1JY30fgOKu2XXhDF2htSBRTDx4YJK4Jp
 CT8g==
X-Gm-Message-State: ACrzQf11NPWwKdRjqFkobs82X3+xKhripl22ytIbl7K/tZooSYofTrx2
 d6u2geM3fN8dgqTLPond9JzwCH8I84qjCnrgB8Q=
X-Google-Smtp-Source: AMsMyM7n2DeUAfBHaHjXxtSCAU28NQ9rJSD2H4h3Fbk4KvwgFnBJitnbjh7WS26bMm/3c0TXSDRFjQJ36rmIAXJ69L0=
X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id
 23-20020a9d0117000000b00666e09d577emr9457953otu.93.1667302701625; Tue, 01 Nov
 2022 04:38:21 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
In-Reply-To: <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 11:39:20 +0000
Message-ID: <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000004374ad05ec67296c"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000004374ad05ec67296c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov <dgutov@HIDDEN> wrote:

> On 01.11.2022 12:59, Jo=C3=A3o T=C3=A1vora wrote:
> > For me, it looks like match-buffers is reinventing
> > cl-remove-if-not and match-buffer-p is reinventing ... unary predicate
> > function of a buffer?
>
> And Eglot is reinventing url-http.
>

Really? Where? I don't understand how, might it might very well be.
Can suggest an improvement? I love to kill code, so let 'er rip.

Jo=C3=A3o

--0000000000004374ad05ec67296c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov &lt;<a href=3D"mailto:d=
gutov@HIDDEN">dgutov@HIDDEN</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On 01.11.2022 12:59, Jo=C3=A3o T=C3=A1vora=
 wrote:<br>
&gt; For me, it looks like match-buffers is reinventing<br>
&gt; cl-remove-if-not and match-buffer-p is reinventing ... unary predicate=
<br>
&gt; function of a buffer?<br>
<br>
And Eglot is reinventing url-http.<br></blockquote><div><br></div><div>Real=
ly? Where? I don&#39;t understand how, might it might very well be.<br></di=
v><div>Can suggest an improvement? I love to kill code, so let &#39;er rip.=
</div><div><br></div><div>Jo=C3=A3o</div></div></div>

--0000000000004374ad05ec67296c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 11:59:02 +0000
Resent-Message-ID: <handler.58839.B58839.166730390331345 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166730390331345
          (code B ref 58839); Tue, 01 Nov 2022 11:59:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 11:58:23 +0000
Received: from localhost ([127.0.0.1]:42888 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oppuQ-00089V-Cm
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:58:22 -0400
Received: from mail-ot1-f53.google.com ([209.85.210.53]:45053)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oppuO-000896-Il
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 07:58:21 -0400
Received: by mail-ot1-f53.google.com with SMTP id
 p8-20020a056830130800b0066bb73cf3bcso8327341otq.11
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 04:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=JRk/8o4v6jXBCV4rY0cjToIEEdI6z+4sOOCgqpImxRc=;
 b=RlMLFWS+9mFBgiK7zC+Lifko9Hny7004Daw/cv4ZaAyRTn3dPPJ7rFKu0Co95nd0/S
 eESxWpirXHlXqK2ADydFCTeeAN+VzgoAML94vS+46LbeAOrRtY5+ZJTmxzr5kbuKJWxA
 QFf4V2OMBc4nfxqm63lVGNCgK6VB8zV6yV2tz5K/HIbpDWqwLF21imxWqzv+2Zqjp48L
 0HWpsneFzJJFJDeTACYoq4VeK2SGobHWQRXpEL28XU2kvKLtVfzH+orVOlXZ07AhGWx8
 YqsbwbD2CcQ4t670vkC2CaiQb2rwEN/4Rsl15/YZa+iz/L94sc2nwrIfrQ2IvJyZQc2w
 w41Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=JRk/8o4v6jXBCV4rY0cjToIEEdI6z+4sOOCgqpImxRc=;
 b=foC9r3Ou58EHJi+0Lemcyu+UKUJHDITULrlPxco6ROk7eFq/tvM09Rx6UT12M4aNz0
 NQGsiRxhlUr+kvwZ10ZYz2O+or+m+PvxfztH9Y5e+18ohF8iANIXMFM5ihzqkEIkf/T/
 +CXHkTGf07W44j7RDPUBxZ11wGS7KdVVy4hMjbzCx5zj5f+3Fxr/7WKRIvnCYGgppSRV
 WMOE8SmquirPebe8k5spdY4O4a9FZldUheVok/pCYC2x9ZijRA5CnqcAJXaFlA7/sMhb
 drvf1a5V7EmpBsxHrFEsQzKi7VLuqx2mG3VSYL3z////ovFjBi39FA1V69fzWjipytF0
 DHIg==
X-Gm-Message-State: ACrzQf2LU2bCgfCXaLTlEUXORo6OrWA61XFSgE+xmgS6UVEDQNia1BUa
 kE+XWZPVD9C8qklkGylvyhRSpmj2vbu2XXuwf/8=
X-Google-Smtp-Source: AMsMyM5uNPF8NhlpJ+DaKOYYtPuErdoNoVl8y4yNUWaTkgPtZzLSqrP2fc99B2hqybGz+tUy4VNRzua+KqU+xKeKefc=
X-Received: by 2002:a9d:117:0:b0:666:e09d:577e with SMTP id
 23-20020a9d0117000000b00666e09d577emr9504395otu.93.1667303894793; Tue, 01 Nov
 2022 04:58:14 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
In-Reply-To: <87h6zihq3q.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 11:59:12 +0000
Message-ID: <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000061c0f005ec677090"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--00000000000061c0f005ec677090
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN>
wrote:


> E.g. `display-buffer-alist' makes use of it to associate display-buffer
> rules with buffers.  Now you can add
>
>       ((major-mode . help-mode) display-buffer-in-side-window)
>
> instead of trying to match being a regular expression to catch all
> *Help* buffer names of a function along the lines of
>
>       (lambda (buf _alist)
>         (with-current-buffer buf
>           (derived-mode-p 'help-mode)))
>

If you really want to save up on this typing, it's better to define
a reusable helper function, or even a higher order function.

  (defun buffer-mode-matcher (mode)
    (lambda (b _alist)
      (with-current-buffer b (derived-mode-p 'help-mode))))

You can add buffer-mode-matcher to the library if it becomes
useful enough.  Then you add:

  `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)

to display-buffer-alist.

But if you really want a new language your language, then I suggest
a simple adapter buffer-matcher utility that merges the two.  That way one
doesn't couple existing utilities to the new mini-language and
simultaneously
the new mini-language become useful in a much wider setting for those who
appreciate such things.

  (defun buffer-matcher (condition)
     "Return unary predicate of a buffer matching the CONDITION
mini-language."
    (lambda (buf &rest _whatever) ; make it even more lax
       (buffer-match-p condition)))

Later on, you might even pass an (... &optional compiled) so that the
return value
is syntax checked and optimized in some way at compile time.

IOW, (E)Lisp already gives you the tools for these composition without
needing to invent new languages with the drawbacks I listed.

--00000000000061c0f005ec677090
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic &lt;<a href=3D"mai=
lto:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
E.g. `display-buffer-alist&#39; makes use of it to associate display-buffer=
<br>
rules with buffers.=C2=A0 Now you can add<br>
<br>
=C2=A0 =C2=A0 =C2=A0 ((major-mode . help-mode) display-buffer-in-side-windo=
w)<br>
<br>
instead of trying to match being a regular expression to catch all<br>
*Help* buffer names of a function along the lines of<br>
<br>
=C2=A0 =C2=A0 =C2=A0 (lambda (buf _alist)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (with-current-buffer buf<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode-p &#39;help-mode)))<br></b=
lockquote><div><br></div><div>If you really want to save up on this typing,=
 it&#39;s better to define</div><div>a reusable helper function, or even a =
higher order function.</div><div><br></div><div>=C2=A0 (defun buffer-mode-m=
atcher (mode)</div><div>=C2=A0 =C2=A0 (lambda (b _alist) <br></div><div>
=C2=A0 =C2=A0=C2=A0=C2=A0 (with-current-buffer b (derived-mode-p &#39;help-=
mode))))</div><div><br></div><div>You can add buffer-mode-matcher to the li=
brary if it becomes <br></div><div>useful enough.=C2=A0 Then you add:</div>=
<div><br></div><div>=C2=A0 `(,(buffer-mode-matcher &#39;help-mode) display-=
buffer-in-side-window)</div><div><br></div><div>to display-buffer-alist.</d=
iv><div><br></div><div>But if you really want a new language your language,=
 then I suggest</div><div>a simple adapter buffer-matcher utility that merg=
es the two.=C2=A0 That way one</div><div>doesn&#39;t couple existing utilit=
ies to the new mini-language and simultaneously</div><div>the new mini-lang=
uage become useful in a much wider setting for those who</div><div>apprecia=
te such things.</div><div><br></div><div>=C2=A0 (defun buffer-matcher (cond=
ition)</div><div>=C2=A0=C2=A0=C2=A0=C2=A0 &quot;Return unary predicate of a=
 buffer matching the CONDITION mini-language.&quot;</div><div>=C2=A0=C2=A0=
=C2=A0 (lambda (buf &amp;rest _whatever) ; make it even more lax</div><div>=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (buffer-match-p condition)))</div><div=
><br></div><div>Later on, you might even pass an (... &amp;optional compile=
d) so that the return value</div><div>is syntax checked and optimized in so=
me way at compile time.<br></div><div><br></div><div>IOW, (E)Lisp already g=
ives you the tools for these composition without <br></div><div>needing to =
invent new languages with the drawbacks I listed.<br></div></div><br></div>

--00000000000061c0f005ec677090--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 13:04:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673078336203 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673078336203
          (code B ref 58839); Tue, 01 Nov 2022 13:04:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:03:53 +0000
Received: from localhost ([127.0.0.1]:42934 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opqvp-0001bz-7Y
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:03:53 -0400
Received: from mout02.posteo.de ([185.67.36.66]:39715)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opqvn-0001bi-32
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:03:51 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 6CD3B240104
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 14:03:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667307825; bh=/222M8XfWI8uMFaf9WDWFktcmvGsyP2cVelny237lRU=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=E2TirNsv46skA1FHUADAbVCehH3+GowHEc3IgecBBsBRlAgwpiVHInFf83hXdSCRU
 Pdbjy0DhTf5CL9f+bWgiGKQ8CpwN7NziYbNGFaRcGhLLHVxFwfVCUcyGpwlf3b21NC
 wfsKZ0spmwRZPvCAkj7Q3ywCOzQUrwLGkbD8h96KDK3ZKc9GpWgHDiR19WR2PZJVZP
 O00rBnV42RW3ejUds1wwOywhQfrBSGSfVWFLU7MPIo3NVYnQwUyb7GJuRrLtg6TCqq
 fwfpzaubSlij67mc+3daMkBnztBaldE4Vo0pfbEoft7B00LZQfcPPo70rvgE4AxMZF
 GKmtNvGbFldkw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1qvy0VtNz9rxW;
 Tue,  1 Nov 2022 14:03:42 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 1 Nov 2022
 11:59:12 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 13:03:36 +0000
Message-ID: <877d0ehlnb.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN>
> wrote:
>
>
>> E.g. `display-buffer-alist' makes use of it to associate display-buffer
>> rules with buffers.  Now you can add
>>
>>       ((major-mode . help-mode) display-buffer-in-side-window)
>>
>> instead of trying to match being a regular expression to catch all
>> *Help* buffer names of a function along the lines of
>>
>>       (lambda (buf _alist)
>>         (with-current-buffer buf
>>           (derived-mode-p 'help-mode)))
>>
>
> If you really want to save up on this typing, it's better to define
> a reusable helper function, or even a higher order function.
>
>   (defun buffer-mode-matcher (mode)
>     (lambda (b _alist)
>       (with-current-buffer b (derived-mode-p 'help-mode))))
>
> You can add buffer-mode-matcher to the library if it becomes
> useful enough.  Then you add:
>
>   `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)
>
> to display-buffer-alist.
>
> But if you really want a new language your language, then I suggest
> a simple adapter buffer-matcher utility that merges the two.  That way one
> doesn't couple existing utilities to the new mini-language and
> simultaneously
> the new mini-language become useful in a much wider setting for those who
> appreciate such things.
>
>   (defun buffer-matcher (condition)
>      "Return unary predicate of a buffer matching the CONDITION
> mini-language."
>     (lambda (buf &rest _whatever) ; make it even more lax
>        (buffer-match-p condition)))
>
> Later on, you might even pass an (... &optional compiled) so that the
> return value
> is syntax checked and optimized in some way at compile time.
>
> IOW, (E)Lisp already gives you the tools for these composition without
> needing to invent new languages with the drawbacks I listed.

I was curious to try this out, and implemented something along the lines
of your suggestion.  The bad news is that it is at least 10 times slower
than the current implementation, that isn't even really optimised.
Perhaps I did something native and didn't see what is wrong, but here
are my notes:

--8<---------------cut here---------------start------------->8---
(defun translate-buffer-condition (condition)
  "Compile a CONDITION into a predicate function."
  (pcase-exhaustive condition
    ((or 't 'nil)
     (lambda (_buffer _arg)
       condition))
    ((pred stringp)
     (lambda (buffer _arg)
       (string-match-p condition (buffer-name buffer))))
    ((pred functionp)
     (if (eq 1 (cdr (func-arity condition)))
	 (lambda (buffer _arg)
	   (funcall condition buffer))
       condition))
    (`(major-mode . ,mode)
     (lambda (buffer _arg)
       (eq
	(buffer-local-value 'major-mode buffer)
	mode)))
    (`(derived-mode . ,mode)
     (lambda (buffer _arg)
       (provided-mode-derived-p
	(buffer-local-value 'major-mode buffer)
	mode)))
    (`(not . ,cond)
     (lambda (buffer arg)
       (not (funcall (translate-buffer-condition cond) buffer arg))))
    (`(or . ,conds)
     (lambda (buffer arg)
       (catch 'match
	 (dolist (cond conds)
	   (when (funcall (translate-buffer-condition cond) buffer arg)
	     (throw 'match t))))))
    (`(and . ,conds)
     (lambda (buffer arg)
       (catch 'match
	 (dolist (cond conds t)
	   (when (funcall (translate-buffer-condition cond) buffer arg)
	     (throw 'match nil))))))))

(defvar buffer-match-p-cache (make-hash-table :test 'eq))

(defun buffer-match-p/compiled (condition buffer-or-name &optional arg)
  "Return non-nil if BUFFER-OR-NAME matches CONDITION.
CONDITION is either:
- the symbol t, to always match,
- the symbol nil, which never matches,
- a regular expression, to match a buffer name,
- a predicate function that takes a buffer object and ARG as
  arguments, and returns non-nil if the buffer matches,
- a cons-cell, where the car describes how to interpret the cdr.
  The car can be one of the following:
  * `derived-mode': the buffer matches if the buffer's major mode
    is derived from the major mode in the cons-cell's cdr.
  * `major-mode': the buffer matches if the buffer's major mode
    is eq to the cons-cell's cdr.  Prefer using `derived-mode'
    instead when both can work.
  * `not': the cdr is interpreted as a negation of a condition.
  * `and': the cdr is a list of recursive conditions, that all have
    to be met.
  * `or': the cdr is a list of recursive condition, of which at
    least one has to be met."
  (funcall (or (gethash condition buffer-match-p-cache)
	       (puthash condition
			(byte-compile (translate-buffer-condition condition))
			buffer-match-p-cache))
	   (get-buffer buffer-or-name)
	   arg))

(defun match-buffers/compiled (condition &optional buffers arg)
  "Return a list of buffers that match CONDITION.
See `buffer-match' for details on CONDITION.  By default all
buffers are checked, this can be restricted by passing an
optional argument BUFFERS, set to a list of buffers to check.
ARG is passed to `buffer-match', for predicate conditions in
CONDITION."
  (let (bufs)
    (dolist (buf (or buffers (buffer-list)))
      (when (buffer-match-p/compiled condition (get-buffer buf) arg)
        (push buf bufs)))
    bufs))

;; Here we will test a moderately complicated condition and time how
;; long it takes with the current implementation and with the proposed
;; alternative.

(defvar sample-condition
  '(and (or buffer-file-name
	    (derived-mode . compilation-mode)
	    (derived-mode . dired-mode)
	    (derived-mode . diff-mode)
	    (derived-mode . comint-mode)
	    (derived-mode . eshell-mode)
	    (derived-mode . change-log-mode))
	"\\*.+\\*"
	(not . "\\` ")))

(benchmark-run 100
  (match-buffers sample-condition pr))
;; =3D> (1.7045469830000002 20 1.1418286690000023)


(benchmark-run 1000
  (match-buffers/compiled project-buffer-conditions pr))
;; =3D> (17.646938126000002 219 12.428946030999999)
--8<---------------cut here---------------end--------------->8---

I guess this just goes to show that one shouldn't underestimate the cost
of a function call...

    LISP programmers know the value of everything and the cost of nothing.
         --  Alan Perlis=20

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 13:23:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673089677894 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673089677894
          (code B ref 58839); Tue, 01 Nov 2022 13:23:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:22:47 +0000
Received: from localhost ([127.0.0.1]:42947 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oprE7-00023F-FH
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:22:47 -0400
Received: from mail-wr1-f43.google.com ([209.85.221.43]:38755)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1oprE6-000231-4J
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:22:46 -0400
Received: by mail-wr1-f43.google.com with SMTP id a14so20084124wru.5
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:22:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=UZlLeIbfM84Vqu/4QOy8bca5EZpiUlS5JQgAvA6o0vY=;
 b=PkE9cDRxWJrqofShsk/5A8oRxY2p6c03RMtLh+rI7NUvmTjpkDOLpaTszInKTFvXky
 6u4nUVHOrD5g9QrUkCHuAMhXfqMQ9GW6F6rbkTySj15K0kaP2DkQKF2+rRYIhmbu5013
 FBHkRcMpbzF1fYjqx/t6NqEIKoMVdS0WWGFpeqGL8GzEr/DBSnguikNge9N55fta0Nzc
 omUcVAKYQ+n0lWJyV/ngsXCMATtru3fhvTDtRXEJUyru+ZTRodj1wrqkgkK0B2qY2Wsg
 CYttmJEEcOcd04XbWflGAm38//8d/Y9FWmRxz6F6Lu9YOhrk+kVtz9Hhwc/oxZYXk7kP
 nWjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=UZlLeIbfM84Vqu/4QOy8bca5EZpiUlS5JQgAvA6o0vY=;
 b=3uOqKqy9l5XajKXejkfpoDRi/IfIbxzxQYFXdwAIxCvWEZbJBMWnUDDEEx5VJi5OE5
 tPplmAGoNBQeTK1IEzUoAa7kmIUynj/BLudJvNVaq8MRca8MmfIMSqT4dtAvuFMDtehq
 q34Q2ME+6BzvHAGboZpiWNsujKMKhIx3YwaKWr9DX8U661vGRscJY0u7MwQOx1dKdR0K
 Ta1E8X3Im3nWwOONRRdb4A0WFNgUcnglPhrmMRpz4POMbaoPIVKcktGWjzr4b04iXRty
 +vnQumvV1O5XeP8FEs27cXkaZIFlcs/K13mCm7bRPUCc2vf6+lhb6UUuZKzX099dGffi
 ulwQ==
X-Gm-Message-State: ACrzQf1n93VxDB9aXzVaH/U2STNX3V9yT05EHr9/7Ghrou/ge2uIWR4m
 PoRSkCRq6JMWMkoWic/Rqjg=
X-Google-Smtp-Source: AMsMyM5eMx/WdaIs3EkdprP6noJxp8kmoDuGk+qWtjS9fZVpN5xAImZ290zBTALXR3CfwDMVD28mrQ==
X-Received: by 2002:a5d:554a:0:b0:22e:3d63:80bc with SMTP id
 g10-20020a5d554a000000b0022e3d6380bcmr94711wrw.30.1667308960223; 
 Tue, 01 Nov 2022 06:22:40 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 bv19-20020a0560001f1300b00236627c078esm10230408wrb.110.2022.11.01.06.22.39
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 06:22:39 -0700 (PDT)
Message-ID: <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN>
Date: Tue, 1 Nov 2022 15:22:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <87k04ggixk.fsf@HIDDEN> <875yfzvawz.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <875yfzvawz.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 01:19, João Távora wrote:
> We can try to make some backward compatible way, but this seems like the
> perfect occasion to activate this most reasonable header in project.el:
> 
>      ;; NOTE: The project API is still experimental and can change in major,
>      ;; backward-incompatible ways.  Everyone is encouraged to try it, and
>      ;; report to us any problems or use cases we hadn't anticipated, by
>      ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.

This is about the API.

project-kills-buffers is not part of it. It's just a regular user-level 
command, to be evolved how we do with regular commands.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 13:38:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673098299166 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673098299166
          (code B ref 58839); Tue, 01 Nov 2022 13:38:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:37:09 +0000
Received: from localhost ([127.0.0.1]:42952 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oprS0-0002Nl-QQ
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:37:09 -0400
Received: from mail-oo1-f54.google.com ([209.85.161.54]:42842)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oprRy-0002NE-Fz
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:37:07 -0400
Received: by mail-oo1-f54.google.com with SMTP id
 r15-20020a4abf0f000000b004761c7e6be1so2059109oop.9
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:37:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=8HwEpsuoNpnl+CBW7x367l71OL2U0dWXqTtQidV6DdM=;
 b=eLYCzpky9vSFTl2w2/x1tc/DlXrN9vzL6E4ksMfLIZsj4tyiqYAQyScDCB0vVXRLi5
 +foxMIvddvalGQioMQ/yZCJaRMbaoGcMvPBSWJH5zh/FeFMNX2+D53QwtZNHvrRDkPDe
 otMOZ9Ks+1rP9V+u6dfosO+avuili+3EUi4Ey0kAEzEIuVq69rawR8SyOS9kBi0jd4R2
 mfTvL64FuIiPeMhxoVH+0OXeJee5qwDut8dfOl8KykMBVVng6w1R+iDQkv3ujv7YbXTJ
 sqgIiq4A3MJaqql/C8L/CanXNCohFcCxK/YXE3/ND8xjr4P+PLwpsrrrjLM6iTsDtSTb
 ErUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=8HwEpsuoNpnl+CBW7x367l71OL2U0dWXqTtQidV6DdM=;
 b=crT0hggrXeDN00ra6POFNwQF9IMgTuff7S+Bn+Qz0IztPXwas713GGyTOKL6/03iGg
 4Lj4O2Qpc7z3zdhuW8H5266B0jaL+Pb6g+FGSnOFxubJHqul2dgeGgwyammHpuwRNJvq
 2VdMh0YB7Jk9/Hq8Y8ZxpTdZAsOvT2KMPrhPWClFs6jgl4tl4kqiEI7Afc4ch73ej061
 9WmFQ+Xe3AQsbZNg54lLfkcLpA3IaVQLjKFm2OAXywe2CyNTYEWj1ERxmkQeILyfPrDW
 fl+/QO63QxhIUncC1B6znfZLPGNqhFIJtUfIao/7cAGccQRV6TF2y/LVo5c75/n2Gl4S
 6wmA==
X-Gm-Message-State: ACrzQf1m2U0Dt1nRVYgyfVN6/G1uW6Su7Bclwl7ZS9T4APIBYn5CTqq5
 bg62Gu5WIuVSIHbyP7IifXa9N2u7IuCQ0Nfpvj8=
X-Google-Smtp-Source: AMsMyM7G1tSUUpctpfnDfj+fKi/5XQ27jExVbXSYJwTs+zZlRtTfAgM7eXAtMNq3xOALXqhdHK14lNX9fxrjOBFIdxE=
X-Received: by 2002:a4a:7:0:b0:495:f4a4:4bdc with SMTP id
 7-20020a4a0007000000b00495f4a44bdcmr8047669ooh.41.1667309820483; 
 Tue, 01 Nov 2022 06:37:00 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
In-Reply-To: <877d0ehlnb.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 13:37:58 +0000
Message-ID: <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000949d9f05ec68d1db"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000949d9f05ec68d1db
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I haven't studied your code in depth, but it seems like you're giving
`match-buffers/compiled` benchmark 10 times the work you're giving to
the other function, which would explain why it's 10x slower.

The byte-compiler (or the native compiler) can't really optimize the
mini-language more magically.  It can only optimize elisp.

My idea of using the byte-compiler to do this is different: it entails
translating the mini-language to elisp first and then byte-compiling
that.  But it is a technique that I think your code isn't applying
or at least not correctly (though I haven't read all of it: I will soon).

You can see eglot's "glob matching" section for the application of
such a technique the "glob" minilanguage that is required by LSP (iow
it wasn't "invented by me" ;-) )

Jo=C3=A3o

On Tue, Nov 1, 2022 at 1:03 PM Philip Kaludercic <philipk@HIDDEN> wrote=
:

> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>
> > On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic <philipk@HIDDEN>
> > wrote:
> >
> >
> >> E.g. `display-buffer-alist' makes use of it to associate display-buffe=
r
> >> rules with buffers.  Now you can add
> >>
> >>       ((major-mode . help-mode) display-buffer-in-side-window)
> >>
> >> instead of trying to match being a regular expression to catch all
> >> *Help* buffer names of a function along the lines of
> >>
> >>       (lambda (buf _alist)
> >>         (with-current-buffer buf
> >>           (derived-mode-p 'help-mode)))
> >>
> >
> > If you really want to save up on this typing, it's better to define
> > a reusable helper function, or even a higher order function.
> >
> >   (defun buffer-mode-matcher (mode)
> >     (lambda (b _alist)
> >       (with-current-buffer b (derived-mode-p 'help-mode))))
> >
> > You can add buffer-mode-matcher to the library if it becomes
> > useful enough.  Then you add:
> >
> >   `(,(buffer-mode-matcher 'help-mode) display-buffer-in-side-window)
> >
> > to display-buffer-alist.
> >
> > But if you really want a new language your language, then I suggest
> > a simple adapter buffer-matcher utility that merges the two.  That way
> one
> > doesn't couple existing utilities to the new mini-language and
> > simultaneously
> > the new mini-language become useful in a much wider setting for those w=
ho
> > appreciate such things.
> >
> >   (defun buffer-matcher (condition)
> >      "Return unary predicate of a buffer matching the CONDITION
> > mini-language."
> >     (lambda (buf &rest _whatever) ; make it even more lax
> >        (buffer-match-p condition)))
> >
> > Later on, you might even pass an (... &optional compiled) so that the
> > return value
> > is syntax checked and optimized in some way at compile time.
> >
> > IOW, (E)Lisp already gives you the tools for these composition without
> > needing to invent new languages with the drawbacks I listed.
>
> I was curious to try this out, and implemented something along the lines
> of your suggestion.  The bad news is that it is at least 10 times slower
> than the current implementation, that isn't even really optimised.
> Perhaps I did something native and didn't see what is wrong, but here
> are my notes:
>
> --8<---------------cut here---------------start------------->8---
> (defun translate-buffer-condition (condition)
>   "Compile a CONDITION into a predicate function."
>   (pcase-exhaustive condition
>     ((or 't 'nil)
>      (lambda (_buffer _arg)
>        condition))
>     ((pred stringp)
>      (lambda (buffer _arg)
>        (string-match-p condition (buffer-name buffer))))
>     ((pred functionp)
>      (if (eq 1 (cdr (func-arity condition)))
>          (lambda (buffer _arg)
>            (funcall condition buffer))
>        condition))
>     (`(major-mode . ,mode)
>      (lambda (buffer _arg)
>        (eq
>         (buffer-local-value 'major-mode buffer)
>         mode)))
>     (`(derived-mode . ,mode)
>      (lambda (buffer _arg)
>        (provided-mode-derived-p
>         (buffer-local-value 'major-mode buffer)
>         mode)))
>     (`(not . ,cond)
>      (lambda (buffer arg)
>        (not (funcall (translate-buffer-condition cond) buffer arg))))
>     (`(or . ,conds)
>      (lambda (buffer arg)
>        (catch 'match
>          (dolist (cond conds)
>            (when (funcall (translate-buffer-condition cond) buffer arg)
>              (throw 'match t))))))
>     (`(and . ,conds)
>      (lambda (buffer arg)
>        (catch 'match
>          (dolist (cond conds t)
>            (when (funcall (translate-buffer-condition cond) buffer arg)
>              (throw 'match nil))))))))
>
> (defvar buffer-match-p-cache (make-hash-table :test 'eq))
>
> (defun buffer-match-p/compiled (condition buffer-or-name &optional arg)
>   "Return non-nil if BUFFER-OR-NAME matches CONDITION.
> CONDITION is either:
> - the symbol t, to always match,
> - the symbol nil, which never matches,
> - a regular expression, to match a buffer name,
> - a predicate function that takes a buffer object and ARG as
>   arguments, and returns non-nil if the buffer matches,
> - a cons-cell, where the car describes how to interpret the cdr.
>   The car can be one of the following:
>   * `derived-mode': the buffer matches if the buffer's major mode
>     is derived from the major mode in the cons-cell's cdr.
>   * `major-mode': the buffer matches if the buffer's major mode
>     is eq to the cons-cell's cdr.  Prefer using `derived-mode'
>     instead when both can work.
>   * `not': the cdr is interpreted as a negation of a condition.
>   * `and': the cdr is a list of recursive conditions, that all have
>     to be met.
>   * `or': the cdr is a list of recursive condition, of which at
>     least one has to be met."
>   (funcall (or (gethash condition buffer-match-p-cache)
>                (puthash condition
>                         (byte-compile (translate-buffer-condition
> condition))
>                         buffer-match-p-cache))
>            (get-buffer buffer-or-name)
>            arg))
>
> (defun match-buffers/compiled (condition &optional buffers arg)
>   "Return a list of buffers that match CONDITION.
> See `buffer-match' for details on CONDITION.  By default all
> buffers are checked, this can be restricted by passing an
> optional argument BUFFERS, set to a list of buffers to check.
> ARG is passed to `buffer-match', for predicate conditions in
> CONDITION."
>   (let (bufs)
>     (dolist (buf (or buffers (buffer-list)))
>       (when (buffer-match-p/compiled condition (get-buffer buf) arg)
>         (push buf bufs)))
>     bufs))
>
> ;; Here we will test a moderately complicated condition and time how
> ;; long it takes with the current implementation and with the proposed
> ;; alternative.
>
> (defvar sample-condition
>   '(and (or buffer-file-name
>             (derived-mode . compilation-mode)
>             (derived-mode . dired-mode)
>             (derived-mode . diff-mode)
>             (derived-mode . comint-mode)
>             (derived-mode . eshell-mode)
>             (derived-mode . change-log-mode))
>         "\\*.+\\*"
>         (not . "\\` ")))
>
> (benchmark-run 100
>   (match-buffers sample-condition pr))
> ;; =3D> (1.7045469830000002 20 1.1418286690000023)
>
>
> (benchmark-run 1000
>   (match-buffers/compiled project-buffer-conditions pr))
> ;; =3D> (17.646938126000002 219 12.428946030999999)
> --8<---------------cut here---------------end--------------->8---
>
> I guess this just goes to show that one shouldn't underestimate the cost
> of a function call...
>
>     LISP programmers know the value of everything and the cost of nothing=
.
>          --  Alan Perlis
>


--=20
Jo=C3=A3o T=C3=A1vora

--000000000000949d9f05ec68d1db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I haven&#39;t studied your code in depth, but it seem=
s like you&#39;re giving</div><div>`match-buffers/compiled` benchmark 10 ti=
mes the work you&#39;re giving to <br></div><div>the other function, which =
would explain why it&#39;s 10x slower.</div><div><br></div><div>The byte-co=
mpiler (or the native compiler) can&#39;t really optimize the <br></div><di=
v>mini-language more magically.=C2=A0 It can only optimize elisp.</div><div=
><br></div><div>My idea of using the byte-compiler to do this is different:=
 it entails <br></div><div>translating the mini-language to elisp first and=
 then byte-compiling <br></div><div>that.=C2=A0 But it is a technique that =
I think your code isn&#39;t applying <br></div><div>or at least not correct=
ly (though I haven&#39;t read all of it: I will soon).</div><div><br></div>=
<div>You can see eglot&#39;s &quot;glob matching&quot; section for the appl=
ication of <br></div><div>such a technique the &quot;glob&quot; minilanguag=
e that is required by LSP (iow <br></div><div>it wasn&#39;t &quot;invented =
by me&quot; ;-) )<br></div><div></div><div><br></div><div>Jo=C3=A3o<br></di=
v></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr=
">On Tue, Nov 1, 2022 at 1:03 PM Philip Kaludercic &lt;<a href=3D"mailto:ph=
ilipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex">Jo=C3=A3o T=C3=A1vora &lt;<a href=3D"ma=
ilto:joaotavora@HIDDEN" target=3D"_blank">joaotavora@HIDDEN</a>&gt; w=
rites:<br>
<br>
&gt; On Tue, Nov 1, 2022 at 11:27 AM Philip Kaludercic &lt;<a href=3D"mailt=
o:philipk@HIDDEN" target=3D"_blank">philipk@HIDDEN</a>&gt;<br>
&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt;&gt; E.g. `display-buffer-alist&#39; makes use of it to associate displ=
ay-buffer<br>
&gt;&gt; rules with buffers.=C2=A0 Now you can add<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0((major-mode . help-mode) display-buffer=
-in-side-window)<br>
&gt;&gt;<br>
&gt;&gt; instead of trying to match being a regular expression to catch all=
<br>
&gt;&gt; *Help* buffer names of a function along the lines of<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (buf _alist)<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer buf<br>
&gt;&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(derived-mode-p &#39;help-=
mode)))<br>
&gt;&gt;<br>
&gt;<br>
&gt; If you really want to save up on this typing, it&#39;s better to defin=
e<br>
&gt; a reusable helper function, or even a higher order function.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0(defun buffer-mode-matcher (mode)<br>
&gt;=C2=A0 =C2=A0 =C2=A0(lambda (b _alist)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0(with-current-buffer b (derived-mode-p &#39;=
help-mode))))<br>
&gt;<br>
&gt; You can add buffer-mode-matcher to the library if it becomes<br>
&gt; useful enough.=C2=A0 Then you add:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0`(,(buffer-mode-matcher &#39;help-mode) display-buffer-in-=
side-window)<br>
&gt;<br>
&gt; to display-buffer-alist.<br>
&gt;<br>
&gt; But if you really want a new language your language, then I suggest<br=
>
&gt; a simple adapter buffer-matcher utility that merges the two.=C2=A0 Tha=
t way one<br>
&gt; doesn&#39;t couple existing utilities to the new mini-language and<br>
&gt; simultaneously<br>
&gt; the new mini-language become useful in a much wider setting for those =
who<br>
&gt; appreciate such things.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0(defun buffer-matcher (condition)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 &quot;Return unary predicate of a buffer matching =
the CONDITION<br>
&gt; mini-language.&quot;<br>
&gt;=C2=A0 =C2=A0 =C2=A0(lambda (buf &amp;rest _whatever) ; make it even mo=
re lax<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-match-p condition)))<br>
&gt;<br>
&gt; Later on, you might even pass an (... &amp;optional compiled) so that =
the<br>
&gt; return value<br>
&gt; is syntax checked and optimized in some way at compile time.<br>
&gt;<br>
&gt; IOW, (E)Lisp already gives you the tools for these composition without=
<br>
&gt; needing to invent new languages with the drawbacks I listed.<br>
<br>
I was curious to try this out, and implemented something along the lines<br=
>
of your suggestion.=C2=A0 The bad news is that it is at least 10 times slow=
er<br>
than the current implementation, that isn&#39;t even really optimised.<br>
Perhaps I did something native and didn&#39;t see what is wrong, but here<b=
r>
are my notes:<br>
<br>
--8&lt;---------------cut here---------------start-------------&gt;8---<br>
(defun translate-buffer-condition (condition)<br>
=C2=A0 &quot;Compile a CONDITION into a predicate function.&quot;<br>
=C2=A0 (pcase-exhaustive condition<br>
=C2=A0 =C2=A0 ((or &#39;t &#39;nil)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (_buffer _arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0condition))<br>
=C2=A0 =C2=A0 ((pred stringp)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(string-match-p condition (buffer-name buffer)))=
)<br>
=C2=A0 =C2=A0 ((pred functionp)<br>
=C2=A0 =C2=A0 =C2=A0(if (eq 1 (cdr (func-arity condition)))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(funcall condition buffer))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0condition))<br>
=C2=A0 =C2=A0 (`(major-mode . ,mode)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(eq<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-local-value &#39;major-mode buffer)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mode)))<br>
=C2=A0 =C2=A0 (`(derived-mode . ,mode)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer _arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(provided-mode-derived-p<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (buffer-local-value &#39;major-mode buffer)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mode)))<br>
=C2=A0 =C2=A0 (`(not . ,cond)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(not (funcall (translate-buffer-condition cond) =
buffer arg))))<br>
=C2=A0 =C2=A0 (`(or . ,conds)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(catch &#39;match<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(dolist (cond conds)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (funcall (translate-buffer-c=
ondition cond) buffer arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(throw &#39;match t))))))<b=
r>
=C2=A0 =C2=A0 (`(and . ,conds)<br>
=C2=A0 =C2=A0 =C2=A0(lambda (buffer arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(catch &#39;match<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(dolist (cond conds t)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(when (funcall (translate-buffer-c=
ondition cond) buffer arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(throw &#39;match nil))))))=
))<br>
<br>
(defvar buffer-match-p-cache (make-hash-table :test &#39;eq))<br>
<br>
(defun buffer-match-p/compiled (condition buffer-or-name &amp;optional arg)=
<br>
=C2=A0 &quot;Return non-nil if BUFFER-OR-NAME matches CONDITION.<br>
CONDITION is either:<br>
- the symbol t, to always match,<br>
- the symbol nil, which never matches,<br>
- a regular expression, to match a buffer name,<br>
- a predicate function that takes a buffer object and ARG as<br>
=C2=A0 arguments, and returns non-nil if the buffer matches,<br>
- a cons-cell, where the car describes how to interpret the cdr.<br>
=C2=A0 The car can be one of the following:<br>
=C2=A0 * `derived-mode&#39;: the buffer matches if the buffer&#39;s major m=
ode<br>
=C2=A0 =C2=A0 is derived from the major mode in the cons-cell&#39;s cdr.<br=
>
=C2=A0 * `major-mode&#39;: the buffer matches if the buffer&#39;s major mod=
e<br>
=C2=A0 =C2=A0 is eq to the cons-cell&#39;s cdr.=C2=A0 Prefer using `derived=
-mode&#39;<br>
=C2=A0 =C2=A0 instead when both can work.<br>
=C2=A0 * `not&#39;: the cdr is interpreted as a negation of a condition.<br=
>
=C2=A0 * `and&#39;: the cdr is a list of recursive conditions, that all hav=
e<br>
=C2=A0 =C2=A0 to be met.<br>
=C2=A0 * `or&#39;: the cdr is a list of recursive condition, of which at<br=
>
=C2=A0 =C2=A0 least one has to be met.&quot;<br>
=C2=A0 (funcall (or (gethash condition buffer-match-p-cache)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(puthash condition<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (byte-compile (translate-buffer-condition condition))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 buffer-match-p-cache))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(get-buffer buffer-or-name)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0arg))<br>
<br>
(defun match-buffers/compiled (condition &amp;optional buffers arg)<br>
=C2=A0 &quot;Return a list of buffers that match CONDITION.<br>
See `buffer-match&#39; for details on CONDITION.=C2=A0 By default all<br>
buffers are checked, this can be restricted by passing an<br>
optional argument BUFFERS, set to a list of buffers to check.<br>
ARG is passed to `buffer-match&#39;, for predicate conditions in<br>
CONDITION.&quot;<br>
=C2=A0 (let (bufs)<br>
=C2=A0 =C2=A0 (dolist (buf (or buffers (buffer-list)))<br>
=C2=A0 =C2=A0 =C2=A0 (when (buffer-match-p/compiled condition (get-buffer b=
uf) arg)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (push buf bufs)))<br>
=C2=A0 =C2=A0 bufs))<br>
<br>
;; Here we will test a moderately complicated condition and time how<br>
;; long it takes with the current implementation and with the proposed<br>
;; alternative.<br>
<br>
(defvar sample-condition<br>
=C2=A0 &#39;(and (or buffer-file-name<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . compilation-mode)=
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . dired-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . diff-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . comint-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . eshell-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (derived-mode . change-log-mode))=
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &quot;\\*.+\\*&quot;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (not . &quot;\\` &quot;)))<br>
<br>
(benchmark-run 100<br>
=C2=A0 (match-buffers sample-condition pr))<br>
;; =3D&gt; (1.7045469830000002 20 1.1418286690000023)<br>
<br>
<br>
(benchmark-run 1000<br>
=C2=A0 (match-buffers/compiled project-buffer-conditions pr))<br>
;; =3D&gt; (17.646938126000002 219 12.428946030999999)<br>
--8&lt;---------------cut here---------------end---------------&gt;8---<br>
<br>
I guess this just goes to show that one shouldn&#39;t underestimate the cos=
t<br>
of a function call...<br>
<br>
=C2=A0 =C2=A0 LISP programmers know the value of everything and the cost of=
 nothing.<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--=C2=A0 Alan Perlis <br>
</blockquote></div><br clear=3D"all"><br>-- <br><div dir=3D"ltr" class=3D"g=
mail_signature">Jo=C3=A3o T=C3=A1vora</div>

--000000000000949d9f05ec68d1db--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 13:39:02 +0000
Resent-Message-ID: <handler.58839.B58839.16673098959272 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673098959272
          (code B ref 58839); Tue, 01 Nov 2022 13:39:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 13:38:15 +0000
Received: from localhost ([127.0.0.1]:42956 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oprT4-0002PU-VU
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:38:15 -0400
Received: from mail-oa1-f46.google.com ([209.85.160.46]:33686)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oprT3-0002PH-On
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 09:38:14 -0400
Received: by mail-oa1-f46.google.com with SMTP id
 586e51a60fabf-13bd2aea61bso16868431fac.0
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 06:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=vHc9DcZ5LRcp6WiUPIRkf4ktgh7G+pHsBpMQX3uIVnI=;
 b=cp7QcXccTkaTbHdRpmFrC6sSu/UIHUOGbkI1atlEVf/vp3BSd1rc4+Hd3SgtjqLgb1
 Z+23PkCXgfOloeN3UzmfyXOxnq2uAY4SBPtp00Z+vweE531kYSI/h4lot6DquN5bbl8d
 3d+NJuP3QzT+yQK8eFRm42O/vo0GEUck4kDj7DOoQIgc/SGlLrZjHtcmGl8/+JjhB3Fu
 pUNHgwvyGNF9NTN2tU+xXDRt4haVBOxSt/VOgNumDu96lWHUd0aBbkaF1COV+7UX7FVf
 4kSpXmxrzby3MfG0fLZSq6wao7MBjt9P+mWOBH0HyNRa+LcQx/8psG4/9r8j9cKLLT6W
 fv6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=vHc9DcZ5LRcp6WiUPIRkf4ktgh7G+pHsBpMQX3uIVnI=;
 b=IQqyITBseQUIn9ajQsAMNV6XxP2PtKJ08x9Y92aCj8rwUsGL+VHAQ4yZMmRlWeNbCw
 Th7zyXg8AzB6ioLfxeXoevFNBoJ6lNSRcfuVtbV54YtxUboGBo3kS7YZrh9a+pBVVjXz
 8N8kLGSu4pd5oyqjPR22+34PTfX+LhA8Mbmra4Nr4AbbVlf6mlbndiAA4L0g8oi5M93H
 PdFlOGqIjlkSfYzwlhc7z/lWsTw8OCHKwkY6BU9RSi7Rc41TcwxZjlexdP0djcxiwxqv
 iLqqRRgTDvpwBIoun8eXqqvPJtgTlc0vmEAPBITo6DWaclfpLKRhZw7dOi4XVvZFNheF
 r/CA==
X-Gm-Message-State: ACrzQf1xMVeHK8WdFw8JLn/d/mm/2fiV8xaVH6LUXjFbePJJMa6034fO
 7nzKROMHuqhY7OlGxx6ST+KnSyKuEIBmRW88rLQ=
X-Google-Smtp-Source: AMsMyM5eGntpjLBp9j2IuK5wbR/ZJO9HnQMKa6xLWAh0RrxvUnir59AmpylqeNnSd7v2GBDpGxOf9+KfyGay6fasTlY=
X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id
 d2-20020a056870e24200b0013bd561ad02mr11297714oac.215.1667309888295; Tue, 01
 Nov 2022 06:38:08 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <87k04ggixk.fsf@HIDDEN> <875yfzvawz.fsf@HIDDEN>
 <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN>
In-Reply-To: <351398ad-1292-f366-3adf-f86a129f9c90@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 13:39:05 +0000
Message-ID: <CALDnm51rxRsMrZ7Nt-E_cLJryzMD0xx9qkHxmjOoctQNxn-m6g@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000009f58a305ec68d565"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--0000000000009f58a305ec68d565
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2022 at 1:22 PM Dmitry Gutov <dgutov@HIDDEN> wrote:

> On 01.11.2022 01:19, Jo=C3=A3o T=C3=A1vora wrote:
> > We can try to make some backward compatible way, but this seems like th=
e
> > perfect occasion to activate this most reasonable header in project.el:
> >
> >      ;; NOTE: The project API is still experimental and can change in
> major,
> >      ;; backward-incompatible ways.  Everyone is encouraged to try it,
> and
> >      ;; report to us any problems or use cases we hadn't anticipated, b=
y
> >      ;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>
> This is about the API.
>
> project-kills-buffers is not part of it. It's just a regular user-level
> command, to be evolved how we do with regular commands.


project-kill-buffers is great: I don't mean to deprecate it change it,
its protocol etc.  If "evolution" means fixing what are demonstrably
its very salient bugs, that's great.

Philip's worry was about project-kill-buffer-conditions.  That variable
contains a programming language and could be deprecated (if we
arrive at the conclusion that it is easily replaced by something else).
We shouldn't be shy of doing so a backward-incompatible way, given that
its usage is estimated to be minimal (and this estimation is backed up
by real data, not just a guess).

--0000000000009f58a305ec68d565
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 1:22 PM Dmitry Gutov &lt;<a href=3D"mailto:dg=
utov@HIDDEN">dgutov@HIDDEN</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On 01.11.2022 01:19, Jo=C3=A3o T=C3=A1vora=
 wrote:<br>
&gt; We can try to make some backward compatible way, but this seems like t=
he<br>
&gt; perfect occasion to activate this most reasonable header in project.el=
:<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 ;; NOTE: The project API is still experimental and=
 can change in major,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 ;; backward-incompatible ways.=C2=A0 Everyone is e=
ncouraged to try it, and<br>
&gt;=C2=A0 =C2=A0 =C2=A0 ;; report to us any problems or use cases we hadn&=
#39;t anticipated, by<br>
&gt;=C2=A0 =C2=A0 =C2=A0 ;; sending an email to emacs-devel, or `M-x report=
-emacs-bug&#39;.<br>
<br>
This is about the API.<br>
<br>
project-kills-buffers is not part of it. It&#39;s just a regular user-level=
 <br>
command, to be evolved how we do with regular commands.</blockquote></div><=
div><br></div><div></div><div>project-kill-buffers is great: I don&#39;t me=
an to deprecate it change it, <br></div><div>its protocol etc.=C2=A0 If &qu=
ot;evolution&quot; means fixing what are demonstrably <br></div><div>its ve=
ry salient bugs, that&#39;s great.<br></div><div><br></div><div>Philip&#39;=
s worry was about project-kill-buffer-conditions.=C2=A0 That variable <br><=
/div><div>contains a programming language and could be deprecated (if we <b=
r></div><div>arrive at the conclusion that it is easily replaced by somethi=
ng else).</div><div>We shouldn&#39;t be shy of doing so a backward-incompat=
ible way, given that</div><div>its usage is estimated to be minimal (and th=
is estimation is backed up</div><div>by real data, not just a guess).<br></=
div></div>

--0000000000009f58a305ec68d565--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 14:02:02 +0000
Resent-Message-ID: <handler.58839.B58839.166731126412541 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166731126412541
          (code B ref 58839); Tue, 01 Nov 2022 14:02:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:01:04 +0000
Received: from localhost ([127.0.0.1]:43941 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oprpA-0003GD-5e
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:01:04 -0400
Received: from mout02.posteo.de ([185.67.36.66]:60671)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oprp7-0003FZ-7I
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:01:02 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 73BF0240104
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 15:00:55 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667311255; bh=5EVYzVr8SRK6BFjdPIb5C+crEl8LXYBRXsj8pIZCzjA=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=HXrPloGg8+e5vWftbVpxYsAcoGWG2HkTZsYADL9qhG4oF3zWxh7X8HNrssq8Ogxvx
 K4OhKrqCE821EOm2eH8wJpn/W7MqHnlahfAw7xuI8JdRxYNs7GPhz8mfqn7p8iu/qg
 g4fBG4u3OUyjrar0naSmEVuCPU9SQW3/KAF0s2rJt+uVx+EUKcU7dgfacHIE1yGUO3
 fj+f/qIw2i884xseTyYb/vhuMx78Q8ZbAgfqHlDs3CrBmIjDRYdOiZ6Zk16ZI29FAx
 +3FRW0/L1B+qlBuZE3UliZfLH2ZIxzPZg0UagZohnhFP0nUIcPENq97LAWbwIvpp/w
 yd+uVUxef6dgA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1s9y3196z9rxY;
 Tue,  1 Nov 2022 15:00:54 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 1 Nov 2022
 13:37:58 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 14:00:54 +0000
Message-ID: <87edumg4fd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> I haven't studied your code in depth, but it seems like you're giving
> `match-buffers/compiled` benchmark 10 times the work you're giving to
> the other function, which would explain why it's 10x slower.
>

You are absolutely right, I re-ran the tests the right way and got these
results:

--8<---------------cut here---------------start------------->8---
(benchmark-run 1000
  (match-buffers sample-condition))
;; =3D> (25.052781603 265 16.678798381999997)

(benchmark-run 1000
  (match-buffers/compiled sample-condition))
;; (30.021295067 335 21.01291473699999)
--8<---------------cut here---------------end--------------->8---

> The byte-compiler (or the native compiler) can't really optimize the
> mini-language more magically.  It can only optimize elisp.

Of course, I don't get why it should?

> My idea of using the byte-compiler to do this is different: it entails
> translating the mini-language to elisp first and then byte-compiling
> that.  But it is a technique that I think your code isn't applying
> or at least not correctly (though I haven't read all of it: I will soon).

What I am doing is translating it into lambda expressions, but I could
also try out translating it into an s-expression and passing that to
`eval'...

> You can see eglot's "glob matching" section for the application of
> such a technique the "glob" minilanguage that is required by LSP (iow
> it wasn't "invented by me" ;-) )

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 14:11:02 +0000
Resent-Message-ID: <handler.58839.B58839.166731184413344 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166731184413344
          (code B ref 58839); Tue, 01 Nov 2022 14:11:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:10:44 +0000
Received: from localhost ([127.0.0.1]:43946 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opryW-0003TA-8h
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:10:44 -0400
Received: from mail-oo1-f50.google.com ([209.85.161.50]:34605)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opryU-0003Sv-F6
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:10:43 -0400
Received: by mail-oo1-f50.google.com with SMTP id
 v8-20020a4ab688000000b00486ac81143fso2070898ooo.1
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 07:10:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=QzpGtOu9iOOwpnGNjAbO1oAqS6AwgrA16djs3xyMpnA=;
 b=V6EO7q3lXACIgNB+gUevmhGSTL1/DvHg+NXfUeQMkr03aJ9Ga0f2LWew6nwkTja1mu
 7kKoXvKPXCsWDJAdecVDPbTa9KauXsE5zdfwhOly57/diP1WfHX7u55/AntiDzJs3DQO
 j2zBDsTW5TrnWSfAYfOEqhng6u76DpZW1KtcNZa7tLNvFzMn9uiboP4zczAoKH/Z3dNy
 ASxiSVdG2PZro+MbLXDl+tohRn1B9R5U8SfAmwr+FnVEKh3tlzpfULKLSJJrMURvz5eb
 N1sC9Nn83LtGbWLu90lRZUaHWgvZu0K0BmnaVeTu+xusC4BSjkLTOup3dslnbBAma1v7
 zArQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=QzpGtOu9iOOwpnGNjAbO1oAqS6AwgrA16djs3xyMpnA=;
 b=K0aS/9RF2lKENJJZqm7w5NfDCRDWcfGUBSjzX9/h1KekOmkaGA/hu63CGYryoo2AZP
 7JNmvL+IBWsZ49kf2PssW+b+BvN1Nwe4Pdy6O6Cvu/3r1e0W5hg06VLiLYrm/m38badu
 bRfPlmRZyPK38sCDhUJZENnUD+7hSdDNB08eH5D3YnsJmvNncMBARrRUuFuAj0J1ubvv
 hpHPKU+k2ncm6sgn3/X+9wEsAOkpneAX0WZ0ahywOoKu9gjJJNLlc61MTKjM9ayyroA2
 RAXXb5Q02Xy89bgkJjTkwmoUVaSfGbsW8Ela8t+Oomo+Mvu+1VsI/6Erib8kpJok/emA
 p/EQ==
X-Gm-Message-State: ACrzQf0vpVNra2Z2qkqh/e/MjIMR8FypB5YDumHgj+kCLSNXDr+W7g37
 2uL/umTepqVO6sfOSdFzHghx3byyUK76l3BWiw8=
X-Google-Smtp-Source: AMsMyM6C/IwwLSoQ2i7OThpf6pbSwITgN1ynMSuBd+zXPNFLIdOCnGzKg05Uc5sLXE8ALv+l8spTJ08h4C4XV5ssFbY=
X-Received: by 2002:a4a:7:0:b0:495:f4a4:4bdc with SMTP id
 7-20020a4a0007000000b00495f4a44bdcmr8114923ooh.41.1667311836895; 
 Tue, 01 Nov 2022 07:10:36 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
In-Reply-To: <87edumg4fd.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 14:11:35 +0000
Message-ID: <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c49f2605ec694965"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000c49f2605ec694965
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic <philipk@HIDDEN> wrote=
:


> > My idea of using the byte-compiler to do this is different: it entails
> > translating the mini-language to elisp first and then byte-compiling
> > that.  But it is a technique that I think your code isn't applying
> > or at least not correctly (though I haven't read all of it: I will soon=
).
>
> What I am doing is translating it into lambda expressions, but I could
> also try out translating it into an s-expression and passing that to
> `eval'...
>

Yes, do that, but use byte-compile instead, not eval.

Jo=C3=A3o T=C3=A1vora

--000000000000c49f2605ec694965
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic &lt;<a href=3D"mail=
to:philipk@HIDDEN">philipk@HIDDEN</a>&gt; wrote:<br></div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; My idea of using the byte-compiler to do this is different: it entails=
<br>
&gt; translating the mini-language to elisp first and then byte-compiling<b=
r>
&gt; that.=C2=A0 But it is a technique that I think your code isn&#39;t app=
lying<br>
&gt; or at least not correctly (though I haven&#39;t read all of it: I will=
 soon).<br>
<br>
What I am doing is translating it into lambda expressions, but I could<br>
also try out translating it into an s-expression and passing that to<br>
`eval&#39;...<br></blockquote><div><br></div><div>Yes, do that, but use byt=
e-compile instead, not eval. <br></div><div><br></div></div><div dir=3D"ltr=
" class=3D"gmail_signature">Jo=C3=A3o T=C3=A1vora</div></div>

--000000000000c49f2605ec694965--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 14:37:02 +0000
Resent-Message-ID: <handler.58839.B58839.166731341415836 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166731341415836
          (code B ref 58839); Tue, 01 Nov 2022 14:37:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 14:36:54 +0000
Received: from localhost ([127.0.0.1]:43975 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opsNq-00047K-1l
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:36:54 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39209)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opsNo-000478-6S
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 10:36:53 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id A658D240028
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 15:36:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667313406; bh=jvwBwx3y90+U9jOkSychBOnmFaZEDA+3leADCfEbYJU=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=bM+tmHl2xk9NbRSKNWww2Xljb9rMFcBYBVrJuhw0CLo3oiolQTy4lwZOkTwr5uOfF
 BGU/qd2rNUJlMH3Qh1hm2OhAM968rK+Id7/Nim8g5B24xqlF3X752YmEiyZjScND3B
 w8br5QAU/GZ9mRiRqiJe4lmkXnlpt2xGamm9FYheSub6UbtVMU63MFuhwldDVlL3CL
 1EvDbBmNzB2ZppIvamX3Gf4byGThzHwcDG6IGdFPJyzl0X/vOOhLvqL5IbqYyi06Q1
 uyoWWHdHmWx9ot8W3/AwSx3dkP5OCKqusECyo2oozQ/U+BqIr6IpjoYD4SEnRvyfxZ
 oSiHwCX6xvTkA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1szK0bFHz9rxV;
 Tue,  1 Nov 2022 15:36:42 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 1 Nov 2022
 14:11:35 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 14:36:42 +0000
Message-ID: <874jvig2rp.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> On Tue, Nov 1, 2022 at 2:00 PM Philip Kaludercic <philipk@HIDDEN> wro=
te:
>
>
>> > My idea of using the byte-compiler to do this is different: it entails
>> > translating the mini-language to elisp first and then byte-compiling
>> > that.  But it is a technique that I think your code isn't applying
>> > or at least not correctly (though I haven't read all of it: I will soo=
n).
>>
>> What I am doing is translating it into lambda expressions, but I could
>> also try out translating it into an s-expression and passing that to
>> `eval'...
>>
>
> Yes, do that, but use byte-compile instead, not eval.

I have tried both, and it doesn't appear to be a particular advantage
one way or another.  That being said, this approach is *a lot* faster,
to the point that I first assumed it was broken:

--8<---------------cut here---------------start------------->8---
(benchmark-run 1000
  (match-buffers/compiled sample-condition))
;; (0.469515746 5 0.3328363100000047)
--8<---------------cut here---------------end--------------->8---

but it works:

--8<---------------cut here---------------start------------->8---
(equal (match-buffers sample-condition) (match-buffers/compiled sample-cond=
ition))
;; =3D> t
--8<---------------cut here---------------end--------------->8---

So this is certainly something worth considering as a replacement!

Here is the implementation:

--8<---------------cut here---------------start------------->8---
(defvar translate-buffer-condition-buffer-sym (make-symbol "buffer"))
(defvar translate-buffer-condition-arg-sym (make-symbol "arg"))

(defun translate-buffer-condition (condition)
  "Compile a CONDITION into a predicate function."
  (pcase-exhaustive condition
    ((or 't 'nil)
     condition)
    ((pred stringp)
     `(string-match-p ,condition (buffer-name ,translate-buffer-condition-b=
uffer-sym)))
    ((pred functionp)
     (if (eq 1 (cdr (func-arity condition)))
         ;; FIXME: is `funcall' necessary here?
	 `(funcall #',condition ,translate-buffer-condition-buffer-sym)
       `(funcall ,condition
		 ,translate-buffer-condition-buffer-sym
		 ,translate-buffer-condition-arg-sym)))
    (`(major-mode . ,mode)
     `(eq (buffer-local-value 'major-mode ,translate-buffer-condition-buffe=
r-sym)
	  ',mode))
    (`(derived-mode . ,mode)
     `(provided-mode-derived-p
       (buffer-local-value 'major-mode ,translate-buffer-condition-buffer-s=
ym)
       ',mode))
    (`(not . ,cond)
     `(not ,(translate-buffer-condition cond)))
    (`(or . ,conds)
     `(or ,@(mapcar #'translate-buffer-condition conds)))
    (`(and . ,conds)
     `(and ,@(mapcar #'translate-buffer-condition conds)))))

(defvar buffer-match-p-cache (make-hash-table :test 'eq))

(defun buffer-match-p/evaled (condition buffer-or-name &optional arg)
  "Return non-nil if BUFFER-OR-NAME matches CONDITION.
CONDITION is either:
- the symbol t, to always match,
- the symbol nil, which never matches,
- a regular expression, to match a buffer name,
- a predicate function that takes a buffer object and ARG as
  arguments, and returns non-nil if the buffer matches,
- a cons-cell, where the car describes how to interpret the cdr.
  The car can be one of the following:
  * `derived-mode': the buffer matches if the buffer's major mode
    is derived from the major mode in the cons-cell's cdr.
  * `major-mode': the buffer matches if the buffer's major mode
    is eq to the cons-cell's cdr.  Prefer using `derived-mode'
    instead when both can work.
  * `not': the cdr is interpreted as a negation of a condition.
  * `and': the cdr is a list of recursive conditions, that all have
    to be met.
  * `or': the cdr is a list of recursive condition, of which at
    least one has to be met."
  (eval (or (gethash condition buffer-match-p-cache)
	    (puthash condition
		     (translate-buffer-condition condition)
		     buffer-match-p-cache))
	`((,translate-buffer-condition-buffer-sym . ,(get-buffer buffer-or-name))
	  (,translate-buffer-condition-arg-sym . ,arg))))

;; Alternative implementation using `byte-compile':
;;
;; (funcall (or (gethash condition buffer-match-p-cache)
;; 	       (puthash condition
;; 			(byte-compile
;; 			 `(lambda (,translate-buffer-condition-buffer-sym
;; 				   ,translate-buffer-condition-arg-sym)
;; 			    ,(translate-buffer-condition condition)))
;; 			buffer-match-p-cache))
;; 	   (get-buffer buffer-or-name) arg)
--8<---------------cut here---------------end--------------->8---

In the end, the second implementation using `byte-compile' might be
preferable as it avoids using `eval'.

> Jo=C3=A3o T=C3=A1vora

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 15:27:02 +0000
Resent-Message-ID: <handler.58839.B58839.166731639820598 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166731639820598
          (code B ref 58839); Tue, 01 Nov 2022 15:27:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 15:26:38 +0000
Received: from localhost ([127.0.0.1]:43997 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opt9x-0005M9-92
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:26:37 -0400
Received: from mail-wr1-f49.google.com ([209.85.221.49]:37864)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opt9v-0005Lw-1O
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:26:35 -0400
Received: by mail-wr1-f49.google.com with SMTP id bs21so20653890wrb.4
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 08:26:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=L/ItkN1ALilt2KUAqidRz7Je6n38FFFwzvwNFLVHv1I=;
 b=HSAwaRfPaVf/FnJl9UIj5D4hg+j0Af502pyY9XnLzQxfpgarWNSXxCLboMmrE/u26F
 ckP4J63IgSiFRpZsNF1vkwE6ZmAgmus9xxXaYFOsObqPjgAu+//72EJ7YdopBNjDtJaM
 v8Na1uobYmaTJ99zOPBTMqeyN0jtBbQf50329lYyTDqtX9b88uvdYt7DGc88YSPx2fyC
 sDGPxwjFmY7xN4KUIw7bA9/X5KrVR+7YbEdXVPPCybo1CKtp/UoNf3Tg/jPkPhBgN5KP
 rAOIqJ44QYqGC7gltyZAdrGV4tJGf8l/1/Y8yEMyWEvdC3XydcPUlXJnLYxNAQ9B3QNc
 ffGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=L/ItkN1ALilt2KUAqidRz7Je6n38FFFwzvwNFLVHv1I=;
 b=xUaqAiuhto6e/18Bpo7lVYH28gJLaGymPWrQOdbGHmJtriHhXWxr+SPSc6P+UTlQ7R
 lwF3MZt2qiXQslz5ZxjIJXTuVJvXkDBfdw7b0F1MNiyhcsXqHJ27ciRNyue56EaPYL61
 i34SM58yoHDbe9mtI+bM0sEq8AJZsTfu04VC7dAdvstAwZ8MUglIvTskBXNUxLTStk1l
 DnFaBGXSAgz/4OAoXZkyUUK6UUUn44cDriLiZr+60B3ZEdmDZDRcwFsvYV7D32vKa9nR
 obuJAq/kLdnyfF7VhdSA2vQBaSgeXPKBY8KMt1/QEW7rHRtm2/TGxSg1xfawG7odXqLE
 9VFg==
X-Gm-Message-State: ACrzQf3ZKOZ5pj+FtpORblKx/vmBSz0gHttdwu7ehFRUP4w4vb1ISyVD
 1wHz4+fOKvBcUAzq+DvMiCE=
X-Google-Smtp-Source: AMsMyM5BUFqzcKKLKKtobcNx7EDxI2u0qxc5SNOfdKsQxQ/kx6UkbfB8BrynlN7vCiB2YuTKtsOkJg==
X-Received: by 2002:a5d:650b:0:b0:236:8ead:3ec2 with SMTP id
 x11-20020a5d650b000000b002368ead3ec2mr12176403wru.434.1667316388870; 
 Tue, 01 Nov 2022 08:26:28 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 l13-20020a05600c2ccd00b003a2f2bb72d5sm11942410wmc.45.2022.11.01.08.26.27
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 08:26:28 -0700 (PDT)
Message-ID: <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN>
Date: Tue, 1 Nov 2022 17:26:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN> <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87h6zihq3q.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 13:27, Philip Kaludercic wrote:

> I am biased, but I believe that the language could even find more use in
> project.el, by having `project-buffers' just call `match-buffers' with a
> special `buffer-match-p' predicate.  Here is a sketch of how that could
> look like (I haven't tested it yet):

Sure, but only after we're ready to drop project.el support for Emacs 
older than 29.

> 
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..b55c245368 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -352,15 +352,28 @@ project--remote-file-names
>                   (concat remote-id file))
>                 local-files))))
>   
> +(defun project-includes-buffer-p (buffer dir)
> +  "Return non-nil if the `default-directory' of BUFFER is below DIR."
> +  (file-in-directory-p
> +   (buffer-local-value 'default-directory buffer)
> +   dir))

Not an optimal name, given that we have made project-buffers a generic 
function, so that a custom project backend can define their own 
buffer-listing strategy. And this one implies that matching by 
default-directory is universal.

> +(defcustom project-buffer-conditions

Why not keep considering unknown buffers as part of project by default?

We'll just stop killing them on cleanup.

Otherwise, we'll really need an extensible mechanism for major modes all 
around the ecosystem to tag themselves as project-visible.

> +  '(and (or buffer-file-name
> +            (derived-mode . compilation-mode)
> +            (derived-mode . dired-mode)
> +            (derived-mode . diff-mode)
> +            (derived-mode . comint-mode)
> +            (derived-mode . eshell-mode)
> +            (derived-mode . change-log-mode))
> +        project-includes-buffer-p)
> +  "A buffer predicate for matching what buffers belong to a project."
> +  :type 'buffer-predicate)

Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 15:28:02 +0000
Resent-Message-ID: <handler.58839.B58839.166731643920706 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166731643920706
          (code B ref 58839); Tue, 01 Nov 2022 15:28:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 15:27:19 +0000
Received: from localhost ([127.0.0.1]:44003 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1optAc-0005Nt-Uy
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:27:19 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:38566)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1optAb-0005Nf-2x
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 11:27:18 -0400
Received: by mail-wm1-f45.google.com with SMTP id
 r186-20020a1c44c3000000b003cf4d389c41so10204725wma.3
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 08:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=y6h24vSdJ9I6vPmy/YI0k8cOx4oxhWIDlpNk6aoMkDY=;
 b=VHiLtw3cDMowE3TgWA6mWbxkXazrl0aP7fRosIHIzfZse4pLiNHvP+ORn5SZc+YPNp
 6j7FIFU3JmtfOXJKWHzOH1/ZzwYCbxlPtRzcUh24N3bDOhsq+72t4SZhCoPcWjyeQy1W
 WO+D9XVTRNa+DmFKRkQ9+Or4uTyQnlp5ZalwTgd5VUID/YT0fJwxxySMJs86l7Cn/IFa
 RTerMHvISbYr9RhRVMaCr+ViIbb9G8oo6iZxDA9wOkh4+5RCc0+2oUnUEX8nDjQR2a74
 rva9+bxShunWOiICKtiY0QFQKzTAc40vS6kbvo56O5NFwv+uu0uMbhFbPgSCzNg8dBfK
 iJ1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=y6h24vSdJ9I6vPmy/YI0k8cOx4oxhWIDlpNk6aoMkDY=;
 b=GPrOFSy52Xqe/oPGZJKtxDDspLHQtBw6hb7hCGOE9gwVzgyHGcYSYwZN6zBHvrg5Kr
 czdASVWNLmj/hZbv31UKnJhNjkt5O/6KHHM0OyHAHIl0HuN7FnrRu9MxEvb8qT9FXDIv
 utwXqhMlqnAEldQdqO3/PkL6OA27IDaCLmlyCdOBiKEtrroawCpnwin0tCC5wll602VA
 yB//UyVEoAiEVNWVhnzYppjELAUZ/wOb9Otx4oNRAnmGe3wg7mnUZtrD7m5bLsWCYYuh
 +8uGyASClwhbc3PulN0M3ah0qC31zDvuPzeUUxRuR9cQRNVPHrIh+ciZd6ZSKiq/bSSR
 NNzQ==
X-Gm-Message-State: ACrzQf2kwlb4aBSG7rQFOK/5YGE3cmuZ3G19Wfdz7Ss6FwytLohIWMKM
 OfuwjH304nnbisVLl+hGruE=
X-Google-Smtp-Source: AMsMyM6saVuREJdkMx6ApR8HASbMBtnNHJW242r+dW4400OJYe6Z/1YCHIhzYzwGENxXSbpM0WQDDQ==
X-Received: by 2002:a7b:cb49:0:b0:3b4:b08a:89b with SMTP id
 v9-20020a7bcb49000000b003b4b08a089bmr12185228wmj.173.1667316431391; 
 Tue, 01 Nov 2022 08:27:11 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 az24-20020adfe198000000b0022e035a4e93sm10561908wrb.87.2022.11.01.08.27.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 08:27:11 -0700 (PDT)
Message-ID: <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN>
Date: Tue, 1 Nov 2022 17:27:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
 <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 13:39, João Távora wrote:
> On Tue, Nov 1, 2022 at 11:23 AM Dmitry Gutov <dgutov@HIDDEN 
> <mailto:dgutov@HIDDEN>> wrote:
> 
>     On 01.11.2022 12:59, João Távora wrote:
>      > For me, it looks like match-buffers is reinventing
>      > cl-remove-if-not and match-buffer-p is reinventing ... unary
>     predicate
>      > function of a buffer?
> 
>     And Eglot is reinventing url-http.
> 
> 
> Really? Where? I don't understand how, might it might very well be.
> Can suggest an improvement? I love to kill code, so let 'er rip.

That's an unfair expectation: you didn't suggest an improvement either.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 16:25:02 +0000
Resent-Message-ID: <handler.58839.B58839.16673198502218 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673198502218
          (code B ref 58839); Tue, 01 Nov 2022 16:25:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 16:24:10 +0000
Received: from localhost ([127.0.0.1]:44078 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opu3d-0000Zh-TQ
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 12:24:10 -0400
Received: from mail-oa1-f42.google.com ([209.85.160.42]:36806)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1opu3b-0000ZC-4C
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 12:24:07 -0400
Received: by mail-oa1-f42.google.com with SMTP id
 586e51a60fabf-13bef14ea06so17360076fac.3
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 09:24:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=pOCJ/S/iKeHFhFWyrWBm8EcNIsLJR5g247UStZ+/4nU=;
 b=qiQNTOcKftEdX5XjZ0Gb0QW2yjcpSWkM8Z51pCLaF+vi+w5SmBPgq1iwE4d9T2kNqF
 qx5xX+88VYjmgY+OiNlTI5iz4EqcQTZMiFf/leh6kLGPRjsPDjMcNJLKdNFxO+UzVhtZ
 tJbgGZ3qGR/bT2d1p0dMCnfmb8Q7knNUfIXQukI58x/kGFogueI/pnfEBWqQ+cE1ijwP
 CrjRBo+n7eWlF6SielXo2l8/I+5fuYKgyX+p+ImGnDwuyIhAwh+R2haK3poCqyG1tOdp
 dMu+JAFl99szTf/DB2W4JxKLSuv3hEWgbeRSLoDsU4GCBTqR+CpUcKqMLThUtIKYGYzB
 Dhhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=pOCJ/S/iKeHFhFWyrWBm8EcNIsLJR5g247UStZ+/4nU=;
 b=jQ+lEUR14V6/EGP+CKkXk8UME/gSSy+pDtKZRffZ67NZU0eDMEEsja9mhiwuIXKr8l
 SyMfeaEBvpGl6uqRi53x1CYEXJtU6vuwhc+vY6E0fntonwsP6Po0Ekk5JIDAPsFRBQhd
 sEwoq4shFkOhYY6SZTfdHf3Ym7jCwpYBOfMOESJkFqdUPr02IgqrT17OIEogxTGzhkZR
 9Zag3aJ2ooiQKHNdzuBOndCOMGphnOp7tqGH3pE/fAp2lVx3PcmkVf0g8M9OUlqJQntF
 /7ZDExj9xNNLqjDc4oEBK8bCGhCDLE7bK8qJDIiYy0R/pStBsz9T5xyPDTn4IJpLAv40
 NG+A==
X-Gm-Message-State: ACrzQf1ZvNzB29vkKeiBNpOxT1WMBjfktldXyBK8hm5A8AbU/sLs+p+M
 bCGrIcx7lC5EF0DEW8EeivourzlQDefiJCDPwHI=
X-Google-Smtp-Source: AMsMyM6KF7R6pob0GEyJGtyLCc3khkUZFepSS+zQN+ZUIsp9zEtk4SvydutvvLNMIluZg3+mys3kJrXNsv2v2M60nUk=
X-Received: by 2002:a05:6870:e242:b0:13b:d561:ad02 with SMTP id
 d2-20020a056870e24200b0013bd561ad02mr11813136oac.215.1667319841292; Tue, 01
 Nov 2022 09:24:01 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN> <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
 <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
 <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN>
In-Reply-To: <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 1 Nov 2022 16:23:48 +0000
Message-ID: <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000de061505ec6b2656"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000de061505ec6b2656
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN> wrote:

That's an unfair expectation: you didn't suggest an improvement either.
>

Oh, I'm sorry, and is it fair to inquire about the subliminally compressed:
"and eglot reinvents http-url"? Can you generously grant a few more
sentences as to its meaning and relevance?

Much obliged,
Jo=C3=A3o

>

--000000000000de061505ec6b2656
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>On Tue, Nov 1, 2022, 15:27 Dmitry Gutov &lt;<a href=
=3D"mailto:dgutov@HIDDEN">dgutov@HIDDEN</a>&gt; wrote:</div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"aut=
o"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">
That&#39;s an unfair expectation: you didn&#39;t suggest an improvement eit=
her.<br></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"au=
to">Oh, I&#39;m sorry, and is it fair to inquire about the subliminally com=
pressed: &quot;and eglot reinvents http-url&quot;? Can you generously grant=
 a few more sentences as to its meaning and relevance?</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">Much obliged,</div><div dir=3D"auto">Jo=C3=
=A3o</div><div dir=3D"auto"><div class=3D"gmail_quote" dir=3D"auto"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000de061505ec6b2656--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 18:45:02 +0000
Resent-Message-ID: <handler.58839.B58839.166732829724626 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166732829724626
          (code B ref 58839); Tue, 01 Nov 2022 18:45:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 18:44:57 +0000
Received: from localhost ([127.0.0.1]:44240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opwFs-0006P7-Ud
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 14:44:57 -0400
Received: from mout01.posteo.de ([185.67.36.65]:42093)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opwFq-0006Ot-OD
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 14:44:55 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id CD692240026
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 19:44:46 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667328288; bh=mEhE/62hKYoX/8kmrd60brjjblsL3yWmXLZnu4rCmac=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=PZBVW1udyIv9n3gnyuyGxU6xi2Eqnt93MgTrzPpSrO0ObpbPt3MMoAxanSAPIjDAF
 hU8rr9Y+Fquyu6VRHxOk7o4/cKXWrJIg1VL+WrbF5+6yGtHSMwA1hdOVwwG+r+n257
 8xZJfHryfmlznmurLE1qMDQnyJCUlu6nOJIbUxxvyB9ePVhYhpptirLrpv8vPLYufl
 T2jAxuy3DDj1MTTyx89dGZePRbnxcDMfp3y1uiZxb7UZgWB0GdUjf65cM12YKG5w//
 OvhemhpiF3NKoH22+Lld/bOgGp3ajJszBaLJSlHL0kYb7AE5smwFp87XWd5shmyxkw
 C3baw0Tuv1sUQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N1zTT2dnxz6tmf;
 Tue,  1 Nov 2022 19:44:45 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Nov 2022 17:26:26 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 18:44:44 +0000
Message-ID: <87bkpqecpv.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 01.11.2022 13:27, Philip Kaludercic wrote:
>
>> I am biased, but I believe that the language could even find more use in
>> project.el, by having `project-buffers' just call `match-buffers' with a
>> special `buffer-match-p' predicate.  Here is a sketch of how that could
>> look like (I haven't tested it yet):
>
> Sure, but only after we're ready to drop project.el support for Emacs
> older than 29.

The functionality can be provided using Compat[0], as is already done for a
few core package that are distributed on GNU ELPA (ERC, python-mode).

[0] https://elpa.gnu.org/packages/compat.html

>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>> index ac278edd40..b55c245368 100644
>> --- a/lisp/progmodes/project.el
>> +++ b/lisp/progmodes/project.el
>> @@ -352,15 +352,28 @@ project--remote-file-names
>>                   (concat remote-id file))
>>                 local-files))))
>>   +(defun project-includes-buffer-p (buffer dir)
>> +  "Return non-nil if the `default-directory' of BUFFER is below DIR."
>> +  (file-in-directory-p
>> +   (buffer-local-value 'default-directory buffer)
>> +   dir))
>
> Not an optimal name, given that we have made project-buffers a generic
> function, so that a custom project backend can define their own
> buffer-listing strategy. And this one implies that matching by
> default-directory is universal.

Right, as I said this is just a sketch.

But as the diff showed, I think any more specific implementation ought
to extend the generic implementation, by using `cl-call-next-method'
instead of `buffer-list'.

>> +(defcustom project-buffer-conditions
>
> Why not keep considering unknown buffers as part of project by default?

What are "unknown buffers"?

> We'll just stop killing them on cleanup.
>
> Otherwise, we'll really need an extensible mechanism for major modes
> all around the ecosystem to tag themselves as project-visible.

Wouldn't a simple buffer local variable suffice?

>> +  '(and (or buffer-file-name
>> +            (derived-mode . compilation-mode)
>> +            (derived-mode . dired-mode)
>> +            (derived-mode . diff-mode)
>> +            (derived-mode . comint-mode)
>> +            (derived-mode . eshell-mode)
>> +            (derived-mode . change-log-mode))
>> +        project-includes-buffer-p)
>> +  "A buffer predicate for matching what buffers belong to a project."
>> +  :type 'buffer-predicate)
>
> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.

This is my point, I think Jo=C3=A3o is right that this ought to be an
enumeration of major modes that are related to projects.  As this is a
user option, users can add or remove whatever modes they disagree on and
that behaviour would ideally be propagated to all projects.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 19:51:01 +0000
Resent-Message-ID: <handler.58839.B58839.166733223230990 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166733223230990
          (code B ref 58839); Tue, 01 Nov 2022 19:51:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 19:50:32 +0000
Received: from localhost ([127.0.0.1]:44273 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opxHL-00083m-F6
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 15:50:31 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:34437)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opxHF-00083O-TS
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 15:50:30 -0400
Received: by mail-wr1-f48.google.com with SMTP id k8so21616106wrh.1
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 12:50:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=WZNy+6SKezqjjP3kFxt7Eg0TJCKi7bAot/hk0eNUJgw=;
 b=LMHiI4Kvxlf/UFWKpVkDqJ9/V5PzNnSAVatwumMzxVCSVpQsib8TbdM3yFI0MmhRAl
 WC6p2wOSrmdDImb5L2IZZ6G3AHHKc3zzFuNNmKu87d7tZFXNOfDji5w1QeuEJ3vuLi1+
 riAmhfunyUykhPRPLKxkyDDivDkyLgHQzKTFWlV3s6DeZJLcivti1g7gPZ+E2ODNJXrX
 EaN4MmvbfA++wbyVz4AFWopy+0QQQm6lJRk3I9XMyam9BhQB6cNNO4F18pVha31Nt74W
 oCz9Ytih4aOzIQGvO8dnhPV+fHwu5eZoExjPCBp4lHzxWSybGTQlB0ZnaYVip2IWXKrJ
 cT+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=WZNy+6SKezqjjP3kFxt7Eg0TJCKi7bAot/hk0eNUJgw=;
 b=1kvshk5UjCCRIi4Kuf+WBM5VwNgNkSHaKY33rAqse93Q5xQG2+4WWbMagxUy7/Nw5I
 igf8pdY+27QMAuIG2xRtWXvox0aFO+xxP3Y7VBWVZFTlPZlLp6wVaK+8SSsghrqqhLQ+
 gjdr0XPsYhEQTpeHtJIIKCY0xzymo08fLaujoWO8rIX/MYkwsRRcNBcg0kw2fb6xQR54
 RcOq4LK5LMcbiidN9qD0vD951L1OIcLBZg0LjZloWyJpj/v3K+IDJULompgmj1AkQRby
 O1YpmP6OjgRBQCDvQZ+PjP/vO/IezKiFbkL93a5lnvAjmPP1NbLKIXzR8Xtw35hkO9Mn
 E1Gw==
X-Gm-Message-State: ACrzQf1VRDanatKfGvENMjGXIqBbfhpwso3Mf6uziuGJoU6sqzdiatOz
 tvLxvwjimHQmSd0/UsjfPSw=
X-Google-Smtp-Source: AMsMyM7jCp0//Qenh2x8D8ykbdsSqMoQu6/Oazg5xC4Q1SJFcG2vdBM7e+riZs2Faz1oKr4jJIzAtQ==
X-Received: by 2002:adf:e785:0:b0:236:5998:67a0 with SMTP id
 n5-20020adfe785000000b00236599867a0mr12895099wrm.414.1667332219791; 
 Tue, 01 Nov 2022 12:50:19 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 h9-20020a05600c414900b003b49ab8ff53sm11361322wmm.8.2022.11.01.12.50.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 12:50:19 -0700 (PDT)
Message-ID: <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN>
Date: Tue, 1 Nov 2022 21:50:17 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN>
 <87bkpqecpv.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87bkpqecpv.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 20:44, Philip Kaludercic wrote:

>> Sure, but only after we're ready to drop project.el support for Emacs
>> older than 29.
> 
> The functionality can be provided using Compat[0], as is already done for a
> few core package that are distributed on GNU ELPA (ERC, python-mode).
> 
> [0] https://elpa.gnu.org/packages/compat.html

I suppose if the performance improvement is shown to be significant, we 
could. I'm a little hesitant to add a new dependency: I haven't been 
following this package, not sure how stable it is.

>>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>>> index ac278edd40..b55c245368 100644
>>> --- a/lisp/progmodes/project.el
>>> +++ b/lisp/progmodes/project.el
>>> @@ -352,15 +352,28 @@ project--remote-file-names
>>>                    (concat remote-id file))
>>>                  local-files))))
>>>    +(defun project-includes-buffer-p (buffer dir)
>>> +  "Return non-nil if the `default-directory' of BUFFER is below DIR."
>>> +  (file-in-directory-p
>>> +   (buffer-local-value 'default-directory buffer)
>>> +   dir))
>>
>> Not an optimal name, given that we have made project-buffers a generic
>> function, so that a custom project backend can define their own
>> buffer-listing strategy. And this one implies that matching by
>> default-directory is universal.
> 
> Right, as I said this is just a sketch.
> 
> But as the diff showed, I think any more specific implementation ought
> to extend the generic implementation, by using `cl-call-next-method'
> instead of `buffer-list'.

Or apply the same filters some other way, I guess. But yes, the 
cl-call-next-method call makes sense in your patch.

>>> +(defcustom project-buffer-conditions
>>
>> Why not keep considering unknown buffers as part of project by default?
> 
> What are "unknown buffers"?

Take whatever special buffer belonging to jsonrpc that was the cause of 
this bug report. It can still be useful to be able switch to it using 
project-switch-to-buffer (if, say, one was looking for the specific 
buffer to try to debug a problem with some Eglot feature in their 
project). We don't want to kill it with the rest of the buffers, 
however. Apparently.

>> We'll just stop killing them on cleanup.
>>
>> Otherwise, we'll really need an extensible mechanism for major modes
>> all around the ecosystem to tag themselves as project-visible.
> 
> Wouldn't a simple buffer local variable suffice?

I guess it will. Only with a more meaningful name than 'project-owned' 
and some proper documentation.

>>> +  '(and (or buffer-file-name
>>> +            (derived-mode . compilation-mode)
>>> +            (derived-mode . dired-mode)
>>> +            (derived-mode . diff-mode)
>>> +            (derived-mode . comint-mode)
>>> +            (derived-mode . eshell-mode)
>>> +            (derived-mode . change-log-mode))
>>> +        project-includes-buffer-p)
>>> +  "A buffer predicate for matching what buffers belong to a project."
>>> +  :type 'buffer-predicate)
>>
>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.
> 
> This is my point, I think João is right that this ought to be an
> enumeration of major modes that are related to projects.  As this is a
> user option, users can add or remove whatever modes they disagree on and
> that behaviour would ideally be propagated to all projects.

Being to customize it is a good thing.

But either we provide a reasonably complete list which we regularly 
update, or we say its completeness is up to the user.

And in the latter case, as soon as the user customizes the var, they 
stop getting any updates we might make to it later (to the default value).

And if we take the strict "whitelist" approach, I'm pretty sure the list 
will require updating in the future, it will never be complete.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 20:12:01 +0000
Resent-Message-ID: <handler.58839.B58839.1667333473403 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.1667333473403
          (code B ref 58839); Tue, 01 Nov 2022 20:12:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 20:11:13 +0000
Received: from localhost ([127.0.0.1]:44287 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opxbM-00006P-G6
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 16:11:13 -0400
Received: from mout02.posteo.de ([185.67.36.66]:39145)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1opxbK-00006A-AE
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 16:11:11 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 29A99240106
 for <58839 <at> debbugs.gnu.org>; Tue,  1 Nov 2022 21:11:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667333464; bh=TJqedmjYJtsV+82B5OQs0rL8oWfXRj6ww3vnHrPpjIY=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=qL0k1x5eaw62ZCYuOsy/42e/2yNBeuK2NlQZRdcoG/IvxyyHpOHFr9RrWvRNjBfw4
 FQbmPq6uammj6po7Tgg/ocVwgLUpimLMB7efuHmLCyPbZn/wDhbXFz40/vbYvFXe5i
 HcdbdFjOrx36LV6jfaFx1POs9JbjtDH1wbpzt8Kk12LIZHlVzIL4B1Tu8XxRq8CchR
 1EJEojtct40zC6sRKibsP85zF7Cl9lrXAhPbHFmv42WGuGxYT96r328KHFtGuLt/DF
 fUH8cBmGgLo9MblGAzBJDVV1Tk74yhnMoUr5T0EZKO88R8ZaE/K55vMOhfdnjQWG3u
 JxRU36dP794kw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N21P22vHgz9rxV;
 Tue,  1 Nov 2022 21:11:02 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Nov 2022 21:50:17 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN>
 <87bkpqecpv.fsf@HIDDEN>
 <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Tue, 01 Nov 2022 20:10:55 +0000
Message-ID: <87wn8ecu5s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 01.11.2022 20:44, Philip Kaludercic wrote:
>
>>> Sure, but only after we're ready to drop project.el support for Emacs
>>> older than 29.
>> The functionality can be provided using Compat[0], as is already
>> done for a
>> few core package that are distributed on GNU ELPA (ERC, python-mode).
>> [0] https://elpa.gnu.org/packages/compat.html
>
> I suppose if the performance improvement is shown to be significant,
> we could. I'm a little hesitant to add a new dependency: I haven't
> been following this package, not sure how stable it is.

I am the maintainer, so I am biased, but stability is a high priority,
which is why the library is extensively tested, where-ever possible:

https://git.sr.ht/~pkal/compat/tree/master/item/compat-tests.el

Fun fact, I came up with the idea for this library when working on
project-kill-buffer over two years ago, as a means of extracting the
language out of project.el, as has been done with buffer-match-p.

>>>> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
>>>> index ac278edd40..b55c245368 100644
>>>> --- a/lisp/progmodes/project.el
>>>> +++ b/lisp/progmodes/project.el
>>>> @@ -352,15 +352,28 @@ project--remote-file-names
>>>>                    (concat remote-id file))
>>>>                  local-files))))
>>>>    +(defun project-includes-buffer-p (buffer dir)
>>>> +  "Return non-nil if the `default-directory' of BUFFER is below DIR."
>>>> +  (file-in-directory-p
>>>> +   (buffer-local-value 'default-directory buffer)
>>>> +   dir))
>>>
>>> Not an optimal name, given that we have made project-buffers a generic
>>> function, so that a custom project backend can define their own
>>> buffer-listing strategy. And this one implies that matching by
>>> default-directory is universal.
>> Right, as I said this is just a sketch.
>> But as the diff showed, I think any more specific implementation
>> ought
>> to extend the generic implementation, by using `cl-call-next-method'
>> instead of `buffer-list'.
>
> Or apply the same filters some other way, I guess. But yes, the
> cl-call-next-method call makes sense in your patch.
>
>>>> +(defcustom project-buffer-conditions
>>>
>>> Why not keep considering unknown buffers as part of project by default?
>> What are "unknown buffers"?
>
> Take whatever special buffer belonging to jsonrpc that was the cause
> of this bug report. It can still be useful to be able switch to it
> using project-switch-to-buffer (if, say, one was looking for the
> specific buffer to try to debug a problem with some Eglot feature in
> their project). We don't want to kill it with the rest of the buffers,
> however. Apparently.

Ah, right.  I have to admit that I rarely use project-switch-to-buffer,
so I forgot about that.  In that case, project-kill-buffer-conditions
cannot be deprecated, as these are just a subset of the project buffers.

>>> We'll just stop killing them on cleanup.
>>>
>>> Otherwise, we'll really need an extensible mechanism for major modes
>>> all around the ecosystem to tag themselves as project-visible.
>> Wouldn't a simple buffer local variable suffice?
>
> I guess it will. Only with a more meaningful name than 'project-owned'
> and some proper documentation.

Right.  Does it have to have a "project-" prefix, or would
"belongs-to-project" (hypothetically) be fine too?

>>>> +  '(and (or buffer-file-name
>>>> +            (derived-mode . compilation-mode)
>>>> +            (derived-mode . dired-mode)
>>>> +            (derived-mode . diff-mode)
>>>> +            (derived-mode . comint-mode)
>>>> +            (derived-mode . eshell-mode)
>>>> +            (derived-mode . change-log-mode))
>>>> +        project-includes-buffer-p)
>>>> +  "A buffer predicate for matching what buffers belong to a project."
>>>> +  :type 'buffer-predicate)
>>>
>>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.
>> This is my point, I think Jo=C3=A3o is right that this ought to be an
>> enumeration of major modes that are related to projects.  As this is a
>> user option, users can add or remove whatever modes they disagree on and
>> that behaviour would ideally be propagated to all projects.
>
> Being to customize it is a good thing.
>
> But either we provide a reasonably complete list which we regularly
> update, or we say its completeness is up to the user.

I would want to argue that the complete list is preferable.

> And in the latter case, as soon as the user customizes the var, they
> stop getting any updates we might make to it later (to the default
> value).
>
> And if we take the strict "whitelist" approach, I'm pretty sure the
> list will require updating in the future, it will never be complete.

Which is fair, but which can also be combined with=20

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 22:24:01 +0000
Resent-Message-ID: <handler.58839.B58839.166734140121568 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166734140121568
          (code B ref 58839); Tue, 01 Nov 2022 22:24:01 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:23:21 +0000
Received: from localhost ([127.0.0.1]:44381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opzfE-0005bn-MQ
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:23:20 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:46077)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opzfC-0005ba-OQ
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:23:19 -0400
Received: by mail-wm1-f52.google.com with SMTP id
 l16-20020a05600c4f1000b003c6c0d2a445so189206wmq.4
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=tJKeiNE9fX7ZtS3ybHLkEuWa3MdlhUOGaP4Qxe0an/o=;
 b=N73NhAxMAfvcxTs4jqguWpPlbBS5Q5N0raNzuUt1Vjsv+zMdcEzo4DHm3Plgv/Ua06
 /bEElq+g78zV4GM3Wffwg+pYFhYj7zNJgkk7P/ep206x5eTo++sQ8Ca2JHCmyGNmHlzu
 ovg5KO3V19x61xcCL+TE0P4hBrROMN8cDW8jgxEbIPSQ+8JxhBLZzT6mpt+7/hCOqetA
 CpE9yHtE7Vfn5CME22ks7MixMTfYY3vB0V3u8h9cFZxZ4MJeT13YRa9R1/m90F4DqjKl
 BuFDdWUKfFDqRBmZ2XKRv6wN48isZeivklCtr0bhTbsJRr+dV7P02aqhteVtT2mCLRoS
 Ka3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=tJKeiNE9fX7ZtS3ybHLkEuWa3MdlhUOGaP4Qxe0an/o=;
 b=S3HdgKe0QKlr5QPPrloY8Dzh9JLHaz20q08OaEneKJwky1hZgTq0njrr23emXQTV9J
 Ng3vzg58biwlBkdxGkdKNrqbwpwuyRgBAIrrAdJOtLwfVCt8YFgnye1Nyzc8/4Xylmd8
 dVEz26i6M2H/rMVsmHCLEjevbPYnyxs8C5lwfVO5lgKhWYAtdznChgj8Z3QZ8BNsfLk0
 P/5f1yDLojn1KItOVgMdfv7njLnxrgGB5SWlNqaE8Nc0G9bYlKWsCT0xzXnBkR58dC0W
 hpvnBx6QV8aRjsnFe+bgfR0nH0k9ZebAPhKiQIftiqHMZ/aTLaA846WC6Eax/W8NiEMi
 /kmg==
X-Gm-Message-State: ACrzQf2qlbHu6vG156BDi6/shfoOL7cO2AW/aItJwbUcx8uvm6U7u6ve
 Az5W2Ad1EzpL4DNSQ83hcw4=
X-Google-Smtp-Source: AMsMyM4zHb7Nafy2wd1hAHEECVEMfKkUi4fwzfVlDt+z7d+SkCaXFeulUKpYgg+o0zorQrd94YZy5Q==
X-Received: by 2002:a7b:c3c4:0:b0:3c4:785a:36d7 with SMTP id
 t4-20020a7bc3c4000000b003c4785a36d7mr23830593wmj.138.1667341392965; 
 Tue, 01 Nov 2022 15:23:12 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 u13-20020a056000038d00b00236c1f2cecesm10579411wrf.81.2022.11.01.15.23.12
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 15:23:12 -0700 (PDT)
Message-ID: <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
Date: Wed, 2 Nov 2022 00:23:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 13:36, João Távora wrote:

>  > what you are doing is pressuring all other participants into your POV by
>  > means of an insult. That usually works better if the offending code was
>  > written by somebody who already left (the project/the discussion/the
>  > company/etc), or is a little younger.
> 
> You are attributing ill-intent to me from a moral high-ground you can't 
> really
> claim.  I had no idea as to the authorship, so I can't have been 
> engaging in those
> perfidious tactics.  But do I apologize for the word "abomination". If 
> it helps
> I'll show you round to plenty such things written by myself in the past.

Not at all, trying to get people to agree to your own (obviously correct 
and beneficial) POV is not ill intent.

The means are not great, though.

> I've explained to Philip objective reasons why I think evaluated
> mini-languages are almost always inferior to a decent Lisp such as Elisp.
> You could perfectly reasonably deprecate these two variables.

Not where this discussion is going, is it?

>  > I'm fairly sure that the solution I offered would be easy enough
>  > implement, to actually protect the vulnerable buffer.
>  > I suppose we are not doing that, however.
> 
> You sketched an untested code-less idea and I explained how flawed it was.

Back atcha. Modulo "code-less".

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 22:26:02 +0000
Resent-Message-ID: <handler.58839.B58839.166734150621747 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166734150621747
          (code B ref 58839); Tue, 01 Nov 2022 22:26:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:25:06 +0000
Received: from localhost ([127.0.0.1]:44386 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opzgw-0005eh-6J
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:25:06 -0400
Received: from mail-wr1-f45.google.com ([209.85.221.45]:41860)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opzgv-0005e8-25
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:25:05 -0400
Received: by mail-wr1-f45.google.com with SMTP id w14so22026101wru.8
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:25:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=Gngs3FhLxI7mtplV+oX/20a8n2l7ocT97UN73yjEG/g=;
 b=YkUjXbWwg1GYm3UIFt3z3upwXmly8kWwzb7XfvE/Cv1Il+Lk0owTUTqeoPYwPbs+A6
 nAEx0xQ3GTf8oxbtxyIKThTI2BoG3bbUxRqujrdLj0tjXnuxUsG8z1SReshwlUEHvkbv
 uOnjRv2BwYNVmGTO7HtmmXu/QIv5A5yC3rpPjP/iphPk6wsljWfrJA6pu7dvNRXU2OUW
 f3NuDNUxGJA7Gdf6kHEI/kcZ01pLYmhkDOx3dzbVvRIWj0vUSK0vD8TgjWaFZC9TW+az
 DMbms5EdQGLzIJrUrvsDkLO4AahZ5msvE7Es4QKEFReTZUa6wt8+uI4Beq8oE1cWTg+i
 YIdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=Gngs3FhLxI7mtplV+oX/20a8n2l7ocT97UN73yjEG/g=;
 b=OKwlt9oNTRx1j/llur9SHN7u9uH0YSLBF07JbBZ9cnlpyphisWR6UMJ1hHk2WFD1qm
 5XvOiY88eWf3/CKGG9GMcQqe7BJ24PghGhanYG2PBK0bnfeBq0DryhZb1eDv6487KEcY
 c/kigvV6QNdpOm/yjyZKaUPp3mLfX4oLMYlk015y0bzw8mClvXqhttu2gY38BuynW6yd
 YclfHtMTWqEMFAJF4lAadS1bRvsJ/0jHc4upgNTj3aJzVdHRu4t9pxRE66Y9z60hA37V
 qgRGIvwYu00f+vY1oE91OzNwplvKCwlJ9ieq4EzcFywosnBLFotlPocdwfQpuRPn+EKD
 7ohQ==
X-Gm-Message-State: ACrzQf05mP8kWnkhTbfQOl/L+LArmXm1+gVwuE0lQwdM+FBqcl6TNEzv
 eaenkuK/2myiOw7T/fuOl+I=
X-Google-Smtp-Source: AMsMyM77wsWzgAFP7tuZhGPZhsZZS4VMGCUnYU/f90wwlsWIzp1/aTUdZJiVMGv4Ti3CYEkEZZmajQ==
X-Received: by 2002:adf:cd09:0:b0:236:659a:6902 with SMTP id
 w9-20020adfcd09000000b00236659a6902mr13420592wrm.574.1667341499338; 
 Tue, 01 Nov 2022 15:24:59 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 e12-20020adfe38c000000b0023655e51c14sm11087214wrm.32.2022.11.01.15.24.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 15:24:59 -0700 (PDT)
Message-ID: <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN>
Date: Wed, 2 Nov 2022 00:24:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN> <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN> <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
 <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
 <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN>
 <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 18:23, João Távora wrote:
> On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN 
> <mailto:dgutov@HIDDEN>> wrote:
> 
>     That's an unfair expectation: you didn't suggest an improvement either.
> 
> 
> Oh, I'm sorry, and is it fair to inquire about the subliminally 
> compressed: "and eglot reinvents http-url"? Can you generously grant a 
> few more sentences as to its meaning and relevance?

Your compressed the meaning and usefulness of a feature to something 
trivial (and only semi-relevant), and so did I.

I thought that would be obvious.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Nov 2022 22:41:02 +0000
Resent-Message-ID: <handler.58839.B58839.166734244323275 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166734244323275
          (code B ref 58839); Tue, 01 Nov 2022 22:41:02 +0000
Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 22:40:43 +0000
Received: from localhost ([127.0.0.1]:44411 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1opzw2-00063L-KK
	for submit <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:40:43 -0400
Received: from mail-wm1-f51.google.com ([209.85.128.51]:39807)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1opzvz-000637-Ju
 for 58839 <at> debbugs.gnu.org; Tue, 01 Nov 2022 18:40:40 -0400
Received: by mail-wm1-f51.google.com with SMTP id
 i5-20020a1c3b05000000b003cf47dcd316so209115wma.4
 for <58839 <at> debbugs.gnu.org>; Tue, 01 Nov 2022 15:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=hLYuRGGCo12V3KLBoBAJ+2BiaYkKMr30E+AzaZd+UoI=;
 b=ligsoTQh6lKjDBzc/gmB2iQJCSQ4BSnd55UyhbY8xB9+EXpFxXY5g1gvge/dHEyq5/
 sWFk20imJGkfly3L28JX/LmsNwRnjHz6XPr3M18GJeRDIdUvaUKnvDymojHFmCENHgWP
 AbV1XqfW8h4GlOBMxeAzIpTgP4OWYNjmT3SeqP9fhle6oFlKwSSoY3YmuWcFjqc423QO
 cGphsRxYl8i3KtPvsV9WQNZwpfsdW+06Z54zITjeOU7w+vgrGdtu0BY1Ep9mfhRKmm0d
 iR771SywximHsiNGrJbiMxotA5vOeDQTRqoYqgTo32DZ44SOK4Uy8INM6zroiUaD/uq2
 w8nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=hLYuRGGCo12V3KLBoBAJ+2BiaYkKMr30E+AzaZd+UoI=;
 b=y+hXWi+522Ft2etyl6U9cxS/Lpky6tEL7PpD2fv5xRwk5r6YKppqeEkrBvUmQMpmg0
 BNsIHeeiUjaZM5O9Jwo+7EpHsmNmNOAk9hxkZk41foNP1uB2mSTOPt7gUCWqKnrxpurT
 86RBIhxtkw1KU/b7/Mp0MI6Jp1TFCiNQVAXCIj6EAoR/71LnzPcCCByyudLVmauuqJd4
 7KBep9VXbKlQ3WDhZa49ESxWieHC3uUPJKWVoldHNdD99yGFWpG1GLVqN9Vs388WHPbr
 nytXs/J1AwSm8VoNlGTIARtw4CdzM2pUtHqxvZv8YapQdihUq2bmN4bExCa/wDUwUurL
 Md6Q==
X-Gm-Message-State: ACrzQf1MT0DmutqSMlCBlf4BgE+mqssiTELHFV/t69jjt37GDglQF6nT
 gkU4u7aM6WR2Fwp0QF8hTHk=
X-Google-Smtp-Source: AMsMyM4qbjDPCE6wvHhAV/RrFIOCJBRY2BUfJhDsTX17XDXssUJZytivJboJj/x7l2AG8/AdHQeedg==
X-Received: by 2002:a05:600c:3b88:b0:3c6:cef8:8465 with SMTP id
 n8-20020a05600c3b8800b003c6cef88465mr23287139wms.64.1667342433556; 
 Tue, 01 Nov 2022 15:40:33 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 p125-20020a1c2983000000b003c21ba7d7d6sm22647wmp.44.2022.11.01.15.40.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Nov 2022 15:40:33 -0700 (PDT)
Message-ID: <0ff05982-860b-7338-8bb6-50ac09cc376a@HIDDEN>
Date: Wed, 2 Nov 2022 00:40:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN> <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN> <e1641d7a-df42-326e-d843-ecb28f427472@HIDDEN>
 <87bkpqecpv.fsf@HIDDEN> <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@HIDDEN>
 <87wn8ecu5s.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <87wn8ecu5s.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 22:10, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> On 01.11.2022 20:44, Philip Kaludercic wrote:
>>
>>>> Sure, but only after we're ready to drop project.el support for Emacs
>>>> older than 29.
>>> The functionality can be provided using Compat[0], as is already
>>> done for a
>>> few core package that are distributed on GNU ELPA (ERC, python-mode).
>>> [0] https://elpa.gnu.org/packages/compat.html
>>
>> I suppose if the performance improvement is shown to be significant,
>> we could. I'm a little hesitant to add a new dependency: I haven't
>> been following this package, not sure how stable it is.
> 
> I am the maintainer, so I am biased, but stability is a high priority,
> which is why the library is extensively tested, where-ever possible:
> 
> https://git.sr.ht/~pkal/compat/tree/master/item/compat-tests.el
> 
> Fun fact, I came up with the idea for this library when working on
> project-kill-buffer over two years ago, as a means of extracting the
> language out of project.el, as has been done with buffer-match-p.

Oh ok. I suppose I don't mind, then.

It would be nice to have some benchmark, however, at what number of 
buffers the optimization brings some perceptible difference (like, the 
delay is reduced by 50ms at least).

>>>>> +(defcustom project-buffer-conditions
>>>>
>>>> Why not keep considering unknown buffers as part of project by default?
>>> What are "unknown buffers"?
>>
>> Take whatever special buffer belonging to jsonrpc that was the cause
>> of this bug report. It can still be useful to be able switch to it
>> using project-switch-to-buffer (if, say, one was looking for the
>> specific buffer to try to debug a problem with some Eglot feature in
>> their project). We don't want to kill it with the rest of the buffers,
>> however. Apparently.
> 
> Ah, right.  I have to admit that I rarely use project-switch-to-buffer,
> so I forgot about that.  In that case, project-kill-buffer-conditions
> cannot be deprecated, as these are just a subset of the project buffers.

There can be other uses for 'project-buffers' as well, like the 
reimplementation of projectile-ibuffer in another bug report.

>>>> We'll just stop killing them on cleanup.
>>>>
>>>> Otherwise, we'll really need an extensible mechanism for major modes
>>>> all around the ecosystem to tag themselves as project-visible.
>>> Wouldn't a simple buffer local variable suffice?
>>
>> I guess it will. Only with a more meaningful name than 'project-owned'
>> and some proper documentation.
> 
> Right.  Does it have to have a "project-" prefix, or would
> "belongs-to-project" (hypothetically) be fine too?

Let's keep to the module-prefixing strategy. I think it makes sense, and 
the rest of the symbols in project.el are named that way.

>>>>> +  '(and (or buffer-file-name
>>>>> +            (derived-mode . compilation-mode)
>>>>> +            (derived-mode . dired-mode)
>>>>> +            (derived-mode . diff-mode)
>>>>> +            (derived-mode . comint-mode)
>>>>> +            (derived-mode . eshell-mode)
>>>>> +            (derived-mode . change-log-mode))
>>>>> +        project-includes-buffer-p)
>>>>> +  "A buffer predicate for matching what buffers belong to a project."
>>>>> +  :type 'buffer-predicate)
>>>>
>>>> Let's not forget Xref, Occur, VC-Dir, Log-View. Maybe some others.
>>> This is my point, I think João is right that this ought to be an
>>> enumeration of major modes that are related to projects.  As this is a
>>> user option, users can add or remove whatever modes they disagree on and
>>> that behaviour would ideally be propagated to all projects.
>>
>> Being to customize it is a good thing.
>>
>> But either we provide a reasonably complete list which we regularly
>> update, or we say its completeness is up to the user.
> 
> I would want to argue that the complete list is preferable.

Then we'll have to keep updating it from time to time.

>> And in the latter case, as soon as the user customizes the var, they
>> stop getting any updates we might make to it later (to the default
>> value).
>>
>> And if we take the strict "whitelist" approach, I'm pretty sure the
>> list will require updating in the future, it will never be complete.
> 
> Which is fair, but which can also be combined with

(unfinished)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 07:19:02 +0000
Resent-Message-ID: <handler.58839.B58839.16673734842696 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673734842696
          (code B ref 58839); Wed, 02 Nov 2022 07:19:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:18:04 +0000
Received: from localhost ([127.0.0.1]:44795 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq80i-0000hP-BO
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:18:04 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:44584)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq80f-0000gu-AX
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:18:02 -0400
Received: by mail-wm1-f49.google.com with SMTP id
 bg9-20020a05600c3c8900b003bf249616b0so650696wmb.3
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:18:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:message-id:date:user-agent:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=hU+5R90vBsr/0Crp/BwTf7LXS34HJ3Ok1fW9zRfb5BY=;
 b=JQXquJfCc0e/8qLYbCEdiqbiaCDwmjastWMJF0W6djQFXbNl+7sUacvo6x/VJ6IQTe
 Xq7+2jgGj+wIJxC9GgpTuh/BNNKz3Fd/wVNDaGFnBq2fO4usL58DZ7uVkf0tVHpTNkOe
 NS4vgnl1vXUmJ0h3ggi79TZVMF1CXr7vG5syB/HhBGejdqg16DRqsyoJg5fpKLom30CC
 QQDL1jy6Tsnp3T4//v1cEc+4KmE3k8mVieM5rUCsgHGLghJPQkj5H8z/lPhDBlcD7KVd
 lt4jA2OC/xptcZ0q+zRwA6LvGsMkjvlOpmrklq++qvxaAuyCEhQTdComz+pPb5ohZz28
 VPSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:message-id:date:user-agent:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=hU+5R90vBsr/0Crp/BwTf7LXS34HJ3Ok1fW9zRfb5BY=;
 b=NobjfKNrw1ZD3ExQrYomLYO3WxGLOJZD8F4myoTrR92DwqhVjrGfwB3dP0X8QQvb5U
 m6mGYqmrCHDdvZojdqywuu4NhU0wG/i321eBIFcILSYHNVfbFJMyJ1Iz29tZ8Nr+qWC0
 PyAiIaluZeMG7gPfu3a7RbHqCXJemVS/lmKwJA7aK9caGNMo/sYR3m4uE50BrViptBz8
 ve7edNT8vebM/kJU0A1TF35+lyq4W+egog05tSjpChgR0YaqdgEL/CpcXeqJDD8B4FVn
 5OlyNnLZfuWqrpz7fJqzBapTpZ1jJmNkGCR5nn1zqq8eEQ9B6ckftuHI0w5DTu7W2wkk
 XY1w==
X-Gm-Message-State: ACrzQf0oCwRrQpoenAsTb/1BB+RecGigqolDQxWK5/gKI2obUAu9yFPt
 JwU0jhErwGRsS5J241AwSgAR0G4wnZo=
X-Google-Smtp-Source: AMsMyM6aowOpSNj9yAGA0DjwgCE6jkHHqA2ZuNOAe3ET+RjtsJmYfLJTRyFfeY/uUYLK23XlG35M6w==
X-Received: by 2002:a05:600c:1614:b0:3cf:816e:4a69 with SMTP id
 m20-20020a05600c161400b003cf816e4a69mr3941993wmn.33.1667373474964; 
 Wed, 02 Nov 2022 00:17:54 -0700 (PDT)
Received: from krug ([87.196.73.80]) by smtp.gmail.com with ESMTPSA id
 v7-20020a05600c444700b003c70191f267sm1051916wmn.39.2022.11.02.00.17.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 00:17:54 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <874jvig2rp.fsf@HIDDEN> (Philip Kaludercic's message of "Tue, 
 01 Nov 2022 14:36:42 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Wed, 02 Nov 2022 07:19:05 +0000
Message-ID: <87edulu8ly.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

>> Yes, do that, but use byte-compile instead, not eval.
> I have tried both, and it doesn't appear to be a particular advantage
> one way or another.  That being said, this approach is *a lot* faster,
> to the point that I first assumed it was broken:

Yes, this approach is always going to be much faster than the "naive"
approach.  Now I've taken your code as a starting point, simplified it,
and I get a reasonable/typical 3.5x speedup when I use a
byte-compilation strategy, so one of us isn't measuring

```elisp
(defun translate-buffer-condition-1 (condition)
  (pcase-exhaustive condition
    ((or 't 'nil)
     condition)
    ((pred stringp)
     `(string-match-p ,condition (buffer-name buffer)))
    ((pred functionp)
     `(,condition buffer))
    (`(major-mode . ,mode)
     `(eq (buffer-local-value 'major-mode buffer)
	  ',mode))
    (`(derived-mode . ,mode)
     `(provided-mode-derived-p
       (buffer-local-value 'major-mode buffer)
       ',mode))
    (`(not . ,cond)
     `(not ,(translate-buffer-condition-1 cond)))
    (`(or . ,conds)
     `(or ,@(mapcar #'translate-buffer-condition-1 conds)))
    (`(and . ,conds)
     `(and ,@(mapcar #'translate-buffer-condition-1 conds)))))

(defun translate-buffer-condition (condition)
  `(lambda (buffer) ,(translate-buffer-condition-1 condition)))

(defvar sample-condition
  '(and (or buffer-file-name
	    (derived-mode . compilation-mode)
	    (derived-mode . dired-mode)
	    (derived-mode . diff-mode)
	    (derived-mode . comint-mode)
	    (derived-mode . eshell-mode)
	    (derived-mode . change-log-mode))
	"\\*.+\\*"
	(not . "\\` ")))

(defvar form (translate-buffer-condition sample-condition))
(defvar compiled (byte-compile form))

(benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.397404883 3 0.18942550900000032)
(benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.113651836 0 0.0)
```

I couldn't understand the need for a hash table or special symbol vars
or what that "arg" was, so I took it out, but it shouldn't make a
difference.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 07:31:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673742084004 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673742084004
          (code B ref 58839); Wed, 02 Nov 2022 07:31:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:30:08 +0000
Received: from localhost ([127.0.0.1]:44821 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq8CN-00012W-OS
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:30:08 -0400
Received: from mout02.posteo.de ([185.67.36.66]:35065)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oq8CM-00010W-Kg
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:30:07 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 40ED8240101
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 08:29:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667374200; bh=jy9zFtFpB2mdtCFIsUzVAtH85CIH4/+iMLHUrPnmG6c=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=XJ5iAdUTJdkzFt8NjNbPXyD6PT8pct25g6YuuZq+efnCFgL7YhXXiE53B32PH579L
 uYQ7bBGGo3vjv8EMY7N4w8GoFPK4jLnzVUjO+8Q8Ko++ZWSawTq5WGN2l9cW0CZvSH
 ewJN1eXU7lk8gVrxfXN4BAOlzmwD7KYVZf3USEG81zyitNHBEHuoRaUasXNAJquBdj
 mFW7M7jogIgy+0IWVieyNQ7nEWat1/e/mYXq35dWjCsdQcaREndppClkmFv++qLNk2
 5n10Z+X48AsVb8aoLrQ1C2n8chd6bcU/r34FsKWsRWjY9Dhx/B/q502T4dQbI6pDJ9
 M1R/OuItgLeiA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2JSQ4LqMz9rxH;
 Wed,  2 Nov 2022 08:29:58 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87edulu8ly.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 07:19:05 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 07:29:58 +0000
Message-ID: <87wn8dbyq1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>>> Yes, do that, but use byte-compile instead, not eval.
>> I have tried both, and it doesn't appear to be a particular advantage
>> one way or another.  That being said, this approach is *a lot* faster,
>> to the point that I first assumed it was broken:
>
> Yes, this approach is always going to be much faster than the "naive"
> approach.  Now I've taken your code as a starting point, simplified it,
> and I get a reasonable/typical 3.5x speedup when I use a
> byte-compilation strategy, so one of us isn't measuring
>
> ```elisp
> (defun translate-buffer-condition-1 (condition)
>   (pcase-exhaustive condition
>     ((or 't 'nil)
>      condition)
>     ((pred stringp)
>      `(string-match-p ,condition (buffer-name buffer)))
>     ((pred functionp)
>      `(,condition buffer))

This would break the current behaviour, because `buffer-match-p'
requires the function be called with an additional argument if possible.

This is fundamental for `display-buffer-alist' to work.

>     (`(major-mode . ,mode)
>      `(eq (buffer-local-value 'major-mode buffer)
> 	  ',mode))
>     (`(derived-mode . ,mode)
>      `(provided-mode-derived-p
>        (buffer-local-value 'major-mode buffer)
>        ',mode))
>     (`(not . ,cond)
>      `(not ,(translate-buffer-condition-1 cond)))
>     (`(or . ,conds)
>      `(or ,@(mapcar #'translate-buffer-condition-1 conds)))
>     (`(and . ,conds)
>      `(and ,@(mapcar #'translate-buffer-condition-1 conds)))))
>
> (defun translate-buffer-condition (condition)
>   `(lambda (buffer) ,(translate-buffer-condition-1 condition)))
>
> (defvar sample-condition
>   '(and (or buffer-file-name
> 	    (derived-mode . compilation-mode)
> 	    (derived-mode . dired-mode)
> 	    (derived-mode . diff-mode)
> 	    (derived-mode . comint-mode)
> 	    (derived-mode . eshell-mode)
> 	    (derived-mode . change-log-mode))
> 	"\\*.+\\*"
> 	(not . "\\` ")))
>
> (defvar form (translate-buffer-condition sample-condition))
> (defvar compiled (byte-compile form))
>
> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.39740=
4883 3 0.18942550900000032)
> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.11365183=
6 0 0.0)
> ```
>
> I couldn't understand the need for a hash table or special symbol vars
> or what that "arg" was, so I took it out, but it shouldn't make a
> difference.

The hash table makes a significant different, try evaluating

   (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffer))=
) ;; (0.113651836 0 0.0)

I have created a new bug report for this issue bug#58950, so that this
one can return to the topic of project.el.

The fresh symbols are used to keep the code clean and avoid possible
naming conflicts.=20

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 07:34:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673744284343 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673744284343
          (code B ref 58839); Wed, 02 Nov 2022 07:34:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:33:48 +0000
Received: from localhost ([127.0.0.1]:44827 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq8Fv-00017y-GI
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:33:47 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:42809)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq8Ft-00017j-KL
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:33:46 -0400
Received: by mail-wr1-f54.google.com with SMTP id cl5so11556813wrb.9
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:33:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=hkBlhjHAmwcH5wsKSvAtTfPSwxRvtlbHQBFpwqGDRRk=;
 b=iu2xOOC1sTx5aSZCjDrRq+GCjSZ9dJ7iJZnWivAbRgG+oxlh+706uxJEw2mvC6ZumI
 BNh0YaJqAxSOBdfR0gfqJyVNDPaKCt6h2CgAR7o5wkQa7SnlJR6iYCSq++TFtocy36MJ
 q1tjUU247Cps2WNiyMziTGq7XwV7sfZZl3NhW/mDZ0extVLr4I8I8320zm8+YQl+P8DH
 SBMqGT7hWehnPCxWHCiveulEB7bM1aDxWc+2qv0+e0vcUygd9VwRObXOKDO9pw/e4ReY
 i2C2UkKthIpXPTTHQXeJRo+qXrcCUKWy+Gqelgd4k4w9RjbR9Qzhix/kGJM58HaNYpND
 d2Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=hkBlhjHAmwcH5wsKSvAtTfPSwxRvtlbHQBFpwqGDRRk=;
 b=P8jxXJygCflGpTy8fYTtiQbk7Gjwvu7AizKANnk/3grXEly0ypR3HLSlvUg9skINwy
 EaHgjmHw1GdpW9FI4Zf6ummbs66mEasSsqvUF2RXO3LSap4hfXZkRnv1gN2P0L7Y54t9
 e6a1oaF8zIsb0+L5hfskP/m89U33sfWwwq1xv2GHzol6mIKKndeGq9lxZ2f8ybtjFnQ8
 BHWhArfI9cLJ8Ce39ufXUJqS9NfvE1OxhoHcoDwKRrHR3R/Vfn84G8/KPGKhUXz7HfiY
 gbwPLqFeJtQI51xYHm0oJkpq2DHMp/TuuuWefS2o7NFrrtfI4IWHLwxx2usXZztI1j0q
 IL/Q==
X-Gm-Message-State: ACrzQf0jBoN9r/vljvzgVPm8VVYog1dbbH4RxlxcPP3/8hnHHboYLas2
 0jaRF7OeXYClm1xicxPw66k=
X-Google-Smtp-Source: AMsMyM4ei06dbaNaak3aHBKTTrk4fTWansaRpe3L8xFCz6mrvBJTqfT3t49B5wn6IxPiWxLIJUYAaw==
X-Received: by 2002:adf:ab1d:0:b0:236:6301:c77 with SMTP id
 q29-20020adfab1d000000b0023663010c77mr13765297wrc.119.1667374419806; 
 Wed, 02 Nov 2022 00:33:39 -0700 (PDT)
Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id
 r17-20020a05600c459100b003c7087f6c9asm1304919wmo.32.2022.11.02.00.33.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 00:33:39 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> (Dmitry Gutov's
 message of "Wed, 2 Nov 2022 00:23:11 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
Date: Wed, 02 Nov 2022 07:34:51 +0000
Message-ID: <87a659u7vo.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

>> I've explained to Philip objective reasons why I think evaluated
>> mini-languages are almost always inferior to a decent Lisp such as Elisp.
>> You could perfectly reasonably deprecate these two variables.
> Not where this discussion is going, is it?

Not sure.  This started has a report of hidden buffer being incorrectly
killed by project.el.  After much insistence, you've agreed to plug the
hole in that library.  During tests I also discovered that project.el is
killing other buffers nonsensically, like Gnus buffers, *ibuffer*, and
many other global.  It was actually easier to find false-positives of
your heuristic than true ones.  Again, after some insistence, you seem
to have come around that these things represent bugs.

Three people here have suggested an opt-in approach for the true
positives.  Now your strategy seems to be "OK: let all these false
positives remain nonsensically associated with a project in
project-buffers but let's have global databases of exceptions for
specific operations, using a (largely redundant) mini-language for
buffer-matching".

If that doesn't sound like a bad idea in the face of much better other
ideas, I don't know what else to tell you.

>>  > I'm fairly sure that the solution I offered would be easy enough
>>  > implement, to actually protect the vulnerable buffer.
>>  > I suppose we are not doing that, however.
>> You sketched an untested code-less idea and I explained how flawed
>> it was.
>
> Back atcha. Modulo "code-less".

Not only did I provide code, I also verified that it works.  Anyone can
see my messages to verify that.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 07:40:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673747474817 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: Philip Kaludercic <philipk@HIDDEN>, 58839 <at> debbugs.gnu.org, Manuel Uberti <manuel.uberti@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673747474817
          (code B ref 58839); Wed, 02 Nov 2022 07:40:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:39:07 +0000
Received: from localhost ([127.0.0.1]:44831 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq8L5-0001Fd-DD
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:39:07 -0400
Received: from mail-wr1-f49.google.com ([209.85.221.49]:44790)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq8L3-0001F8-6Z
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:39:05 -0400
Received: by mail-wr1-f49.google.com with SMTP id v1so23194429wrt.11
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:39:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=oBB1pjuGq5DBJTXzI00pR3+doKqX60PeMJxwMnGK8Zs=;
 b=mOfsDMq6b/6OyKlNquyeAiSqkld4CHxx0IP/D6ZLSnL3ZtNqiiPp5H99rxQe7kJWu0
 +r+yAgD2Guua0i7Xvyf/tUwH78+H3Zxiykg5ubyEMbQ4m5H5ZQXTLgN07A3iTwpLjtPi
 4d8rcw9RZKgHdi6ncJENM0c4Nfkbd5yvrdAslu+dy6NsMILoT6qC8VsL3fTJpvcHQIWc
 8Ld8Fa9103hty5GeR/0h7KOFAyTowPWGvSeGJiuYeaQ5GhQtPqJYQkmkfuEn74bZuDpl
 s5aXzpW5uBbQ75WyLUZO5IvWdjobAylzgSIYrLgDXWx8K+e29uZnfFd9gMnMucHgmWPD
 hgVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=oBB1pjuGq5DBJTXzI00pR3+doKqX60PeMJxwMnGK8Zs=;
 b=4LkyWLleT0I8Iv4ExSC1fDx590TLDb4IxoP/JBv15bhaJWYrXdX06E8eCr86jJbcge
 vHzJbkqkhP0Nd6l/EYgdQ1x2JFTtH8/D/Nf1D5JkZFaPWq2OYMN5xO1sw2/nxpkAudXD
 JGCfnnJcWB8rUz3wGgrVAR9KiN/47ZhhgKNVy4SkCSOYGGFaCbWS3O9Ux1sePxNxKqqg
 njE+8KrbcU6hc2obwgP41gxyCg7GL+cfNYxTF2vMQQVECCrhUnI60iIykRpmut2+p96F
 Q5dBIYUgvd99I39wTD8rmrz8xZHlGLCw3u+HNJ4uJJJnZwA8fiaWe7JzW802YlMlQFpL
 ygHQ==
X-Gm-Message-State: ACrzQf2IzT3cn7MUEyzlwzuFh5KbUpMsFUPd2caRVNZN45ATCJEWI0n+
 jLy4Fhf1eiIqt60UABwsm7Q=
X-Google-Smtp-Source: AMsMyM7iXa2VT9zsRWE1Wyq8gMJvooADXf4MXGjycWkwQC1yr2iKvQMrqQ42/6Po+Bbj3i/kv2eRWA==
X-Received: by 2002:a5d:4572:0:b0:236:ccbe:3513 with SMTP id
 a18-20020a5d4572000000b00236ccbe3513mr9147191wrc.497.1667374739353; 
 Wed, 02 Nov 2022 00:38:59 -0700 (PDT)
Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id
 h3-20020a05600c350300b003c6deb5c1edsm1256849wmq.45.2022.11.02.00.38.57
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 00:38:58 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN> (Dmitry Gutov's
 message of "Wed, 2 Nov 2022 00:24:57 +0200")
References: <87sfj8umwb.fsf@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <b6c7eb42-5e33-5129-c94e-a832efa37c6c@HIDDEN>
 <CALDnm53uyFccrHnEcu+53n=ivz8R2Z4qF=BK7YYxVkbQOFB5wA@HIDDEN>
 <e000ac28-e7f7-a264-429f-c5fd277dda4d@HIDDEN>
 <CALDnm52eYg-dnShdD9Rihz6Px7ZsQ5Uu9rcSTwpA6e8eKy=7Mg@HIDDEN>
 <390b18bf-7514-c8a0-9eee-76685d7ed856@HIDDEN>
Date: Wed, 02 Nov 2022 07:40:10 +0000
Message-ID: <875yfxu7mt.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 01.11.2022 18:23, Jo=C3=A3o T=C3=A1vora wrote:
>> On Tue, Nov 1, 2022, 15:27 Dmitry Gutov <dgutov@HIDDEN
>> <mailto:dgutov@HIDDEN>> wrote:
>>     That's an unfair expectation: you didn't suggest an improvement
>> either.
>> Oh, I'm sorry, and is it fair to inquire about the subliminally
>> compressed: "and eglot reinvents http-url"? Can you generously grant
>> a few more sentences as to its meaning and relevance?
>> Your compressed the meaning and usefulness of a feature to something
> trivial (and only semi-relevant), and so did I.
> I thought that would be obvious.

Not only it is not, but I still have no idea what on earth you're
talking about.  You said "Eglot reinvents http-url", leading anyone to
believe there is something in http-url that Eglot can reuse.  Apparently
there isn't: so you're either too clever or just wasting time.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 07:48:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673752335572 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673752335572
          (code B ref 58839); Wed, 02 Nov 2022 07:48:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 07:47:13 +0000
Received: from localhost ([127.0.0.1]:44837 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq8Sv-0001Ro-E3
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:47:13 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:36427)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq8Su-0001Rb-31
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 03:47:12 -0400
Received: by mail-wr1-f41.google.com with SMTP id j15so23244513wrq.3
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 00:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=q54FjQLIrHzW3Kpe3xQQcJI92y2NY2m9psANBUVBLNs=;
 b=ic3SfF2bu6A6ME3VqaB9im3WLcknwiXv52KTi3nF1xdty0k4Wu/FXQ6lQFwtLVoxoF
 XWZVROrV0S5dwNBCZKfL3Znllqguh/4OjHot3eFX77Q552IiTSqfamQ4/JuDh054fzMo
 4jYDkfJKFE/n4kxbKl5ESIIPyJgwSw+5FckPXIYjwMXxOgM8fj7/k2hSkLfGO7Uh4BE3
 YbXM1EWQC8+3/9N0wCodu6trmnBi9nIfNxhDDNTaduYE3JwVkzy5e1yj1ZasKhrZlpJp
 hs4tGlZHTbYd8vra1tcarA0XD/SqqCKK51fAJZnb2TU8uTz118r3aoZB5dx211d939FD
 WPtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=q54FjQLIrHzW3Kpe3xQQcJI92y2NY2m9psANBUVBLNs=;
 b=WWQLJhJvqGSAbdVlCtgstyQAVgvzJ7IRA4hDnoNvzX26noN9Cpf44ngUzAXZAaDIBC
 pPPIvKtA8Sc7oWvQLTO6ARLFRXvSdXfp8hNH7iZ02UEryQBPYtPA/M0qU08fdHXwv+4P
 RIDDAEMmVE5IMFZR8gdSEssdjogsw6FSeS+Gm6hQofbtiu1iMvmlwkNgWiYOVeJa+4Zm
 OK1qP9FT5R9vp9aAjYApZRF80yQsYMsgWiIA4ZRTWeC6LoRRoUEO0+bJsNZkKr1ix7hG
 aFPfeykZXeCYy2dDmoMCB06vesbsVRMvrnPFW2ree4vzHFFbpld1pn8vaTdPi9k4hPWZ
 OtNQ==
X-Gm-Message-State: ACrzQf2Wp0x5/+/VrUp10ML+jQrE9F8Pm5SGQ2/7YuTzs5ucIaPC47tV
 L7SK3UZhNsejrVe+BXNca/EgdbbBgCE=
X-Google-Smtp-Source: AMsMyM4Js//3hYf9zYTH5+A+o48RSAyNBtIekfxJx3IFFWZfM5+mF4IzF70e8z5PK0wU4iLUNwFC+A==
X-Received: by 2002:adf:a45a:0:b0:236:9aa8:e675 with SMTP id
 e26-20020adfa45a000000b002369aa8e675mr14339829wra.407.1667375225949; 
 Wed, 02 Nov 2022 00:47:05 -0700 (PDT)
Received: from krug ([87.196.81.36]) by smtp.gmail.com with ESMTPSA id
 u8-20020a05600c19c800b003c6f8d30e40sm1145856wmq.31.2022.11.02.00.47.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 00:47:05 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87wn8dbyq1.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 07:29:58 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 07:48:16 +0000
Message-ID: <871qqlu79b.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>
>> Philip Kaludercic <philipk@HIDDEN> writes:
>>
>>>> Yes, do that, but use byte-compile instead, not eval.
>>> I have tried both, and it doesn't appear to be a particular advantage
>>> one way or another.  That being said, this approach is *a lot* faster,
>>> to the point that I first assumed it was broken:
>>
>> Yes, this approach is always going to be much faster than the "naive"
>> approach.  Now I've taken your code as a starting point, simplified it,
>> and I get a reasonable/typical 3.5x speedup when I use a
>> byte-compilation strategy, so one of us isn't measuring
>>
>> ```elisp
>> (defun translate-buffer-condition-1 (condition)
>>   (pcase-exhaustive condition
>>     ((or 't 'nil)
>>      condition)
>>     ((pred stringp)
>>      `(string-match-p ,condition (buffer-name buffer)))
>>     ((pred functionp)
>>      `(,condition buffer))
>
> This would break the current behaviour, because `buffer-match-p'
> requires the function be called with an additional argument if possible.
>
> This is fundamental for `display-buffer-alist' to work.

I couldn't figure out where this argument arise or who should provides
it (the condition?).  It wasn't clear.  At any rate, if you understand
this you can probably re-add it and I'm sure it won't make any
difference to the time.

>>     (`(major-mode . ,mode)
>>      `(eq (buffer-local-value 'major-mode buffer)
>> 	  ',mode))
>>     (`(derived-mode . ,mode)
>>      `(provided-mode-derived-p
>>        (buffer-local-value 'major-mode buffer)
>>        ',mode))
>>     (`(not . ,cond)
>>      `(not ,(translate-buffer-condition-1 cond)))
>>     (`(or . ,conds)
>>      `(or ,@(mapcar #'translate-buffer-condition-1 conds)))
>>     (`(and . ,conds)
>>      `(and ,@(mapcar #'translate-buffer-condition-1 conds)))))
>>
>> (defun translate-buffer-condition (condition)
>>   `(lambda (buffer) ,(translate-buffer-condition-1 condition)))
>>
>> (defvar sample-condition
>>   '(and (or buffer-file-name
>> 	    (derived-mode . compilation-mode)
>> 	    (derived-mode . dired-mode)
>> 	    (derived-mode . diff-mode)
>> 	    (derived-mode . comint-mode)
>> 	    (derived-mode . eshell-mode)
>> 	    (derived-mode . change-log-mode))
>> 	"\\*.+\\*"
>> 	(not . "\\` ")))
>>
>> (defvar form (translate-buffer-condition sample-condition))
>> (defvar compiled (byte-compile form))
>>
>> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.3974=
04883 3 0.18942550900000032)
>> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.1136518=
36 0 0.0)
>> ```
>>
>> I couldn't understand the need for a hash table or special symbol vars
>> or what that "arg" was, so I took it out, but it shouldn't make a
>> difference.
>
> The hash table makes a significant different, try evaluating
>
>    (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffer=
))) ;; (0.113651836 0 0.0)
>

You seem to be suggesting to byte-compile a compiled object which is
odd.  Did you mean (byte-compile form)?  More importantly, you're
forcing the byte-compilation process to run every one of those 100000
repetitions, which is not something we want to measure: the point of any
code compilation is to do it once and then reuse the results of
compilation many times.

(and I'm still confused by the purpose of the hash table usage)

> The fresh symbols are used to keep the code clean and avoid possible
> naming conflicts.

Can you explain what naming conflict would arise or how the code I
provided is somehow unclean?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 08:22:02 +0000
Resent-Message-ID: <handler.58839.B58839.16673773118973 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673773118973
          (code B ref 58839); Wed, 02 Nov 2022 08:22:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:21:51 +0000
Received: from localhost ([127.0.0.1]:44867 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq90Q-0002Kf-T6
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:21:51 -0400
Received: from mout02.posteo.de ([185.67.36.66]:57453)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oq90O-0002KS-NL
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:21:49 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id E7A69240106
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 09:21:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667377302; bh=8rGBLeQTatMLtFtWVAm9WzySkujMKY8TW358ZcjpmpY=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=Dw2Bc27/VA8pE1DGV/Izx05CYu1FUszuE8XkW3xLF5OzP1S+e0T2abliNi3F4CjaS
 eIPEbpICd2ujMkJIkXXAwp1v1WNAa8W1KGYT8e8zTFBFn4WqKzkaA39A8Ui2vLgaup
 SwvyjmkbjqDQi/SJcHMwVRGVWSqYI5a9YKxQMmonjffA8Sd5D9VA8D2MoDcfn7pP7E
 76yYAG1OreytGY5NnQ5j5spKGDCaBHcJ7Ap5qk/ffq0LTb/ta8YoWmGDzeAVI5Lwqr
 buCGe19DYtzAGPnrby/Q0sBBpoF7lZe6spoh1umZOmuuS9sOvnRgPlXXA12eg6hbMe
 FQJ/6sI1NdFgg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2Kc60nB9z6tmy;
 Wed,  2 Nov 2022 09:21:41 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <871qqlu79b.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 07:48:16 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 08:21:41 +0000
Message-ID: <877d0dbwbu.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>>
>>> Philip Kaludercic <philipk@HIDDEN> writes:
>>>
>>>>> Yes, do that, but use byte-compile instead, not eval.
>>>> I have tried both, and it doesn't appear to be a particular advantage
>>>> one way or another.  That being said, this approach is *a lot* faster,
>>>> to the point that I first assumed it was broken:
>>>
>>> Yes, this approach is always going to be much faster than the "naive"
>>> approach.  Now I've taken your code as a starting point, simplified it,
>>> and I get a reasonable/typical 3.5x speedup when I use a
>>> byte-compilation strategy, so one of us isn't measuring
>>>
>>> ```elisp
>>> (defun translate-buffer-condition-1 (condition)
>>>   (pcase-exhaustive condition
>>>     ((or 't 'nil)
>>>      condition)
>>>     ((pred stringp)
>>>      `(string-match-p ,condition (buffer-name buffer)))
>>>     ((pred functionp)
>>>      `(,condition buffer))
>>
>> This would break the current behaviour, because `buffer-match-p'
>> requires the function be called with an additional argument if possible.
>>
>> This is fundamental for `display-buffer-alist' to work.
>
> I couldn't figure out where this argument arise or who should provides
> it (the condition?).  It wasn't clear.  At any rate, if you understand
> this you can probably re-add it and I'm sure it won't make any
> difference to the time.

See `display-buffer-assq-regexp' in window.el.

>>>     (`(major-mode . ,mode)
>>>      `(eq (buffer-local-value 'major-mode buffer)
>>> 	  ',mode))
>>>     (`(derived-mode . ,mode)
>>>      `(provided-mode-derived-p
>>>        (buffer-local-value 'major-mode buffer)
>>>        ',mode))
>>>     (`(not . ,cond)
>>>      `(not ,(translate-buffer-condition-1 cond)))
>>>     (`(or . ,conds)
>>>      `(or ,@(mapcar #'translate-buffer-condition-1 conds)))
>>>     (`(and . ,conds)
>>>      `(and ,@(mapcar #'translate-buffer-condition-1 conds)))))
>>>
>>> (defun translate-buffer-condition (condition)
>>>   `(lambda (buffer) ,(translate-buffer-condition-1 condition)))
>>>
>>> (defvar sample-condition
>>>   '(and (or buffer-file-name
>>> 	    (derived-mode . compilation-mode)
>>> 	    (derived-mode . dired-mode)
>>> 	    (derived-mode . diff-mode)
>>> 	    (derived-mode . comint-mode)
>>> 	    (derived-mode . eshell-mode)
>>> 	    (derived-mode . change-log-mode))
>>> 	"\\*.+\\*"
>>> 	(not . "\\` ")))
>>>
>>> (defvar form (translate-buffer-condition sample-condition))
>>> (defvar compiled (byte-compile form))
>>>
>>> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.397=
404883 3 0.18942550900000032)
>>> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.113651=
836 0 0.0)
>>> ```
>>>
>>> I couldn't understand the need for a hash table or special symbol vars
>>> or what that "arg" was, so I took it out, but it shouldn't make a
>>> difference.
>>
>> The hash table makes a significant different, try evaluating
>>
>>    (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffe=
r))) ;; (0.113651836 0 0.0)
>>
>
> You seem to be suggesting to byte-compile a compiled object which is
> odd.  Did you mean (byte-compile form)?=20=20

Yes, that was a copy-o on my end.

>                                          More importantly, you're
> forcing the byte-compilation process to run every one of those 100000
> repetitions, which is not something we want to measure: the point of any
> code compilation is to do it once and then reuse the results of
> compilation many times.

Exactly, but if the byte-compilation would take place in buffer-match-p,
then the measurement is relevant.

> (and I'm still confused by the purpose of the hash table usage)

The rationale is the same as for regular expressions in the core.  They
are also compiled and stored, to avoid the need for them to be
interpreted over and over again.

This should all be explained in the bug report I pointed you to, and
where this discussion should continue.

>> The fresh symbols are used to keep the code clean and avoid possible
>> naming conflicts.
>
> Can you explain what naming conflict would arise or how the code I
> provided is somehow unclean?

This is currently not the case, but if the language extended in the
future, there is the possibility that naming conflicts could arise.  I
am just following the same principle used when writing macros that
avoids name capturing.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 08:37:01 +0000
Resent-Message-ID: <handler.58839.B58839.166737817210437 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166737817210437
          (code B ref 58839); Wed, 02 Nov 2022 08:37:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:36:12 +0000
Received: from localhost ([127.0.0.1]:44891 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq9EJ-0002iH-VS
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:36:12 -0400
Received: from mout02.posteo.de ([185.67.36.66]:48461)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oq9EI-0002hy-2z
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:36:10 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 46C7D240106
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 09:36:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667378164; bh=Ot+q00dZUOP5YSKK0ieXy3UMuqGDwaectKAK4GN256Y=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=QhjJ49KF4B7aZ2Q4RttqOhq/uXIAuSFsJ/KeZa2iIz89pGP28FssxUd1jXkw3gSpG
 QcU9JANkuEyWERNCb88eL00scyRaLta838KuPQlgYRZH3Fq0Bd3OG3GRhLVNxXCRey
 sJtWUL9dnSsT3LliWzOeowwFJ1psVkqX+AAU26N+4uwBR+k8dwXZp9Vgf97vFopwfW
 XUdNnG5fs03rYzqlgnOkY1sgYp7XZJQ5D70gXD7O3Dz6RAwJap5ZMXi/0U0n2kebOb
 6keGvzRfj/4FInfHZUZsKHKebz+bCcTd3QWA/FZdvbLHGmvDw8bWmAmxUw3OiUOcXa
 aY6qsuqcl9c2g==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2Kwc6RpXz6tn3;
 Wed,  2 Nov 2022 09:36:00 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87a659u7vo.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 07:34:51 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 08:36:00 +0000
Message-ID: <8735b1bvnz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


In general I'd like to remind everyone of the GNU Kind Communication
Guidelines, because the tone of the discussion in this issue report has
been unpleasant for a few days now.

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>>> I've explained to Philip objective reasons why I think evaluated
>>> mini-languages are almost always inferior to a decent Lisp such as Elis=
p.
>>> You could perfectly reasonably deprecate these two variables.
>> Not where this discussion is going, is it?
>
> Not sure.  This started has a report of hidden buffer being incorrectly
> killed by project.el.=20=20

The issue that was reported was that Eglot/jsonrpc raised an error that
broke `project-kill-buffer'.  This could have also all been solved by
wrapping a `with-demoted-errors' around `kill-buffer'.

>                        After much insistence, you've agreed to plug the
> hole in that library.  During tests I also discovered that project.el is
> killing other buffers nonsensically, like Gnus buffers, *ibuffer*, and
> many other global.  It was actually easier to find false-positives of
> your heuristic than true ones.  Again, after some insistence, you seem
> to have come around that these things represent bugs.
>
> Three people here have suggested an opt-in approach for the true
> positives.  Now your strategy seems to be "OK: let all these false
> positives remain nonsensically associated with a project in
> project-buffers but let's have global databases of exceptions for
> specific operations, using a (largely redundant) mini-language for
> buffer-matching".

For the record, I am still not convinced 100% either way.  Whether or
not whitelisting or blacklisting is the better approach will concretely
depend the list of misjudgments that the current condition makes.

> If that doesn't sound like a bad idea in the face of much better other
> ideas, I don't know what else to tell you.
>
>>>  > I'm fairly sure that the solution I offered would be easy enough
>>>  > implement, to actually protect the vulnerable buffer.
>>>  > I suppose we are not doing that, however.
>>> You sketched an untested code-less idea and I explained how flawed
>>> it was.
>>
>> Back atcha. Modulo "code-less".
>
> Not only did I provide code, I also verified that it works.  Anyone can
> see my messages to verify that.
>
> Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 08:41:01 +0000
Resent-Message-ID: <handler.58839.B58839.166737844710839 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166737844710839
          (code B ref 58839); Wed, 02 Nov 2022 08:41:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:40:47 +0000
Received: from localhost ([127.0.0.1]:44898 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq9Ik-0002ok-Nq
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:40:47 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:41793)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq9If-0002oO-LC
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:40:44 -0400
Received: by mail-wr1-f46.google.com with SMTP id w14so23391001wru.8
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 01:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=4YZbzUoBCcHCiWBRI/Eho7eyp9jmpwGDzJ+1R1MOkeE=;
 b=dy4K/L/HN1FQinMpf3Sdx50ISUgEAroMtl5Kre+mEygfPW38UvKP4qdVNR7foIMxLL
 UC3UrMfgCSIdzjCmykQVzzU/rMCo6Ht1QqC9vr7RB7+XpIF/TOuSQAB5CdmJvVoIubbi
 /PObSNcY+3tQKTnjnqD8osH+I800WFR6rmcNo5dwxX6xMgwF3oNLRT34txvgAfS0+Sy7
 BPRPALMvQx3ni3wi+CMPskPyhb72Ol9pK5T5mb/Sj9T9+0vgrXFAidpJ1+v0Cd9j0njL
 TPc5XfUOOLoRhTZXtpzDmYzs7g2kzaizi7HL8SmgPCAAbLrwdNcnxhrX3Mdn2JszZzRM
 6MIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=4YZbzUoBCcHCiWBRI/Eho7eyp9jmpwGDzJ+1R1MOkeE=;
 b=GTXBzRRYHP/RtJMLZgmXhAHGuuo6TGpPttQIwoR0nHe+arjolOqmATctdGLbnwzIBN
 3Q9qLYmJy9XtCvZIhyC447q6Bk4yrP4a+5Ns9b1IVZMCApMSbXncV7hEk5GEGAr3tCxu
 nogRMXobEPDpDqw4K4IoqRBjhuNzY0QzUKgwRTdXzmDxV0JqO/obOBrIlMc/uw55rYDU
 N+pc/hGJ7W8mpQeXM/8ALy0G9Yq3cDyU9NhhnI7HcI+Bu/PTTrG+r46IWVZsf+1tg/0R
 2rOpHG8etRARS4Bf9AzmqyIySOK6vR8zSc/9QxA3bDlvuxHG6tlaK055PCFwTo4o36hS
 gTYw==
X-Gm-Message-State: ACrzQf1AKx5woKRFoiYn+klxPOwuyzKviXLO4BjHxuBfj+QZm0MwsGAu
 D3aicUjSiCdg+X8qIP5HmpJ6h/Px59s=
X-Google-Smtp-Source: AMsMyM4CYP/MMyboTbBr9y3T8bITmuu+EbkxiItF34oKR+XOaknxjUmV4V2vEqMmxsGx0IBtBcQKlA==
X-Received: by 2002:a5d:4944:0:b0:236:7f32:1ad5 with SMTP id
 r4-20020a5d4944000000b002367f321ad5mr14399230wrs.377.1667378435446; 
 Wed, 02 Nov 2022 01:40:35 -0700 (PDT)
Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36])
 by smtp.gmail.com with ESMTPSA id
 bo29-20020a056000069d00b0022eafed36ebsm12474562wrb.73.2022.11.02.01.40.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 01:40:34 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <877d0dbwbu.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 08:21:41 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
 <877d0dbwbu.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 08:41:47 +0000
Message-ID: <87r0ylsq7o.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

>> I couldn't figure out where this argument arise or who should provides
>> it (the condition?).  It wasn't clear.  At any rate, if you understand
>> this you can probably re-add it and I'm sure it won't make any
>> difference to the time.
>
> See `display-buffer-assq-regexp' in window.el.

Sorry, I'm not following.  Anyway, as I said, this seems to be a detail:
feel free to add back arg wherever it is needed.

>>                                          More importantly, you're
>> forcing the byte-compilation process to run every one of those 100000
>> repetitions, which is not something we want to measure: the point of any
>> code compilation is to do it once and then reuse the results of
>> compilation many times.
>
> Exactly, but if the byte-compilation would take place in buffer-match-p,
> then the measurement is relevant.

But then you're throwing away the benefits of compilation.  But my
suggestion is for you to get rid of "buffer-match-p".  Rather, make a
'buffer-matcher' that does the compilation, and then place the return
value of that, which is a plain old (possibly very fast, if compiled)
function object in the display-buffer-alist variables and everywhere
where you can put functions.

That way you still get your mini-language, you get a much faster version
of it, and you don't force your mini-language to other people who prefer
just typing plain old Elisp.

>> (and I'm still confused by the purpose of the hash table usage)
>
> The rationale is the same as for regular expressions in the core.  They
> are also compiled and stored, to avoid the need for them to be
> interpreted over and over again.
>
> This should all be explained in the bug report I pointed you to, and
> where this discussion should continue.

Well, I think you're overcomplicating this.  If you insulate
display-buffer-alist from the mini-language (i.e. you keep it the way it
was), then you don't need this hash table, and you can still use the
mini-language.

(add-to-list 'display-buffer-alist
             `(,(philips-mini-language-buffer-matcher
                  '(and (mode . x) (or (not (and "123")))))
               . display-buffer-in-side-window))

Again: you keep your mini-language and you can suggest people use
philips-mini-language-buffer-matcher in many other library APIs in
Emacs, not just window.el, but without needing to ever touch those
libraries.

It's a much more modular design, less impositive, much smaller and much
faster.

> This is currently not the case, but if the language extended in the
> future, there is the possibility that naming conflicts could arise.  I
> am just following the same principle used when writing macros that
> avoids name capturing.

You don't need to cargo cult that principle blindly.  This kind of macro
hygiene you are talking about is for macros that take arbitrary lisp
forms, which is not the case of the mini-language.  If it ever is, add
the hygiene then and likely not in a top-level defvar.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 08:50:02 +0000
Resent-Message-ID: <handler.58839.B58839.166737898711806 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166737898711806
          (code B ref 58839); Wed, 02 Nov 2022 08:50:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:49:47 +0000
Received: from localhost ([127.0.0.1]:44903 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq9RS-00034L-Qz
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:49:47 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:36541)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oq9RR-000349-Sp
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 04:49:46 -0400
Received: by mail-wr1-f46.google.com with SMTP id j15so23453633wrq.3
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 01:49:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=UqO6Eoe2NqDqH4iJ3U7JsD0VWa0ZGpu0DdddY4sDWzU=;
 b=CZK0cHgoBV49hOJJXV9w7GkprbdCWuhWCe93b8OH8YO2g4vZtPZacW73fuy4SiQAGU
 KrmiT4ujgtlMYS3XQGfXEO6CMqO7qAMSRDUCIRqd9D98kLTiRDDoem6Mf2KdBA7YCttD
 dkYA+EvnJ+2VyTOteLHmTaOtXmB5fXyHA7JiyKjHHszVxh6uNbep9nTRB+SriLzl7K2d
 W1HA80oTwO3xjmbBRk5GQALoeaJE8YeJk0D/VI/BoV9W/0e97yIFeTWS73bRMTcQfzyI
 CKOZdyXH0A0ECG8a5MNawh/NhQAD7yepRYJk5kEqXPMSIohHp9sWO4+JvmHuVyfFIl6x
 xl9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=UqO6Eoe2NqDqH4iJ3U7JsD0VWa0ZGpu0DdddY4sDWzU=;
 b=mc03ljS5WcREXMHWgPsn+fLpi+dNqzYlyEGXVEj/G52AanPkPZTNAJiiyJ0TRJbEHf
 na8wyhRthvAZytXSFHE+5FFw68HpWorCxDM2p8tpOCKD9ConPzX74RohHjEp6/qwMLbN
 DCKIr3SIoIOVhB7fqOMqV2g2ht3qK/P8XZcRwu9ryraY68RUEPUro6NHn7a69B7UIC1D
 /K4AyZ9faxnrPMXLze953BtTPWbncjEmrfZOENIvxje3ijEOEUSFLklzJN8FakBvbaET
 ipXXMtsvf9Dv6d+TwPQN2ZabXcWcRAPSQ6EYHGpbr4HR+dJjblbV9mYTlNFX98fbpi1t
 pYxQ==
X-Gm-Message-State: ACrzQf0pZhcSlFE6x9VrrGhWSuHXsaKihsOpD4V6JxIC+/aRq5ThleFd
 RvY/lrjSctlXjjUHZjUeGpc=
X-Google-Smtp-Source: AMsMyM7L+n65U9ydEV/2SynYN9TFIGPjpABUeeA3mC536MYqgDYZtHTWLz60z7nQje7s4/a0Aeib8Q==
X-Received: by 2002:adf:ff90:0:b0:236:cb5d:4824 with SMTP id
 j16-20020adfff90000000b00236cb5d4824mr9642927wrr.718.1667378980204; 
 Wed, 02 Nov 2022 01:49:40 -0700 (PDT)
Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36])
 by smtp.gmail.com with ESMTPSA id
 dn12-20020a05600c654c00b003cf537ec2efsm1490437wmb.36.2022.11.02.01.49.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 01:49:39 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <8735b1bvnz.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 08:36:00 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 08:50:51 +0000
Message-ID: <87mt99spsk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

>> Not sure.  This started has a report of hidden buffer being incorrectly
>> killed by project.el.  
>
> The issue that was reported was that Eglot/jsonrpc raised an error that
> broke `project-kill-buffer'.  This could have also all been solved by
> wrapping a `with-demoted-errors' around `kill-buffer'.

No.  It couldn't.  The error is there to show you among other things
that the LSP connection isn't being shut down correctly, which is not
something to paper over.  And even if you did paper over the error, you
would break eglot-autoshutdown.  I've explained that at least 3 times
already in the beginning of this discussion.

>> Three people here have suggested an opt-in approach for the true
>> positives.  Now your strategy seems to be "OK: let all these false
>> positives remain nonsensically associated with a project in
>> project-buffers but let's have global databases of exceptions for
>> specific operations, using a (largely redundant) mini-language for
>> buffer-matching".
>
> For the record, I am still not convinced 100% either way.

I just said that becasue you at one point did suggested the
opt-in approach 

  I have to admit that I am more and more inclined to make the list a
  opt-in thing, where  we explicitly mark those major modes that are tied
  to a project.

But of course it's OK to change one's mind back and forth.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 09:07:02 +0000
Resent-Message-ID: <handler.58839.B58839.166737999713373 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166737999713373
          (code B ref 58839); Wed, 02 Nov 2022 09:07:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:06:37 +0000
Received: from localhost ([127.0.0.1]:44915 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq9hl-0003Td-4h
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:06:37 -0400
Received: from mout02.posteo.de ([185.67.36.66]:57853)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oq9hi-0003TP-BP
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:06:35 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id AA20B240107
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 10:06:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667379988; bh=D/MMZN0u3wA0q1CiPMdlRRfIgDygp0wIW5mRrLBnn9s=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=UJeZGbz/TQBvwU57snwHdZ8Z8rGh57ej5N8LNVPxsmzc6AGY66Fn7W/q77gjxh1Pr
 V98sOnsRa3ctKtELKeH16RhwFtqlrxD6IGtZTpY5TzzXxkPHgFCDC5+qzZHTMyHfTw
 Lql1t1emhUUqKOYrLTJcoaNYphuU9iWV5tGRfFx6dn2EniCHfZ2I6Rf4dN94L9jwGM
 do1oatojzOFCq74am3LWQyezs5abuNlkEs/rJspWvOO7tvFq3ZWFb1IvTfOTdCzkEl
 Zut6DsLUT2Pb0YqutLxTsPiO6kaqfdLZcJw2qYe8mlOj+WvJ3mbTmWg0JS4g2jTnIT
 xfzhG6CBX9RBg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2Lbk4D3Cz6tm6;
 Wed,  2 Nov 2022 10:06:25 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87r0ylsq7o.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 08:41:47 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
 <877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 09:06:20 +0000
Message-ID: <87v8nxafoz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>>> I couldn't figure out where this argument arise or who should provides
>>> it (the condition?).  It wasn't clear.  At any rate, if you understand
>>> this you can probably re-add it and I'm sure it won't make any
>>> difference to the time.
>>
>> See `display-buffer-assq-regexp' in window.el.
>
> Sorry, I'm not following.  Anyway, as I said, this seems to be a detail:
> feel free to add back arg wherever it is needed.

I just meant to give an example where and how the argument is used.

>>>                                          More importantly, you're
>>> forcing the byte-compilation process to run every one of those 100000
>>> repetitions, which is not something we want to measure: the point of any
>>> code compilation is to do it once and then reuse the results of
>>> compilation many times.
>>
>> Exactly, but if the byte-compilation would take place in buffer-match-p,
>> then the measurement is relevant.
>
> But then you're throwing away the benefits of compilation.  But my
> suggestion is for you to get rid of "buffer-match-p".  Rather, make a
> 'buffer-matcher' that does the compilation, and then place the return
> value of that, which is a plain old (possibly very fast, if compiled)
> function object in the display-buffer-alist variables and everywhere
> where you can put functions.

I see, but I don't agree.  My main objection here is that the conditions
aren't introspectable (e.g. when using ECI) any more and that it all
becomes more verbose.

> That way you still get your mini-language, you get a much faster version
> of it, and you don't force your mini-language to other people who prefer
> just typing plain old Elisp.

That is not the case to begin with, as the "mini-language" is just a
super-set of Emacs Lisp, seeing as any function is a legal word of the
language.  As I have said before, it just makes it easier to write
common operations like matching buffer names or major modes.

>>> (and I'm still confused by the purpose of the hash table usage)
>>
>> The rationale is the same as for regular expressions in the core.  They
>> are also compiled and stored, to avoid the need for them to be
>> interpreted over and over again.
>>
>> This should all be explained in the bug report I pointed you to, and
>> where this discussion should continue.
>
> Well, I think you're overcomplicating this.  If you insulate
> display-buffer-alist from the mini-language (i.e. you keep it the way it
> was), then you don't need this hash table, and you can still use the
> mini-language.
>
> (add-to-list 'display-buffer-alist
>              `(,(philips-mini-language-buffer-matcher
>                   '(and (mode . x) (or (not (and "123")))))
>                . display-buffer-in-side-window))
>
> Again: you keep your mini-language and you can suggest people use
> philips-mini-language-buffer-matcher in many other library APIs in
> Emacs, not just window.el, but without needing to ever touch those
> libraries.
>
> It's a much more modular design, less impositive, much smaller and much
> faster.

I have not much elese to say on the issue here, that hasn't already been
said.  If you think it is such a mistake, please report a bug or post on
emacs-devel and we can clarify the issue there.

>> This is currently not the case, but if the language extended in the
>> future, there is the possibility that naming conflicts could arise.  I
>> am just following the same principle used when writing macros that
>> avoids name capturing.
>
> You don't need to cargo cult that principle blindly.  This kind of macro
> hygiene you are talking about is for macros that take arbitrary lisp
> forms, which is not the case of the mini-language.  If it ever is, add
> the hygiene then and likely not in a top-level defvar.

I don't see any disadvantage from following best practices, even if it
is not immediately relevant.  There is no reason why `buffer' ought to
be a special symbol, so I would like to avoid the possibility of this
leading to issues that hack to be back-hacked at some point in the
future.

But this is just a matter of personal style.  I have seen you write
documentations strings like "[...] This docstring appeases checkdoc,
that's all.", while I insist on documenting every function I commit,
even if I am the only one who uses the package.  We just have different
principles.

> Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 09:14:01 +0000
Resent-Message-ID: <handler.58839.B58839.166738040213981 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166738040213981
          (code B ref 58839); Wed, 02 Nov 2022 09:14:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:13:22 +0000
Received: from localhost ([127.0.0.1]:44927 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oq9oH-0003dR-Vd
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:13:22 -0400
Received: from mout01.posteo.de ([185.67.36.65]:46817)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oq9oG-0003dD-2v
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:13:20 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 5ECED240029
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 10:13:14 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667380394; bh=GTE+qtj3jpAdAmC0k1Am+bbj+3c9F/InoY0V4DVdBR4=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=BBB1t00VfwcuKkAM90aPmHxr7DRmir1eY2jmjaLJ8QUgJYdkf4nn6usRY7huoMags
 zrhQ/WtMEPk/zkw5RwMXbR+J193rNXnN4wCo7QcCX/UTlQI4rSUZyGXIN1rKlGY3aK
 ttN+Ay7y75sRadQLITD2u/bWtJM1Z/094oJjCLcjB7XQwM3GvP5wJJuOyZKtpjC1ZE
 VMxnhb3thRerlq6kbsxKLdAV02hz1IaENaQI5WFa6HPUyHC99Ni4DpBHl89XoTat7t
 vrCyVtC/GBn3cST0JvZ7qE3/g8bLnp1mcFetTIVBAW8obNou82jI6/gCfFylwyQGw7
 /lfcwXWI2JUPg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2LlV4LVRz9rxV;
 Wed,  2 Nov 2022 10:13:10 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87mt99spsk.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 08:50:51 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 09:13:10 +0000
Message-ID: <87r0ylafdl.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>>> Not sure.  This started has a report of hidden buffer being incorrectly
>>> killed by project.el.=20=20
>>
>> The issue that was reported was that Eglot/jsonrpc raised an error that
>> broke `project-kill-buffer'.  This could have also all been solved by
>> wrapping a `with-demoted-errors' around `kill-buffer'.
>
> No.  It couldn't.  The error is there to show you among other things
> that the LSP connection isn't being shut down correctly, which is not
> something to paper over.  And even if you did paper over the error, you
> would break eglot-autoshutdown.  I've explained that at least 3 times
> already in the beginning of this discussion.

That was not my concern, my concern was that project-kill-buffer broke.
I continue to not see a reason why project.el should be considered
broken because of this, and not jsonrpc/eglot.

To be fair, I am not as familiar with LSP as you are, so there might be
a technical reason why this is the case, but without something like
that, you appear to be privileging an arbitrary perspective, supposedly
because you are the maintainer of these packages.

This is probably best solved by reading code.  Can you point me to a few
functions/section/etc. that would help me clarify the situation.

>>> Three people here have suggested an opt-in approach for the true
>>> positives.  Now your strategy seems to be "OK: let all these false
>>> positives remain nonsensically associated with a project in
>>> project-buffers but let's have global databases of exceptions for
>>> specific operations, using a (largely redundant) mini-language for
>>> buffer-matching".
>>
>> For the record, I am still not convinced 100% either way.
>
> I just said that becasue you at one point did suggested the
> opt-in approach=20
>
>   I have to admit that I am more and more inclined to make the list a
>   opt-in thing, where  we explicitly mark those major modes that are tied
>   to a project.

The key word here is "more and more inclined".

> But of course it's OK to change one's mind back and forth.

I haven't made up my mind, I am just trying to understand all
perspectives, and get a better overview over the issue.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 09:52:01 +0000
Resent-Message-ID: <handler.58839.B58839.166738270818012 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166738270818012
          (code B ref 58839); Wed, 02 Nov 2022 09:52:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 09:51:48 +0000
Received: from localhost ([127.0.0.1]:44940 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqAPT-0004gO-I5
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:51:48 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:38594)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oqAPS-0004g6-93
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 05:51:46 -0400
Received: by mail-wr1-f51.google.com with SMTP id a14so23693693wru.5
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 02:51:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=DQxZ+TIJnmlG5FyUAsgo/jcWJ7hSylBkCT7OzA+18K4=;
 b=CMl8qqjoYrAe0TYZ8aT7Uzh25IAtV7PRJfvbRvJckBC/f9KD1y2brQYCKHV5v3qjJi
 XJnYUba/+0HoNyrowI36rVw3uniNY5BiZBMmS1BBuhx+aKFt4gstJ33KH0SJ7yGeTy+o
 ty1zvkuopqrW1S4eVqspEVIO3MCrwQ44YkIFhZeZse0Cf5njZ5d73ZdCHM1GMBjsF5jD
 4YInJ4JOetduzVLu9hVVeSgvbS7fV6WGh3Xah1IYHllK4SpWi1O/fwH0lLdk7RvqpBZz
 SrMncKifX8ywHTyGRccyk1XmS86ikUPe9cWrXagiOL9RyJt6sspG4PZeui4k1Wq8+PHn
 FmAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=DQxZ+TIJnmlG5FyUAsgo/jcWJ7hSylBkCT7OzA+18K4=;
 b=NpJCpqFi6/VXKFU0sogMpzw48Y2krzXW0+muw9XfOKquaPt4F5bT8etByE0dzyGU51
 6DT8dUArv7IJkZAs9z1iomKTfsi5wHRfntSw1smoxMAypep01xuAl0bmv3b0Z4IN4lev
 Bvli3vAJDbLq7sisR3Mg7YemRyxLhmiHuDfHNhR0PDQnKd2DrjCjeEP2pq6poa9R0/vl
 vxl5I/1ZDgvbI3tdDLP1XVhJd2eNSl7TmOs4mnNlj2d5jE+oJTMLAVlbu/jEa/fUZudR
 OC18sdl2GwLHfuL3NjvXc208mY824mHI7ooBeaNv6+x+Jbx9jjbOLDqVXQmtGIfmk+FO
 kTcg==
X-Gm-Message-State: ACrzQf0h7OfTOqBnwt3fzns+3UEpvB4AOkoU1J/FdcmWEUqEoO9m2qlr
 CwEjo3uculNzoXFJPZaY7RNtu/en4BA=
X-Google-Smtp-Source: AMsMyM7ErRsvKilVFiZdVq4nREd7oE43kw+zWhg24EwNpD+bUhMgpQ8ZruOXlCVjtVKhkZkWZrN44Q==
X-Received: by 2002:adf:ef4e:0:b0:236:6608:f6ce with SMTP id
 c14-20020adfef4e000000b002366608f6cemr14467325wrp.85.1667382700005; 
 Wed, 02 Nov 2022 02:51:40 -0700 (PDT)
Received: from krug (87-196-81-36.net.novis.pt. [87.196.81.36])
 by smtp.gmail.com with ESMTPSA id
 j19-20020a05600c1c1300b003a8434530bbsm1621429wms.13.2022.11.02.02.51.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 02:51:39 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87v8nxafoz.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 09:06:20 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
 <877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN>
 <87v8nxafoz.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 09:52:50 +0000
Message-ID: <87iljxsmx9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

>> But then you're throwing away the benefits of compilation.  But my
>> suggestion is for you to get rid of "buffer-match-p".  Rather, make a
>> 'buffer-matcher' that does the compilation, and then place the return
>> value of that, which is a plain old (possibly very fast, if compiled)
>> function object in the display-buffer-alist variables and everywhere
>> where you can put functions.
>
> I see, but I don't agree.  My main objection here is that the conditions
> aren't introspectable (e.g. when using ECI) any more and that it all
> becomes more verbose.

If you want introspection, i.e. see the translated Elisp code when
inspecting the value of display-buffer-alist, then pass another argument
to buffer-matcher which makes it return an uncompiled function.

Furthermore, as debugging goes, the buffer-matcher idea is much better:
if the user does a mistake in his mini-language program, that mistake
can be caught when buffer-matcher is called, i.e. during her init.  Not
when display-buffer-alist is about to run the program.  And if your
mini-language ever evolves, you can also issue warnings at this point.
This is what compilation and compilers have always existed for.  Lisp
gives you this power in a few lines (something which takes a lot of hard
in other languages).

>> That way you still get your mini-language, you get a much faster version
>> of it, and you don't force your mini-language to other people who prefer
>> just typing plain old Elisp.
>
> That is not the case to begin with, as the "mini-language" is just a
> super-set of Emacs Lisp, seeing as any function is a legal word of the
> language.  As I have said before, it just makes it easier to write
> common operations like matching buffer names or major modes.

That's not what a super-set is.  A super-set language is C++ to C,
because C++ can compile (almost any) C program.  The mini-language is a
DSL.  In my opinion, one that brings very few advantages, but there's no
accounting for taste.  So the common way to do DSL's in Elisp is use the
approach I provided.  You make them more useful, and you don't force
people to use them.

> I have not much elese to say on the issue here, that hasn't already been
> said.  If you think it is such a mistake, please report a bug or post on
> emacs-devel and we can clarify the issue there.

OK.  It's not so much a mistake as lost opportunity to make a more
reusable, less britlle piece of software using less code, less
docstrings, less manual writing, etc.  Cuts down on the mental overload,
potentially teaches some people Elisp instead of mini-language, and
reduces CPU usage and laptop battery time.

>>> This is currently not the case, but if the language extended in the
>>> future, there is the possibility that naming conflicts could arise.  I
>>> am just following the same principle used when writing macros that
>>> avoids name capturing.
>>
>> You don't need to cargo cult that principle blindly.  This kind of macro
>> hygiene you are talking about is for macros that take arbitrary lisp
>> forms, which is not the case of the mini-language.  If it ever is, add
>> the hygiene then and likely not in a top-level defvar.
>
> I don't see any disadvantage from following best practices, even if it
> is not immediately relevant.

This is not a best practice, really it's not. MAKE-SYMBOL and GENSYM are
for macro that take forms hygiene: this is simply not that case.

> be a special symbol, so I would like to avoid the possibility of this
> leading to issues that hack to be back-hacked at some point in the
> future.
>
> But this is just a matter of personal style.  I have seen you write
> documentations strings like "[...] This docstring appeases checkdoc,
> that's all."

Ahaha, that was just a joke.  Keep documenting all your functions,
you're very right to do so.  Trust me, don't make defvar's for
(make-symbol).  Noone does this: it's just cruft.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 11:32:01 +0000
Resent-Message-ID: <handler.58839.B58839.16673886884786 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16673886884786
          (code B ref 58839); Wed, 02 Nov 2022 11:32:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 11:31:28 +0000
Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqBxw-0001F8-6O
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 07:31:28 -0400
Received: from mout01.posteo.de ([185.67.36.65]:52937)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oqBxu-0001Et-Ub
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 07:31:27 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 29DE6240028
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 12:31:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667388681; bh=5/Ac3PgPkgBFNQ25ePngB+QFUx3mdYx09nb3tUzp/E4=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=D2pq4ewm43qJhfmhshhVeiLRhtzoAPot6mPht1mgpswURcsV5RNBmp22fbjSmwKHb
 oBJ+iyNEXGSu5e3oD3C8MMECWoGzVjAwn1GlnWrXRXJSWhrA2iy7VhXrNkO4wpJfgX
 pJjDb9DRdbas+7nfrvVvxRQV5Q1oH5txqKc/D7/4kuJm/5212A30UG1/diiS6mYTk1
 YxkqmSLkDJ5OnJ0HdraGZBlFM/ahoQGDQYD/yReHGsJ408kYAsk3o2hvlV3XbW7Egs
 aExo4gTocy/rTuKQqMGxvLye1h2wYs2xM/jtj4zXF23NJ38fEkZFZMfNSm3mW67CRC
 xVrMgg0IkKI4w==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2Pps73CPz6tn7;
 Wed,  2 Nov 2022 12:31:17 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87iljxsmx9.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 09:52:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <87tu3jgdbv.fsf@HIDDEN>
 <CALDnm52NHNybscttBE6bvoL--2tk6hEt-dqnYHe5Kvyx9TRNfQ@HIDDEN>
 <87h6zihq3q.fsf@HIDDEN>
 <CALDnm51Xv9HG06VVzMZbmHc_rG_ugpZQyFh3rsc1oK1jQcEdtA@HIDDEN>
 <877d0ehlnb.fsf@HIDDEN>
 <CALDnm539kHSheoUaKRme3u_y4PG0oh4caqP0hOswne_z-KpXug@HIDDEN>
 <87edumg4fd.fsf@HIDDEN>
 <CALDnm52xcqAisBo_jBwWs5Sy7NXfeY7o6YgHq39YvfHq0Kv_sQ@HIDDEN>
 <874jvig2rp.fsf@HIDDEN> <87edulu8ly.fsf@HIDDEN>
 <87wn8dbyq1.fsf@HIDDEN> <871qqlu79b.fsf@HIDDEN>
 <877d0dbwbu.fsf@HIDDEN> <87r0ylsq7o.fsf@HIDDEN>
 <87v8nxafoz.fsf@HIDDEN> <87iljxsmx9.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 11:31:11 +0000
Message-ID: <871qqltwxs.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

>>> That way you still get your mini-language, you get a much faster version
>>> of it, and you don't force your mini-language to other people who prefer
>>> just typing plain old Elisp.
>>
>> That is not the case to begin with, as the "mini-language" is just a
>> super-set of Emacs Lisp, seeing as any function is a legal word of the
>> language.  As I have said before, it just makes it easier to write
>> common operations like matching buffer names or major modes.
>
> That's not what a super-set is.  A super-set language is C++ to C,
> because C++ can compile (almost any) C program.  The mini-language is a
> DSL.  In my opinion, one that brings very few advantages, but there's no
> accounting for taste.  So the common way to do DSL's in Elisp is use the
> approach I provided.  You make them more useful, and you don't force
> people to use them.

Let B be the set of S-Expressions that `buffer-match-p' handles, and F
be the set of S-Expressions that satisfy `functionp'.  We see that

   B =E2=88=96 F =E2=89=A0 =E2=88=85

as for any foo, (major-mode . foo) =E2=88=88 B, but (major-mode . foo) =E2=
=88=89 F.  We
see that

   F =E2=88=96 B =3D =E2=88=85

as every function (per `functionp') is a valid `buffer-match-p'
predicate.  Hence we conclude that B =E2=8A=8B F (strict superset).        =
     =E2=88=8E

>> be a special symbol, so I would like to avoid the possibility of this
>> leading to issues that hack to be back-hacked at some point in the
>> future.
>>
>> But this is just a matter of personal style.  I have seen you write
>> documentations strings like "[...] This docstring appeases checkdoc,
>> that's all."
>
> Ahaha, that was just a joke.  Keep documenting all your functions,
> you're very right to do so.  Trust me, don't make defvar's for
> (make-symbol).  Noone does this: it's just cruft.

Again, see the other bug report, the code I pasted in this thread was
just a sketch.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 14:00:02 +0000
Resent-Message-ID: <handler.58839.B58839.166739758921769 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166739758921769
          (code B ref 58839); Wed, 02 Nov 2022 14:00:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 13:59:49 +0000
Received: from localhost ([127.0.0.1]:46876 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqEHU-0005f1-QS
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 09:59:49 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:36800)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oqEHS-0005dv-3n
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 09:59:47 -0400
Received: by mail-wm1-f49.google.com with SMTP id
 c3-20020a1c3503000000b003bd21e3dd7aso1354171wma.1
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 06:59:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:message-id:date:user-agent
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=c+gtgLx7+FM25kMavdsdyEKPs4qpG3svZJ0epApx19Y=;
 b=aL7K7IvOBFn3vTVHHNC5NpBQgJA7WQ9QfkKBZc060Jy1aRY8j4kTFIy4r6t/k/m2l+
 SAZuUB8ITlv4cWmHWSgeuUX7wVMF6tw8Zjd7rC1h0CP5/B1ure/dy71wf0KP0/41DSNY
 10PUekrMwhtNdG7hqFQ5HZxqY+/0dOw/FZ7clttHmPjxuZbcXJyG3wN+Kwz/qNv894hd
 goM4L4FamNDZqq5a/tsggiGJVxVENPVrm0lT0+wQ/fp84Omgl+lJYMYX4cH1nYjNYXMl
 KfsAhq2cKXscL9rmzrwgSwMFue4RtOMT103XMMXNzqZxKywVQuQW3tjKy70mQa+RWGKz
 dmhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:message-id:date:user-agent
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=c+gtgLx7+FM25kMavdsdyEKPs4qpG3svZJ0epApx19Y=;
 b=jA9yifs21r6C49FpS3n+1b9G+/OZ6ykepNIQ7FasgACwaXC3AjILhlR0+9RuQ9X6SL
 u7iyW0qLRpnZ+jT5bbZHRxvDYHVtmwBNYUAK6m6X7M9mvcwfzMdPjLKV685PeD6DKUHS
 0rXdaVKj7lUuLA9chnnmV88zdMKTZdT3XuY85YK0vq+9DKjYk4Pd/0M420NeBNhsAEgB
 chcdksKNYKbpDnr7MbKcGs3uFlleye06UF4FDIvi4sLgDj3MYQsPnsrhgPXEoW4y3pVB
 I/8aB36WJ/s/NtHrsIoNkRMs8te8q1NKYFB16wcrzv/rK0yi0W9rkRbW9KYCM/qSfhe5
 76Sw==
X-Gm-Message-State: ACrzQf147eB3XtRA7MAVtb3FoIT/JBbQtYOa1TBN+RJV1g9nZ+24VGi2
 NrJiilFSmh5wxTJdvx33+WU=
X-Google-Smtp-Source: AMsMyM73/fW+z2EwJD0t/61PriZArr5Obt9SHJ/SHbND+4C64oafQ7zKOVBSbY+iSWDWxXVVTEcfzw==
X-Received: by 2002:a05:600c:3550:b0:3cf:4c20:5856 with SMTP id
 i16-20020a05600c355000b003cf4c205856mr15911295wmq.188.1667397579806; 
 Wed, 02 Nov 2022 06:59:39 -0700 (PDT)
Received: from krug ([87.196.80.27]) by smtp.gmail.com with ESMTPSA id
 b6-20020adfee86000000b0023677fd2657sm12931313wro.52.2022.11.02.06.59.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 06:59:39 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87r0ylafdl.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 09:13:10 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Wed, 02 Nov 2022 14:00:50 +0000
Message-ID: <87cza5sbfx.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Philip Kaludercic <philipk@HIDDEN> writes:

> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>
>> Philip Kaludercic <philipk@HIDDEN> writes:
>>
>>>> Not sure.  This started has a report of hidden buffer being incorrectly
>>>> killed by project.el.=20=20
>>>
>>> The issue that was reported was that Eglot/jsonrpc raised an error that
>>> broke `project-kill-buffer'.  This could have also all been solved by
>>> wrapping a `with-demoted-errors' around `kill-buffer'.
>>
>> No.  It couldn't.  The error is there to show you among other things
>> that the LSP connection isn't being shut down correctly, which is not
>> something to paper over.  And even if you did paper over the error, you
>> would break eglot-autoshutdown.  I've explained that at least 3 times
>> already in the beginning of this discussion.
>
> That was not my concern, my concern was that project-kill-buffer
> broke.  I continue to not see a reason why project.el should be
> considered broken because of this, and not jsonrpc/eglot.

It was always broken since the way it was created.  Eglot's precedes it,
I've also explained this.  You can't kill a internal hidden buffer just
because you can see it anymore than you unintern some "--" symbol in
obarray simply because you can see it and don't like its inelegant name,
or you think it's taking too much RAM.  I can't really explain this any
other way.

> This is probably best solved by reading code.  Can you point me to a few
> functions/section/etc. that would help me clarify the situation.
> I haven't made up my mind, I am just trying to understand all
> perspectives, and get a better overview over the issue.

OK, one last time.  First, the above principle of encapsulation has
nothing to do with LSP or Eglot or Jsonrpc.

Specifically in Eglot, as I already explained, eglot.el and jsonrpc.el
colaborate so that jsonrpc.el holds a network process to communicate
with the LSP server.  It uses a buffer for more convenient and efficient
parsing of messages.  That buffer is out of bounds for Eglot (and anyone
else).  Eglot doesn't know or care that a buffer is being used, it only
actuate on the handle using operations of jsonrpc.el's API.  According
to user options, Eglot provides controlled shutdown and reconnection
using these operations.

All of this has worked for a long time and predates project.el's buffer
collection/killing/switching logic.

If you or some Lisp package finds and destroys the hidden implementation
detail, all the above is broken.  Therefore packages like project.el
that do it are buggy in that regard.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Philip Kaludercic <philipk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 14:44:01 +0000
Resent-Message-ID: <handler.58839.B58839.166740019125888 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166740019125888
          (code B ref 58839); Wed, 02 Nov 2022 14:44:01 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 14:43:11 +0000
Received: from localhost ([127.0.0.1]:46929 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqExS-0006jU-W9
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 10:43:11 -0400
Received: from mout01.posteo.de ([185.67.36.65]:39709)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <philipk@HIDDEN>) id 1oqExR-0006jH-3k
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 10:43:09 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 92669240027
 for <58839 <at> debbugs.gnu.org>; Wed,  2 Nov 2022 15:43:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1667400183; bh=3roSJmNTpjwRyTG2KuL5vChIpLyzYe2+QuXqaftY3vU=;
 h=From:To:Cc:Subject:Autocrypt:Date:From;
 b=p+RwVeJRveO/CbGP2Qb8R5iQa6e6IX+xuSoCE+LY8txr6E7EroF7NaUnGd1JBuK48
 B6ecVO5jbSC7yEOZKKD9sqqQlhkaApHrhDYHBCAcgkMbws7S/NfaVego5dAMTb2oMz
 KXa4yFyesesZyEODPzScliq2piX2YGYv7eVCcIvD6K2fRQQ+LSt1c53oD2MZB8MD6U
 eGpxuFz8QlixdxEV9JHLsfSUz/7i8tWtbFAend3eMiBxTKm2135WrZbz7Cz6usk70W
 5AEsyN2c0Gnk6OGG9w+yUy47W6+OAuGUv5ERCm36rso8RDaPnxb7yi3/0XDWhqdXzD
 UPlcaVTyb1/7w==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4N2V463CxNz9rxK;
 Wed,  2 Nov 2022 15:42:59 +0100 (CET)
From: Philip Kaludercic <philipk@HIDDEN>
In-Reply-To: <87cza5sbfx.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 14:00:50 +0000")
References: <87sfj8umwb.fsf@HIDDEN> <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
 <87cza5sbfx.fsf@HIDDEN>
Autocrypt: addr=philipk@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo
 aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0
 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ
 CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh
 io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF
 AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo
 Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS
 g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB
Date: Wed, 02 Nov 2022 14:42:59 +0000
Message-ID: <87r0ylh0y4.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Philip Kaludercic <philipk@HIDDEN> writes:
>
>> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
>>
>>> Philip Kaludercic <philipk@HIDDEN> writes:
>>>
>>>>> Not sure.  This started has a report of hidden buffer being incorrect=
ly
>>>>> killed by project.el.=20=20
>>>>
>>>> The issue that was reported was that Eglot/jsonrpc raised an error that
>>>> broke `project-kill-buffer'.  This could have also all been solved by
>>>> wrapping a `with-demoted-errors' around `kill-buffer'.
>>>
>>> No.  It couldn't.  The error is there to show you among other things
>>> that the LSP connection isn't being shut down correctly, which is not
>>> something to paper over.  And even if you did paper over the error, you
>>> would break eglot-autoshutdown.  I've explained that at least 3 times
>>> already in the beginning of this discussion.
>>
>> That was not my concern, my concern was that project-kill-buffer
>> broke.  I continue to not see a reason why project.el should be
>> considered broken because of this, and not jsonrpc/eglot.
>
> It was always broken since the way it was created.  Eglot's precedes it,
> I've also explained this.=20=20

This is not an argument.

>                            You can't kill a internal hidden buffer just
> because you can see it anymore than you unintern some "--" symbol in
> obarray simply because you can see it and don't like its inelegant name,
> or you think it's taking too much RAM.  I can't really explain this any
> other way.

The equivalence is not given, more so because there is no package that
manages symbols the way that project.el manages buffers.  If this is
all, your argument, or rather statement, is simply not convincing, no
matter how often it is reiterated. *

>> This is probably best solved by reading code.  Can you point me to a few
>> functions/section/etc. that would help me clarify the situation.
>> I haven't made up my mind, I am just trying to understand all
>> perspectives, and get a better overview over the issue.
>
> OK, one last time.  First, the above principle of encapsulation has
> nothing to do with LSP or Eglot or Jsonrpc.

Again, it is not given that this applies to buffers.  Robust code should
be able to handle a missing resource or prevent the resource from being
revoked.  This is not possible with buffers, so this is a design fault
with Eglot or Jsonprc. *

> Specifically in Eglot, as I already explained, eglot.el and jsonrpc.el
> colaborate so that jsonrpc.el holds a network process to communicate
> with the LSP server.  It uses a buffer for more convenient and efficient
> parsing of messages.  That buffer is out of bounds for Eglot (and anyone
> else).=20=20

Can I `switch-to-buffer' into it, can I `kill-buffer' it?  Yes?  So it
is not out of bounds, and a mistake was made in the design by assuming
this is the case. *

E.g. why does the buffer have a default directory?

>         Eglot doesn't know or care that a buffer is being used, it only
> actuate on the handle using operations of jsonrpc.el's API.  According
> to user options, Eglot provides controlled shutdown and reconnection
> using these operations.

OK, these appear as convince options that can be used, but don't prevent
me from killing any buffers. *

> All of this has worked for a long time and predates project.el's buffer
> collection/killing/switching logic.

Again, this is not an argument, just a statement of fact that doesn't
imply anything definitive.  From the same statement I can also infer
that jsonrpc/Eglot had an undetected bug that was exposed by project.el.
You are committing an informal logical fallacy by assuming some kind of
temporal order in the attribution of mistakes. *

> If you or some Lisp package finds and destroys the hidden implementation
> detail, all the above is broken.  Therefore packages like project.el
> that do it are buggy in that regard.

This is a "If it can be destroyed by the truth, it deserves to be
destroyed"-kind of thing.  Double-dash symbols are "private" by
convention, but that might change in the future.  Hidden buffers are
just not displayed, as said in the manual (found via the index):

    Buffers that are ephemeral and generally uninteresting to the user
    have names starting with a space, so that the =E2=80=98list-buffers=E2=
=80=99 and
    =E2=80=98buffer-menu=E2=80=99 commands don=E2=80=99t mention them (but =
if such a buffer visits a
    file, it *is* mentioned).  A name starting with space also initially
    disables recording undo information; see *note Undo::.

The keywords being "ephemeral and generally uninteresting", not "private
and off-limits" This is not the same kind of thing like with a symbol
that was generated using `make-symbol', where you are guaranteed nobody
can access it without being passed the symbol directly or via some dirty
hacks.  And just so it is clear, using `buffer-list' is not a dirty
hack. *

If you need private buffers, you either need to argue that the
convention be clarified in the reference manual or have these
implemented in such a way (e.g. by passing a flag to
`get-buffer-create') nobody can access a private buffer without being
passed the buffer object or via some dirty hacks.  And just so it is
clear, using `buffer-list' is not a dirty hack.

  * These are all "Strong Opinions, Weakly Held", I really don't care
    about it too much.  What I don't like about this discussion is the
    tone you take in postulating the mistake was made somewhere else and
    that is that.  This is arrogant, unkind and non-constructive
    behaviour.  If necessary I am ready to discuss this off-list and
    resolve any issues.  I am inherently non-confrontation and dislike
    the fact that I have to even clarify this.  My top priority is
    always to find common grounds.

    I am almost never frustrated by discussions on the Emacs development
    mailing list or in bug reports.  The tone is at best productive, at
    worst lethargic.  This thread is an exception, which is very sad to
    see.  I implore you once more to consider the GNU Kind Communication
    Guidelines and try to foster a productive and positive atmosphere.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 17:52:03 +0000
Resent-Message-ID: <handler.58839.B58839.166741151120247 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166741151120247
          (code B ref 58839); Wed, 02 Nov 2022 17:52:03 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 17:51:51 +0000
Received: from localhost ([127.0.0.1]:47134 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqHu3-0005GV-DM
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 13:51:51 -0400
Received: from relay2-d.mail.gandi.net ([217.70.183.194]:50025)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1oqHu1-0005G6-D0
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 13:51:49 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by mail.gandi.net (Postfix) with ESMTPSA id A40EE40003;
 Wed,  2 Nov 2022 17:51:41 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <87r0ylh0y4.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 14:42:59 +0000")
Organization: LINKOV.NET
References: <87sfj8umwb.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
 <87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 19:32:02 +0200
Message-ID: <86mt991dst.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

>> OK, one last time.  First, the above principle of encapsulation has
>> nothing to do with LSP or Eglot or Jsonrpc.
>
> Again, it is not given that this applies to buffers.  Robust code should
> be able to handle a missing resource or prevent the resource from being
> revoked.  This is not possible with buffers, so this is a design fault
> with Eglot or Jsonprc. *

While the default value of project-kill-buffer-conditions really
looks too wide (especially covering fundamental-mode and special-mode),
OTOH I completely support the request to make Eglot more resilient
to unforeseeable situations.  Currently it's so brittle, so I get a lot
of such errors all the time:

Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
  file-truename(nil)
  eglot--path-to-uri(nil)
  eglot--TextDocumentIdentifier()
  eglot--signal-textDocument/didClose()
  kill-buffer(#<buffer  *xref-temp*>)
  xref--convert-hits(...)
  xref-matches-in-files("word" ...)
  project--find-regexp-in-files("word" ...)
  apply(project--find-regexp-in-files ("word" ...))
  xref--show-xref-buffer(...)
  xref--show-xrefs(...)
  xref-show-xrefs(...)
  project-find-regexp("word")
  funcall-interactively(project-find-regexp "word")
  command-execute(project-find-regexp)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 02 Nov 2022 18:16:02 +0000
Resent-Message-ID: <handler.58839.B58839.166741292522473 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Philip Kaludercic <philipk@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166741292522473
          (code B ref 58839); Wed, 02 Nov 2022 18:16:02 +0000
Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 18:15:25 +0000
Received: from localhost ([127.0.0.1]:47146 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqIGq-0005qO-T7
	for submit <at> debbugs.gnu.org; Wed, 02 Nov 2022 14:15:25 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:44029)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oqIGp-0005qA-41
 for 58839 <at> debbugs.gnu.org; Wed, 02 Nov 2022 14:15:23 -0400
Received: by mail-wr1-f41.google.com with SMTP id g12so25719175wrs.10
 for <58839 <at> debbugs.gnu.org>; Wed, 02 Nov 2022 11:15:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
 :message-id:reply-to;
 bh=ZjydSnWPQwAnNtmqHXHYKoSgigP9wifb8CEJ8zJJpg8=;
 b=GzenMkO90w0AJz6HiLliHKu+puHMqFUNyOoHL8szLc9q4Xs372I9AAKrBPSj5xKUW8
 SZedyd2PA9rBIWsIPKEpm22nnluPCizf1SHrgotel0Lz+ERgZNuJcmdmoqlu0Ndz7K94
 B+bCxpv+TMdsxXRGTlvB2qVBLLqzPUowIhDZZrfpeqnyH1UhG4mCtWXBOjFiJJcc556G
 MVFV03aCfOGla9xZFSlgsHp8JYVaLshLYD7hr35kT087iJ7sA5zY+sJVlL7TTT8RtwJb
 ohC41kTQF5ZGCe3C5xXjGm449hGk02pZt1Xj0OUb9zh2QnTC51ewrvSr19M5qvnJOG8u
 D+Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:mime-version:user-agent:message-id:date
 :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
 :to:cc:subject:date:message-id:reply-to;
 bh=ZjydSnWPQwAnNtmqHXHYKoSgigP9wifb8CEJ8zJJpg8=;
 b=dG0mNKc9hGQXMLk0xQ+2Jt3W0TEjmILkBDYz8ttPpbAHfIYHV/5emE45bmTMysV1rm
 +8gZCpXxGzDbAtPd9+qHQC7JWyJXlX221Y/qb3y+KC6SK5MVURFG8LkTFNfkVgguzFx/
 HkJu1xghCi6dARZSDp8rRPpu4GNqF6UZJjPI6kCavSzbUHaqsQuFqecbZzc0qEG1Xyvk
 U5SClW4ohht6VoBwWyFKu4sO3oO1lVwr/Gjhnbk51rLReptJ6d8vEMHCcct01qW5kKQ2
 J1j7F+93rSxFDRIbc7D0QKpSn12rvO/LkIeCkE4QQvYHIkiTnj0W/b5VwoesRAIjepKX
 2iJw==
X-Gm-Message-State: ACrzQf11sZ8BN5n9ioM6M3NRInljiz/ga1Gan2HLCeL58gIQJ9azvDq6
 uhBZU/6QzvH5Wa/1mqNuUrprvbc4MP0=
X-Google-Smtp-Source: AMsMyM5EEEQ4f0ycmIZoIKQDtAiZO7AdQLkeakEl2gOfPEkOd9f5L0Jf6EdcfLwJL9FRBh/0FnJtsg==
X-Received: by 2002:adf:b612:0:b0:236:5d1f:143a with SMTP id
 f18-20020adfb612000000b002365d1f143amr15668495wre.364.1667412916761; 
 Wed, 02 Nov 2022 11:15:16 -0700 (PDT)
Received: from krug (87-196-82-28.net.novis.pt. [87.196.82.28])
 by smtp.gmail.com with ESMTPSA id
 o21-20020a05600c4fd500b003c71358a42dsm3366707wmq.18.2022.11.02.11.15.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 02 Nov 2022 11:15:16 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87r0ylh0y4.fsf@HIDDEN> (Philip Kaludercic's message of "Wed, 
 02 Nov 2022 14:42:59 +0000")
References: <87sfj8umwb.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
 <87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
Date: Wed, 02 Nov 2022 18:16:18 +0000
Message-ID: <877d0dql1p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Sorry Philip, but this is a very long email rehashing many things I've
addressed repeatedly.  I don't have anything to add.

I hope Dmitry installs the patch to project.el's
project-kill-buffer-conditions that he proposed so that this bug can be
closed.  Or some other patch like the ones I proposed.

Thanks for everything, I'm geting off the merry-go-round now.

Jo=C3=A3o

Philip Kaludercic <philipk@HIDDEN> writes:

[...snipped...]

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Juri Linkov <juri@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 03 Nov 2022 17:40:01 +0000
Resent-Message-ID: <handler.58839.B58839.166749718614049 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 58839 <at> debbugs.gnu.org
Cc: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166749718614049
          (code B ref 58839); Thu, 03 Nov 2022 17:40:01 +0000
Received: (at 58839) by debbugs.gnu.org; 3 Nov 2022 17:39:46 +0000
Received: from localhost ([127.0.0.1]:50402 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqeBu-0003eP-5J
	for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 13:39:46 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:39305)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <juri@HIDDEN>) id 1oqeBq-0003e8-L7
 for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 13:39:44 -0400
Received: (Authenticated sender: juri@HIDDEN)
 by mail.gandi.net (Postfix) with ESMTPSA id 6FCBE60006;
 Thu,  3 Nov 2022 17:39:33 +0000 (UTC)
From: Juri Linkov <juri@HIDDEN>
In-Reply-To: <86mt991dst.fsf@HIDDEN> (Juri Linkov's message of "Wed, 
 02 Nov 2022 19:32:02 +0200")
Organization: LINKOV.NET
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN> <877d0iw8iq.fsf@HIDDEN>
 <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN>
 <87a659u7vo.fsf@HIDDEN> <8735b1bvnz.fsf@HIDDEN>
 <87mt99spsk.fsf@HIDDEN> <87r0ylafdl.fsf@HIDDEN>
 <87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
 <86mt991dst.fsf@HIDDEN>
Date: Thu, 03 Nov 2022 19:30:13 +0200
Message-ID: <86o7tojda2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

> OTOH I completely support the request to make Eglot more resilient
> to unforeseeable situations.  Currently it's so brittle, so I get a lot
> of such errors all the time:
>
> Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
>   file-truename(nil)
>   eglot--path-to-uri(nil)
>   eglot--TextDocumentIdentifier()
>   eglot--signal-textDocument/didClose()
>   kill-buffer(#<buffer  *xref-temp*>)
>   xref--convert-hits(...)
>   xref-matches-in-files("word" ...)
>   project--find-regexp-in-files("word" ...)
>   apply(project--find-regexp-in-files ("word" ...))
>   xref--show-xref-buffer(...)
>   xref--show-xrefs(...)
>   xref-show-xrefs(...)
>   project-find-regexp("word")
>   funcall-interactively(project-find-regexp "word")
>   command-execute(project-find-regexp)

Here's a patch that fixes this:

diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
index c5870618372..5b05f84c63c 100644
--- a/lisp/progmodes/eglot.el
+++ b/lisp/progmodes/eglot.el
@@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode
   (unless eglot--managed-mode
     ;; Called when `revert-buffer-in-progress-p' is t but
     ;; `revert-buffer-preserve-modes' is nil.
-    (when (and buffer-file-name (eglot-current-server))
+    (when (and buffer-file-name
+               (not (string-match-p "\\` " (buffer-name)))
+               (eglot-current-server))
       (setq eglot--diagnostics nil)
       (eglot--managed-mode)
       (eglot--signal-textDocument/didOpen))))

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 03 Nov 2022 18:20:02 +0000
Resent-Message-ID: <handler.58839.B58839.16674995823276 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Juri Linkov <juri@HIDDEN>
Cc: 58839 <at> debbugs.gnu.org, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.16674995823276
          (code B ref 58839); Thu, 03 Nov 2022 18:20:02 +0000
Received: (at 58839) by debbugs.gnu.org; 3 Nov 2022 18:19:42 +0000
Received: from localhost ([127.0.0.1]:50604 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqeoY-0000qm-4M
	for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 14:19:42 -0400
Received: from mail-oi1-f174.google.com ([209.85.167.174]:40499)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1oqeoW-0000qY-J1
 for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 14:19:41 -0400
Received: by mail-oi1-f174.google.com with SMTP id n186so2850244oih.7
 for <58839 <at> debbugs.gnu.org>; Thu, 03 Nov 2022 11:19:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=BeArjrfNkZ4KeKSKpmyOSlIkMTPAGlJ/i67Abk1sjxo=;
 b=fqHyvmAJdUvbI4PTK8oNqLySC6ltK4gkA7T+Z2Xi1PmJd1PU9feP6FF0pdQ9F76S9c
 5vBkKb0+pBGN69nwk+RPUSi3AkMaQ6p/mCxOJ3XNOJ5hpFVSNHfPLBv4GoXzK4F6zH9O
 oTUsbVRICMoPfinx0lDnBFb0aEqI4A5/sJgN5A3lXX0q+0+IvBCcBCihIw2KoVvn7C7M
 UU38AK7cejvYr/KbQkoHJCMLk6uvFdVRaNy/9UmuEDJj/5elGv8gPUEJ6gxbgITVPK0D
 LS1pSayPkx24xENIZh60/O6lovho4HD1MxaOkThifHET+G5P7LKxHV9v5pRSOKaQmh0P
 LtJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=BeArjrfNkZ4KeKSKpmyOSlIkMTPAGlJ/i67Abk1sjxo=;
 b=DcHfUYverjSDr8sN0pZRWj+TrTs3ESlkWOQpQuVtBpXhCxVIc9SI3iX3QV69tlS+B6
 GS/PsbW1h4T9wsZPwaO3jfdpl2C+QboAvoOPVeGgr9s0ZafnR/MCMffHbWiz0yw9hxIq
 eTe+WUeq/oIi2ze9fppT+SLXcDW3H7BLz1tVBzG+njJjQH73svqO0+E9O/44wIijHzbv
 SVWOAjRG1x2oBTY6U+6heZlBqNDVA83r/a/aggkQRJeRHbUADwMfsJrDfZtDnvfCvHlD
 KZ3VIxUNgZZlKp38nhnfiEKH4bY62Y9BjeRIhtX5DrSOH9Uh2MvwO17eRs3+EOGuA9NI
 dXHA==
X-Gm-Message-State: ACrzQf0hU8J44OeAlFxHDcecsOgjKIMtdT0eT3bZAz6USgXXJewMe3ri
 EZezjX/15APWSEWzZrmkVB/yX5/SOInBTCGrzDE=
X-Google-Smtp-Source: AMsMyM6Xp1I6f/kK7AXaixelsiXpFK183sib/waUIHgyILLSqcfnyJn/gJUG+J9MCg/Qbqs4zB+OktK8s0XROqO3aS8=
X-Received: by 2002:a05:6808:a05:b0:35a:2a65:eb01 with SMTP id
 n5-20020a0568080a0500b0035a2a65eb01mr8552965oij.215.1667499573698; Thu, 03
 Nov 2022 11:19:33 -0700 (PDT)
MIME-Version: 1.0
References: <87sfj8umwb.fsf@HIDDEN> <87ilk2x1si.fsf@HIDDEN>
 <871qqq7l9p.fsf@HIDDEN> <87eduqwekz.fsf@HIDDEN>
 <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN> <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
 <87edunvhf2.fsf@HIDDEN> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
 <6c9811d7-ad05-2d2d-0c34-9b4c1fa09305@HIDDEN> <87a659u7vo.fsf@HIDDEN>
 <8735b1bvnz.fsf@HIDDEN> <87mt99spsk.fsf@HIDDEN>
 <87r0ylafdl.fsf@HIDDEN>
 <87cza5sbfx.fsf@HIDDEN> <87r0ylh0y4.fsf@HIDDEN>
 <86mt991dst.fsf@HIDDEN> <86o7tojda2.fsf@HIDDEN>
In-Reply-To: <86o7tojda2.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Thu, 3 Nov 2022 18:19:20 +0000
Message-ID: <CALDnm51U-aswy6TRfx4hG39tXe9gMiV_Z-WVr9C+abQrktSsdw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c0e51605ec94ffb8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

--000000000000c0e51605ec94ffb8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Juri, this doesn't seem right. Eglot shouldn't be turning itself on in
hidden buffers to start with: It's totally useless there.

So you have to explain an Emacs -Q recipe that demonstrates how Eglot
reached this nonsensical state. You haven't done that (or have you and i
have missed it?).

I tried project-find-regexp with Eglot-managed files with no problems, but
I have no idea what you're doing.

Also, this problem is totally off-topic here: this is about
project-kill-buffers. Please start as new issue of you haven't already.

Jo=C3=A3o

On Thu, Nov 3, 2022, 17:39 Juri Linkov <juri@HIDDEN> wrote:

> > OTOH I completely support the request to make Eglot more resilient
> > to unforeseeable situations.  Currently it's so brittle, so I get a lot
> > of such errors all the time:
> >
> > Debugger entered--Lisp error: (wrong-type-argument arrayp nil)
> >   file-truename(nil)
> >   eglot--path-to-uri(nil)
> >   eglot--TextDocumentIdentifier()
> >   eglot--signal-textDocument/didClose()
> >   kill-buffer(#<buffer  *xref-temp*>)
> >   xref--convert-hits(...)
> >   xref-matches-in-files("word" ...)
> >   project--find-regexp-in-files("word" ...)
> >   apply(project--find-regexp-in-files ("word" ...))
> >   xref--show-xref-buffer(...)
> >   xref--show-xrefs(...)
> >   xref-show-xrefs(...)
> >   project-find-regexp("word")
> >   funcall-interactively(project-find-regexp "word")
> >   command-execute(project-find-regexp)
>
> Here's a patch that fixes this:
>
> diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el
> index c5870618372..5b05f84c63c 100644
> --- a/lisp/progmodes/eglot.el
> +++ b/lisp/progmodes/eglot.el
> @@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode
>    (unless eglot--managed-mode
>      ;; Called when `revert-buffer-in-progress-p' is t but
>      ;; `revert-buffer-preserve-modes' is nil.
> -    (when (and buffer-file-name (eglot-current-server))
> +    (when (and buffer-file-name
> +               (not (string-match-p "\\` " (buffer-name)))
> +               (eglot-current-server))
>        (setq eglot--diagnostics nil)
>        (eglot--managed-mode)
>        (eglot--signal-textDocument/didOpen))))
>

--000000000000c0e51605ec94ffb8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Juri, this doesn&#39;t seem right. Eglot shouldn&#39;t be=
 turning itself on in hidden buffers to start with: It&#39;s totally useles=
s there.<div dir=3D"auto"><br></div><div dir=3D"auto">So you have to explai=
n an Emacs -Q recipe that demonstrates how Eglot reached this nonsensical s=
tate. You haven&#39;t done that (or have you and i have missed it?).</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">I tried project-find-regexp wi=
th Eglot-managed files with no problems, but I have no idea what you&#39;re=
 doing.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Also, this probl=
em is totally off-topic here: this is about project-kill-buffers. Please st=
art as new issue of you haven&#39;t already.</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">Jo=C3=A3o</div></div><br><div class=3D"gmail_quote"><d=
iv dir=3D"ltr" class=3D"gmail_attr">On Thu, Nov 3, 2022, 17:39 Juri Linkov =
&lt;<a href=3D"mailto:juri@HIDDEN">juri@HIDDEN</a>&gt; wrote:<br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">&gt; OTOH I completely support the reque=
st to make Eglot more resilient<br>
&gt; to unforeseeable situations.=C2=A0 Currently it&#39;s so brittle, so I=
 get a lot<br>
&gt; of such errors all the time:<br>
&gt;<br>
&gt; Debugger entered--Lisp error: (wrong-type-argument arrayp nil)<br>
&gt;=C2=A0 =C2=A0file-truename(nil)<br>
&gt;=C2=A0 =C2=A0eglot--path-to-uri(nil)<br>
&gt;=C2=A0 =C2=A0eglot--TextDocumentIdentifier()<br>
&gt;=C2=A0 =C2=A0eglot--signal-textDocument/didClose()<br>
&gt;=C2=A0 =C2=A0kill-buffer(#&lt;buffer=C2=A0 *xref-temp*&gt;)<br>
&gt;=C2=A0 =C2=A0xref--convert-hits(...)<br>
&gt;=C2=A0 =C2=A0xref-matches-in-files(&quot;word&quot; ...)<br>
&gt;=C2=A0 =C2=A0project--find-regexp-in-files(&quot;word&quot; ...)<br>
&gt;=C2=A0 =C2=A0apply(project--find-regexp-in-files (&quot;word&quot; ...)=
)<br>
&gt;=C2=A0 =C2=A0xref--show-xref-buffer(...)<br>
&gt;=C2=A0 =C2=A0xref--show-xrefs(...)<br>
&gt;=C2=A0 =C2=A0xref-show-xrefs(...)<br>
&gt;=C2=A0 =C2=A0project-find-regexp(&quot;word&quot;)<br>
&gt;=C2=A0 =C2=A0funcall-interactively(project-find-regexp &quot;word&quot;=
)<br>
&gt;=C2=A0 =C2=A0command-execute(project-find-regexp)<br>
<br>
Here&#39;s a patch that fixes this:<br>
<br>
diff --git a/lisp/progmodes/eglot.el b/lisp/progmodes/eglot.el<br>
index c5870618372..5b05f84c63c 100644<br>
--- a/lisp/progmodes/eglot.el<br>
+++ b/lisp/progmodes/eglot.el<br>
@@ -1792,7 +1792,9 @@ eglot--maybe-activate-editing-mode<br>
=C2=A0 =C2=A0(unless eglot--managed-mode<br>
=C2=A0 =C2=A0 =C2=A0;; Called when `revert-buffer-in-progress-p&#39; is t b=
ut<br>
=C2=A0 =C2=A0 =C2=A0;; `revert-buffer-preserve-modes&#39; is nil.<br>
-=C2=A0 =C2=A0 (when (and buffer-file-name (eglot-current-server))<br>
+=C2=A0 =C2=A0 (when (and buffer-file-name<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not (string-match-=
p &quot;\\` &quot; (buffer-name)))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot-current-serv=
er))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(setq eglot--diagnostics nil)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot--managed-mode)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0(eglot--signal-textDocument/didOpen))))<br>
</blockquote></div>

--000000000000c0e51605ec94ffb8--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 04 Nov 2022 01:14:01 +0000
Resent-Message-ID: <handler.58839.B58839.166752439820896 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, manuel.uberti@HIDDEN, 58839 <at> debbugs.gnu.org
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166752439820896
          (code B ref 58839); Fri, 04 Nov 2022 01:14:01 +0000
Received: (at 58839) by debbugs.gnu.org; 4 Nov 2022 01:13:18 +0000
Received: from localhost ([127.0.0.1]:51055 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqlGo-0005Qy-2n
	for submit <at> debbugs.gnu.org; Thu, 03 Nov 2022 21:13:18 -0400
Received: from mail-wr1-f42.google.com ([209.85.221.42]:34609)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1oqlGl-0005Qh-UB
 for 58839 <at> debbugs.gnu.org; Thu, 03 Nov 2022 21:13:17 -0400
Received: by mail-wr1-f42.google.com with SMTP id k8so5130198wrh.1
 for <58839 <at> debbugs.gnu.org>; Thu, 03 Nov 2022 18:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:from:to:cc:subject:date:message-id:reply-to;
 bh=ZEppwYF455OSCQA5rYM0nS02Nn+JiRs1M5r0mRuBOvo=;
 b=RTuIxQIaTDENLz6dLbXBt+3AGOusKrkkHNmtDNEJg//xcSbVnO8PsU/MxyvHnujI4D
 9DuMW/tFLHRd7WW5gm8AB3G5G67QdBTULwbw/3XaYCE3wT1HYEDzm3fjZfejpjThAxrP
 GNZlqwpHr7CfKIZ2GII8Jv5HwWCx4DiomJ/eFHjF2CYBt1o29DJHVXRmwNumAcMtRR2r
 55o7U83o7oJVjLMLn+hEdIQi5E5a2rvD8YM0l+glf6dD32oBR06GIwoTKeolE3hdy+Sh
 7HJJpab/muaGy52JPiqQrrB9tpVviH70Idt5B+v7GFPhXlgd1LstHfg/krIlKnrvy4Nn
 hMbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:from:references:cc:to
 :content-language:subject:user-agent:mime-version:date:message-id
 :sender:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=ZEppwYF455OSCQA5rYM0nS02Nn+JiRs1M5r0mRuBOvo=;
 b=Sk+4kjY4ZiSov6Cz0X0PHdYDbe4VypgmStJaEqZ0zU2R18OZXP4Wknm7NCRDCd00KM
 GJ2xZZHTsw6GdGGjYJS/qwZLzmStMYVqLi5vnuIgx9myZrnekdxToi0mOhqcFQjcIi43
 i28hxaVPrR0bulScFcb3ro9uUWFrOngL4M9cBGBjcQ+nAUHEJ+kKcekf8Nk8/+npDic4
 7IajxCh+UFAst+kr81cVHqOaukzr4JmoqB45jIEiWshZWgt5OE7b33ZKmn/IC3TJtecK
 9ILU/QcXzMmdGLcqC/2wefeQw+jfwFH6gOy1lZ2T8goqF0qpGgZe35gdjxahMfZjVHFz
 iOpg==
X-Gm-Message-State: ACrzQf1qmo50Fy0n+39vxfBAgbm25cn4SIFnx0/azkFRP6MSUPKhUrdD
 rVdJqTIBGhKVJV8Eh9wtmog=
X-Google-Smtp-Source: AMsMyM59xIWy7PCi7tm+hUkrQEoy0fFdz4vxC4gdJu6NTswGqHnf5Nl09oFGiO6H9gwVHQcG3hABOA==
X-Received: by 2002:a5d:554e:0:b0:236:ccf1:f958 with SMTP id
 g14-20020a5d554e000000b00236ccf1f958mr16374894wrw.378.1667524389794; 
 Thu, 03 Nov 2022 18:13:09 -0700 (PDT)
Received: from [192.168.0.6] ([46.251.119.176])
 by smtp.googlemail.com with ESMTPSA id
 bu14-20020a056000078e00b0022cdb687bf9sm2967834wrb.0.2022.11.03.18.13.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 03 Nov 2022 18:13:09 -0700 (PDT)
Message-ID: <3922d5b4-4afb-e8b9-7b31-11a818c0b751@HIDDEN>
Date: Fri, 4 Nov 2022 03:13:07 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Content-Language: en-US
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN> <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN> <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN> <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN> <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> <87edunvhf2.fsf@HIDDEN>
 <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@HIDDEN>
 <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
In-Reply-To: <CALDnm50jPXm+553ddW_EFB2x0Z+AEsAY0X47MQMTw3MLkLju8w@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

On 01.11.2022 13:36, João Távora wrote:
> On Mon, Oct 31, 2022 at 10:51 PM Dmitry Gutov <dgutov@HIDDEN 
> <mailto:dgutov@HIDDEN>> wrote:
> 
>  > I suggest you try it first.
> 
> It works in my test
> 
>  > Disaster, really?
> 
> The reason I came about the Gnus problem was when using it
> to reply to some emails here and trying out the C-x p k and finding out
> all my Gnus buffers were gone.

I have now pushed the proposed fix, as well as an additional change to 
except Gnus modes (not sure it will be enough -- there might be 
background buffers using some modes that don't derive -- but it seems to 
help in my brief testing).

That's not to mark a final decision, but to fix the immediate issues, 
and to remember them in the code.

The question now is how to better handle packages and features that are 
similar to Gnus in that regard. One alternative option would be to add a 
var through which such modes could opt-out (rather than opt-in). It 
seems more likely that we won't have to update 
project-kill-buffer-conditions often then.

A whitelisting approach seems cleaner/safer, though.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running
Resent-From: "Basil L. Contovounesios" <contovob@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 04 Nov 2022 11:22:01 +0000
Resent-Message-ID: <handler.58839.B58839.166756089127409 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58839
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: philipk@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 58839 <at> debbugs.gnu.org, manuel.uberti@HIDDEN, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Received: via spool by 58839-submit <at> debbugs.gnu.org id=B58839.166756089127409
          (code B ref 58839); Fri, 04 Nov 2022 11:22:01 +0000
Received: (at 58839) by debbugs.gnu.org; 4 Nov 2022 11:21:31 +0000
Received: from localhost ([127.0.0.1]:51919 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1oqulP-00077z-5I
	for submit <at> debbugs.gnu.org; Fri, 04 Nov 2022 07:21:31 -0400
Received: from mail-ej1-f51.google.com ([209.85.218.51]:36822)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <contovob@HIDDEN>) id 1oqulK-00077i-CS
 for 58839 <at> debbugs.gnu.org; Fri, 04 Nov 2022 07:21:28 -0400
Received: by mail-ej1-f51.google.com with SMTP id 13so12477510ejn.3
 for <58839 <at> debbugs.gnu.org>; Fri, 04 Nov 2022 04:21:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
 bh=1A57DIGaEHch7sEXUCPK+/5QZEfW9G1KZIMGQfHo36o=;
 b=PCG8wNE2h8Z2CFXrXFsYs1QS8Of1Cl3RAXNYv1UQp23l0yIGm3AED5j1Ixc5HTAhEr
 ji0rKJiSgb6XW2VfOgTquY70XlxlOpmOQvldO90j8meRbKwY7t06oP0JykJ6eTf1RhVX
 kl0r18gCb9Yc+LZAZW1xOFf77hl7wJh/c4g00MZmE2HFjhax/Jnhdz7N/EuOTKYa4+2Q
 VXRAi+5kP3VMplQdieplvmY+dOgpZ2LpWGevF3ECpQKdCz8pthNCnaOLVOb++22afrd7
 WW5sdEX+YfLg/K5LLFzhsJeKt2qlfJmX8GLVu2CY91JQW7d9796fpThyIvN+luJCCdI3
 ra2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=mime-version:user-agent:message-id:date:references:in-reply-to
 :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
 :message-id:reply-to;
 bh=1A57DIGaEHch7sEXUCPK+/5QZEfW9G1KZIMGQfHo36o=;
 b=tileF0Qm+ef884objC5ydvYpSuCp2Ytu5HG4hYoN4af4H0DjWtOvvBHk1GhQ3TzAB9
 C4KpFM0wZSDrYktMrKyRyGs3lQ5Xx0qCG50a2+oX1wt+iCKnMrbtM5Ex50GgGwPaiHga
 C+Pip3lBCZWqMl7pCrnltufx0mPmchj1a8CSmGUaKrj4orR5vzU0gu0iF7csJTBRVFNv
 dh5JZxCVF4cjFogeoyAb+AbPMyLt6eVDHt+TIYX/WjVwi8k4vy8S7zyjmmj6cePr+6CB
 ozlDNEIdoVNHNxSWpTv3zEZPKjRqH9PPfbIm5ENIrH0Qk2t0qDGLb8KifLzfjvUNcSMS
 SGbw==
X-Gm-Message-State: ACrzQf1bM/imOLBqgkzzkSF70aQDiXcKgf2KFjJTm2QnHouV5hmaHXeB
 K+fL89zLvxJvzz2hGyIKr8Q5aQ==
X-Google-Smtp-Source: AMsMyM7r8GbZT61l+vs8PX6BpNhCb6CjsbfanstbiNMn4/XuSFMp64GlwvOe7qIBzMCtW9eX71NlLw==
X-Received: by 2002:a17:907:7e81:b0:7ad:e144:19e5 with SMTP id
 qb1-20020a1709077e8100b007ade14419e5mr22954411ejc.51.1667560880102; 
 Fri, 04 Nov 2022 04:21:20 -0700 (PDT)
Received: from localhost ([2a02:587:320c:8829:23:8156:16ed:40c2])
 by smtp.gmail.com with ESMTPSA id
 q21-20020a17090676d500b0073de0506745sm1650543ejn.197.2022.11.04.04.21.18
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 04 Nov 2022 04:21:19 -0700 (PDT)
From: "Basil L. Contovounesios" <contovob@HIDDEN>
In-Reply-To: <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Oct 2022 19:24:02 +0200")
References: <87sfj8umwb.fsf@HIDDEN>
 <CALDnm53uLpMHTCwBVrh4nWj3rzp+ycQcMxZ7HAob3SPiO2urTA@HIDDEN>
 <87edur3lil.fsf@HIDDEN>
 <aa1f7010-a456-286c-0cfa-26f0455733c5@HIDDEN>
 <87a65f3j40.fsf@HIDDEN>
 <213f3549-de4e-25a7-5e27-d13893e557bc@HIDDEN>
 <87zgdfwkle.fsf@HIDDEN>
 <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@HIDDEN>
 <87v8o3wgq1.fsf@HIDDEN>
 <ba230c2f-020b-2130-28fb-8ccf757996e3@HIDDEN>
 <87ilk2x1si.fsf@HIDDEN> <871qqq7l9p.fsf@HIDDEN>
 <87eduqwekz.fsf@HIDDEN> <87wn8invbx.fsf@HIDDEN>
 <877d0iw8iq.fsf@HIDDEN> <837d0hhlke.fsf@HIDDEN>
 <46ff0065-5645-ef1e-2621-242fb6a73f98@HIDDEN>
 <87v8o0uxn5.fsf@HIDDEN>
 <787a4362-7ff5-7dbb-9118-16e4bee5f328@HIDDEN>
Date: Fri, 04 Nov 2022 13:21:17 +0200
Message-ID: <871qqj55jm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov [2022-10-31 19:24 +0200] wrote:

> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index ac278edd40..1e7573c740 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -1223,7 +1223,9 @@ project-display-buffer-other-frame
>  (defcustom project-kill-buffer-conditions
>    '(buffer-file-name    ; All file-visiting buffers are included.
>      ;; Most of the temp buffers in the background:
> -    (major-mode . fundamental-mode)
> +    (and
> +     (major-mode . fundamental-mode)
> +     (not "\\` "))

AKA "\\`[^ ]" here and elsewhere, FWIW.

Thanks,

-- 
Basil

Last modified: Fri, 4 Nov 2022 11:30:02 UTC

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