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#42386: Acknowledgement ([PATCH] Handle symbols in project-kill-buffers-ignores) Date: Sat, 18 Jul 2020 01:21:47 +0300 Message-ID: <0c296186-702e-576d-a609-b3028d093def@yandex.ru> References: <878sfjkh8o.fsf@warpmail.net> <87pn8udpur.fsf@warpmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28021"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: 42386@debbugs.gnu.org To: "Philip K." Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 18 00:22:55 2020 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 1jwYkC-0005kj-BO for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 18 Jul 2020 00:22:16 +0200 Original-Received: from localhost ([::1]:36540 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwYk4-0008G3-9E for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 17 Jul 2020 18:22:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37626) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwYjy-0008Fx-1P for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 18:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46591) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jwYjx-0003Fv-OW for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 18:22:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jwYjx-0007j9-Jl for bug-gnu-emacs@gnu.org; Fri, 17 Jul 2020 18:22: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: Fri, 17 Jul 2020 22:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42386 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 42386-submit@debbugs.gnu.org id=B42386.159502451929695 (code B ref 42386); Fri, 17 Jul 2020 22:22:01 +0000 Original-Received: (at 42386) by debbugs.gnu.org; 17 Jul 2020 22:21:59 +0000 Original-Received: from localhost ([127.0.0.1]:58137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwYjv-0007it-Fp for submit@debbugs.gnu.org; Fri, 17 Jul 2020 18:21:59 -0400 Original-Received: from mail-ed1-f65.google.com ([209.85.208.65]:43766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwYjs-0007ic-EN for 42386@debbugs.gnu.org; Fri, 17 Jul 2020 18:21:59 -0400 Original-Received: by mail-ed1-f65.google.com with SMTP id a1so8808914edt.10 for <42386@debbugs.gnu.org>; Fri, 17 Jul 2020 15:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0O5UJ7iykIdUUS/L3mB+fFBM+63ldgfJGaQ38+WPW5E=; b=G3Cl5uVRil4YoXk7TFHYZG4y8GKwW6+RmtOqevBm1GHl2LRAcV3aSAiHAlIn7kLuVx 8GOgjzKtXTbtgDE7V8VpBvmdXAswqUDYFXZKMqM9adDppKIBut2pgY4WFCoKaOhCn1GH wiL6uhh75dezu46WP3DHw4kkxFgYCRb9vMWvtSBphnp83AIgyeQa2foGK95kb6CjPSHq GBgPy/2TiiXKad3TBDBnXMpDvXNYejcxvwvEbB2FnHnjYymw8/kNYlA+rTiX/2GKxOvd Xttecd5yB1WsZ1kE00Hs6aVJPERTAVRyNxNT2qcDoTjPDjIjBJIwipZbRsWBL3LYX6yM 6VsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0O5UJ7iykIdUUS/L3mB+fFBM+63ldgfJGaQ38+WPW5E=; b=GJtNRHI0nhac2Pquy5Z4Z6d7RQuNv3aJoA3YDkIpkeqSUbj5YuxwO0QbzBCqZ/YzVm 4jiPaXT+2Cleketlx+Il00GvBpPSc/d3XLpPQ1WWY+hXoLBVBy1F2sCuB8M2mQK5Wt12 7njK92pb7of0kCmTbMWTZ5+z4hjiXXQvff+sR9/ZIuwchMggL9OtSgbQ5fiEVHkvusHv nOff11FVGbA2O1yAIA+dgp6F92qbdP1PFU7xVCo/sAkGljtuUu4FBW1bH0c4H2U4vG0k o1mGw2OPFHf1C649twI2gpxO39IlA7QL7PYYuVKfoVJRYbAsE5kaiYmK+NCc2Hbm+2db L9aQ== X-Gm-Message-State: AOAM532dsXCHaUOMrltOG+fdsXJmxFzeS3ha9Yqbx7xM1wpIyIlPr96e 3lvBcFXV50/cC1lYtQx3u/RPozIm X-Google-Smtp-Source: ABdhPJxrf2pJm0RHOiB9lhyfsO1J9K4DWgxlTjZD/sDPfIQRril7lQ5ZnKoJfBIM+sZe9Hn0jWYBog== X-Received: by 2002:a05:6402:b9b:: with SMTP id cf27mr11601609edb.84.1595024510146; Fri, 17 Jul 2020 15:21:50 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id l22sm8909867ejr.98.2020.07.17.15.21.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Jul 2020 15:21:49 -0700 (PDT) In-Reply-To: <87pn8udpur.fsf@warpmail.net> Content-Language: en-US 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:183162 Archived-At: On 17.07.2020 20:16, Philip K. wrote: > Dmitry Gutov writes: > >> On 17.07.2020 18:30, Philip K. wrote: >>> (defcustom project-kill-buffers-ignores >>> '("\\*Help\\*") >> >> You might as well update the default value. > > So what should be added, besides ERC? Probably nothing, unless you have something else to propose. At this point, you are the main driver of this feature. I like it in theory (a lot), but so far has done little to incorporate in my workflow, so you're the foremost person to hit the edge cases. I also don't do email/IRC/notes/etc in Emacs. Speaking of some ideas, though, if you are worried about more unknown modes needing the same treatment, we could flip the meaning of this var and go with the whitelist approach, like font-lock-global-modes does. It can still serve as a blacklist if the first element is `not`. To give an example: (defcustom project-kill-buffers-conditions '(buffer-file-name ; All file-visiting buffers are included. (derived-mode . compilation-mode) ;; Most of the temp buffers in the background: (major-mode . fundamental-mode) ;; A bit questionable (alternatively, include ;; xref--xref-buffer-mode, occur-mode, ;; vc-dir-mode, log-view-mode, log-edit-mode separately): (derived-mode . special-mode)) "Conditions for buffers `project-kill-buffers' should kill. Each condition is either a regular expression matching a buffer name, or a predicate function that takes a buffer object as argument and returns non-nil if it matches, or a cons cell which <...>. Buffers that belong to the current project, and match any of the conditions, will be killed. If the list starts with `not', the meaning is negated." :type '(repeat (choice regexp function)) :version "28.1" :package-version '(project . "0.6.0")) If this kind of list can be exhaustive enough, this can be a decent default. What do you think? If you're not sure, let's go with your patch now. >> Or I wonder if you should just use memq in the implementation. > > I tried to find out what major-mode hierarchies exist on my system, so I > wrote > > (let (tree) > (dolist (f features) > (require f)) > (mapatoms > (lambda (a) > (let ((p (get a 'derived-mode-parent))) > (when p > (push (cons p a) > tree))))) > (with-temp-buffer > (insert "digraph {\n") > (dolist (node tree) > (insert (format "\"%s\" -> \"%s\";\n" (car node) (cdr node)))) > (insert "}\n") > (write-file "dep.dot") > (shell-command "dot -Tpng dep.dot > dep.png") > (delete-file "dep.dot"))) > > that generated an image of a tree. It seems it's mostly flat, meaning > that a majority of the major modes are based on prog-mode, text-mode or > special-mode. All further levels seem to be connected, such as with > magit or gnus. So while I get that someone might not find it intuitive > that major modes other than the one listed are not killed, I think a > generous interpretation is better than killing more than one might want. Fair enough. Or we could provide both kinds of checks, like in the example above (major-mode vs derived-mode). >> Both font-lock-global-modes and desktop-modes-not-to-save are not >> applied to derivatives. > > Hmm, I didn't know about that. As explained, just from looking at my > system, taking derivations into consideration appears to have more > advantages than disadvantages, but I'm not dogmatic on that point. I don't know which is the best approach either.