From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Sat, 29 Oct 2022 23:49:01 +0100 Message-ID: <877d0iw8iq.fsf@gmail.com> References: <87sfj8umwb.fsf@posteo.net> <87edur3lil.fsf@posteo.net> <87a65f3j40.fsf@posteo.net> <213f3549-de4e-25a7-5e27-d13893e557bc@yandex.ru> <87zgdfwkle.fsf@gmail.com> <8e31a89d-e35e-6dd0-a8e3-f0b9684c8bfa@yandex.ru> <87v8o3wgq1.fsf@gmail.com> <87ilk2x1si.fsf@gmail.com> <871qqq7l9p.fsf@posteo.net> <87eduqwekz.fsf@gmail.com> <87wn8invbx.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Manuel Uberti , 58839@debbugs.gnu.org, Dmitry Gutov To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 30 00:49:24 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ooudn-0009Io-Md for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 30 Oct 2022 00:49:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooudU-0003mM-HL; Sat, 29 Oct 2022 18:49:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooudS-0003lw-T4 for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ooudS-0003Z4-Le for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ooudS-00045B-4c for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 18:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Oct 2022 22:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58839 X-GNU-PR-Package: emacs Original-Received: via spool by 58839-submit@debbugs.gnu.org id=B58839.166708368315574 (code B ref 58839); Sat, 29 Oct 2022 22:49:02 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 22:48:03 +0000 Original-Received: from localhost ([127.0.0.1]:36849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooucU-000435-Te for submit@debbugs.gnu.org; Sat, 29 Oct 2022 18:48:03 -0400 Original-Received: from mail-wr1-f45.google.com ([209.85.221.45]:39541) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooucQ-00041p-Pv for 58839@debbugs.gnu.org; Sat, 29 Oct 2022 18:48:02 -0400 Original-Received: by mail-wr1-f45.google.com with SMTP id o4so11056134wrq.6 for <58839@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) Original-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) In-Reply-To: <87wn8invbx.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 29 Oct 2022 22:01:06 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246576 Archived-At: Philip Kaludercic 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.