From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 20 Jun 2020 15:25:30 +0300 Message-ID: <83zh8xvs91.fsf@gnu.org> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <626efe11-0f9c-081b-11dd-0d61cee8168d@yandex.ru> <83h7v7xf7w.fsf@gnu.org> <831rmayj55.fsf@gnu.org> <6dc2c2ac-8e17-f044-dc78-8c109f936ad2@yandex.ru> <83wo42w83e.fsf@gnu.org> <83a70yw1y8.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="78559"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philip@warpmail.net, theothornhill@pm.me, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jun 20 14:26:30 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 1jmcZq-000KLl-FX for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 14:26:30 +0200 Original-Received: from localhost ([::1]:33918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmcZp-0002TF-Bm for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 08:26:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35142) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmcZ4-0001OO-A5 for emacs-devel@gnu.org; Sat, 20 Jun 2020 08:25:42 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38529) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmcZ2-0001x4-O7; Sat, 20 Jun 2020 08:25:40 -0400 Original-Received: from [176.228.60.248] (port=4104 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmcZ2-0000IG-49; Sat, 20 Jun 2020 08:25:40 -0400 In-Reply-To: (message from Dmitry Gutov on Sat, 20 Jun 2020 14:29:20 +0300) 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:252437 Archived-At: > Cc: philip@warpmail.net, emacs-devel@gnu.org > From: Dmitry Gutov > Date: Sat, 20 Jun 2020 14:29:20 +0300 > > On 20.06.2020 11:55, Eli Zaretskii wrote: > > I proposed to find a different way of telling which buffer is related > > to a project, other than by looking at its default-directory. We > > could design a way of doing that which would then support adding > > buffers to a project quite easily. But Dmitry doesn't think we should > > go that way. > > If you can outline and propose that alternative way, I'm all for > considering it. I think I did. And I don't really understand what is being requested here. Recording something in a variable, be it a buffer-local one or a global one indexed by a project, is easy, and doesn't require any complicated design. I'm talking as a user here, asking you to support what I think is a very common usage pattern of working on some programming problem that involves changes in a group of related files. > Compared to an ad-hoc variable (or having a command that adds such a > buffer manually), I'd much prefer an automatic approach. Not sure what does "automatic" mean here. If that means using only currently available buffer-local variables, then who's to say that this is good enough? Why limit ourselves to only such solutions? the few presented examples already uncovered some deficiencies in relying on one such variable. OTOH, we could introduce a new buffer-local variable to be automatically set by, say, a find-file-hook, or by project-find-file, or via some other feature we have. Same with recording relevant buffers in some project-specific data structure. IOW, it sounds like we have any number of ways for doing something like that, and the only argument is whether we should.