From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 2ab66c9: Replace project-kill-buffers-ignores with project-kill-buffer-conditions Date: Sun, 06 Sep 2020 23:24:52 -0400 Message-ID: References: <87ft7ueg4g.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="2160"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, dgutov@yandex.ru To: "Philip K." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Sep 07 05:25:45 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kF7mq-0000Qy-KB for ged-emacs-devel@m.gmane-mx.org; Mon, 07 Sep 2020 05:25:44 +0200 Original-Received: from localhost ([::1]:37992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kF7mp-0002oq-LC for ged-emacs-devel@m.gmane-mx.org; Sun, 06 Sep 2020 23:25:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kF7m8-0002I0-3p for emacs-devel@gnu.org; Sun, 06 Sep 2020 23:25:00 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10106) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kF7m5-00010y-L6 for emacs-devel@gnu.org; Sun, 06 Sep 2020 23:24:59 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2A78F100257; Sun, 6 Sep 2020 23:24:56 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1714D10022F; Sun, 6 Sep 2020 23:24:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1599449094; bh=on0d00pEz7sCK79gKxmVFykYhfDEtXs4yLqHPyGFRuY=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=KhRt/TdK9g+2sEPGHz4fsSFJNekXbjOBE8NCANbZOwczXG75x0wIGfuvnDc1h8Wup /wiSsejZtcPogJi3cBRWNkP9JfctwWqhSGHaerfGyw5GbVG906YabcEnEpomZSVpif doN714zRi9AaYq82PJzpKlGwGJWCF98EfHcbv0tm/FgfYMaiv/rVbVahxg9lSzCi8D y9j1JzIn3Q9uzyJQP3Q5+Yu41z0WQbds9MivW0sAqeEQWSfTB5V45ir7R92UnL+0Sl daIOmvha3FfAdUhgHnqSsOlPnnq0Ti0UKkKdbOeJk3xHJNdRzAa2EF/8xyDOAA7wo8 pzAsjZvbL2sjA== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C33521203DF; Sun, 6 Sep 2020 23:24:53 -0400 (EDT) In-Reply-To: <87ft7ueg4g.fsf@posteo.net> (Philip K.'s message of "Sun, 06 Sep 2020 23:42:55 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/06 23:24:56 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254609 Archived-At: > Of course, but the main problem seems to be to decide which solution to > pick. The code (project--kill-buffer-check and project--buffers-to-kill) > is already close-to generic enough to be easily moved around. I think instead that the main problem is to make use of that code in places which currently use another code, and deal with the corresponding potential incompatibilities. Once that's done, we can try and figure out where is the best place for that generic code (if not project.el) and how to make it work for GNU ELPA packages like project.el. There are many different acceptable options there (including keeping a backward-compatibility copy of that generic code in project.el, or placing it into a separate GNU ELPA package added as a new dependency, ...). I think it'll be pretty easy to solve. Stefan