From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Tue, 1 Nov 2022 21:50:17 +0200 Message-ID: <39e79ad3-66df-3aa9-cc3f-c5868bfbc6a2@yandex.ru> References: <87sfj8umwb.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> <877d0iw8iq.fsf@gmail.com> <837d0hhlke.fsf@gnu.org> <46ff0065-5645-ef1e-2621-242fb6a73f98@yandex.ru> <87v8o0uxn5.fsf@gmail.com> <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> <87edunvhf2.fsf@gmail.com> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@yandex.ru> <87tu3jgdbv.fsf@posteo.net> <87h6zihq3q.fsf@posteo.net> <87bkpqecpv.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12694"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Cc: Eli Zaretskii , 58839@debbugs.gnu.org, manuel.uberti@inventati.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 01 20:51:22 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 1opxI8-00033A-Og for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 01 Nov 2022 20:51:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1opxHt-0005tW-Lo; Tue, 01 Nov 2022 15:51:05 -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 1opxHq-0005tB-GJ for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 15:51: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 1opxHq-0004TU-8g for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 15:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1opxHp-00084U-NI for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 15:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2022 19:51:01 +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.166733223230990 (code B ref 58839); Tue, 01 Nov 2022 19:51:01 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 1 Nov 2022 19:50:32 +0000 Original-Received: from localhost ([127.0.0.1]:44273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opxHL-00083m-F6 for submit@debbugs.gnu.org; Tue, 01 Nov 2022 15:50:31 -0400 Original-Received: from mail-wr1-f48.google.com ([209.85.221.48]:34437) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opxHF-00083O-TS for 58839@debbugs.gnu.org; Tue, 01 Nov 2022 15:50:30 -0400 Original-Received: by mail-wr1-f48.google.com with SMTP id k8so21616106wrh.1 for <58839@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) Original-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) Content-Language: en-US In-Reply-To: <87bkpqecpv.fsf@posteo.net> 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:246806 Archived-At: 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.