From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Theodor Thornhill Newsgroups: gmane.emacs.devel Subject: Re: master 1e3b0f2: Improve doc strings of project.el Date: Fri, 19 Jun 2020 17:46:36 +0000 Message-ID: <877dw3ne2z.fsf@thornhill.no> References: <87bllfqj82.fsf@warpmail.net> <83o8pfxhzq.fsf@gnu.org> <83imfnxgt3.fsf@gnu.org> <83eeqbxevp.fsf@gnu.org> <87bllfnjy5.fsf@thornhill.no> <83d05vx9or.fsf@gnu.org> Reply-To: Theodor Thornhill Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="85687"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jun 19 19:48:31 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 1jmL7v-000MDJ-OV for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 19:48:31 +0200 Original-Received: from localhost ([::1]:46588 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmL7u-0003ht-QH for ged-emacs-devel@m.gmane-mx.org; Fri, 19 Jun 2020 13:48:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40124) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmL6B-0001MW-Py for emacs-devel@gnu.org; Fri, 19 Jun 2020 13:46:44 -0400 Original-Received: from mail2.protonmail.ch ([185.70.40.22]:23217) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmL69-0002Va-2J; Fri, 19 Jun 2020 13:46:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail; t=1592588798; bh=ZnSOXRSodgj0hDS/NZYDBUVLxtbAJIgoXlSPF+FWd7U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=lu5EqzyV5juB+M9paK+UqxppTcqMylj5PjSkWWXjKJKnVrmqcLIdVZbtonmrgc2HO VQYsL8Qr4OjK2nQfBEIuBaQ8oIK/96hbQDXU4ajV5/l4SduB85I4zuxU2tNsUeH371 wnD0em/8Di69aC1HUUkF2BRKAk59Y4Jyr3Wd9ZTBtRz/GFU5BY6y9cyO0vBpyA4UuW 4+7jZMDbfkMpnJbXMlhOWNBho8QqVSq8UnQwCif5rOeDpn/xZmh2T07jap2Vl0dYNf phraZYCKBDCi5PuKb05RJ9I82dEWnJTQ40jwXPodxe4FLI9WTVrMUayqR1XF2B4Xgp +pYRzKNzs8bXg== In-Reply-To: <83d05vx9or.fsf@gnu.org> Received-SPF: pass client-ip=185.70.40.22; envelope-from=theothornhill@pm.me; helo=mail2.protonmail.ch X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/19 13:46:38 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -37 X-Spam_score: -3.8 X-Spam_bar: --- X-Spam_report: (-3.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:252384 Archived-At: >> >> Or am I misunderstanding you? > > Maybe. I don't think I understand what you are suggesting in enough > detail to tell. For a project of any kind (vc, major-mode-based, or any concept you can think of) to decide what buffers are useful we need some set of information about the project. If as you say, a text-mode based project only should show buffers of say, org-mode, markdown etc, and exclude buffers generated by org-babel or something, we need to place that knowledge somewhere. This knowledge is in part stored in 'project-ignores', where we can ignore patterns such as "assets" "node_modules" etc. without it needing to be put in a .gitignore [1]. However, then we lose the optimized search functionalities offered by the "(head vc)" implementation in project.el. If for instance the project-switch-to-buffer should have to know everything about every imaginable combination of interesting derivates of a project, then I believe that would be a quite a bit larger function (or at least a huge curated map of sorts). What I am thinking, surely without knowing all the intricacies here, is that maybe the "switch-to-buffer" and "kill-buffers" also should be defgenerics? Then the implementation of what to show can be put off for later, and the "(head vc)" version can be decided now? Otherwise, I guess the user has to specify a set of patterns, or at least decide on major-modes to include, and that would seem like a hassle to me. I may be overthinking this, but it would be nice if "switch-to-buffer" only would be a "brainless" buffer-picker with only useful choices. Theo [1]: If we choose to implement our own notion of a project.