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 13:16:45 +0100 Message-ID: <87ilk2x1si.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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36283"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Philip Kaludercic , 58839@debbugs.gnu.org, Manuel Uberti To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 29 14:16:44 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 1ooklX-0009Ao-V1 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Oct 2022 14:16:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ookl0-0004NT-Bs; Sat, 29 Oct 2022 08:16:11 -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 1ookku-0004Lu-RU for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:16:04 -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 1ookks-0007Ly-MZ for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:16:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ookks-0007Qj-DV for bug-gnu-emacs@gnu.org; Sat, 29 Oct 2022 08:16: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 12:16: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.166704574428525 (code B ref 58839); Sat, 29 Oct 2022 12:16:02 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 29 Oct 2022 12:15:44 +0000 Original-Received: from localhost ([127.0.0.1]:35095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ookka-0007Py-8L for submit@debbugs.gnu.org; Sat, 29 Oct 2022 08:15:44 -0400 Original-Received: from mail-wm1-f53.google.com ([209.85.128.53]:35426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ookkY-0007Pk-19 for 58839@debbugs.gnu.org; Sat, 29 Oct 2022 08:15:43 -0400 Original-Received: by mail-wm1-f53.google.com with SMTP id m29-20020a05600c3b1d00b003c6bf423c71so8075235wms.0 for <58839@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) Original-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) In-Reply-To: (Dmitry Gutov's message of "Sat, 29 Oct 2022 14:27:31 +0300") 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:246520 Archived-At: Dmitry Gutov 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