From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: master 1e3b0f2: Improve doc strings of project.el Date: Sat, 20 Jun 2020 22:55:35 +0000 (UTC) Message-ID: <045712ee-02de-4cdf-b33a-a617644792af@default> 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>> <<6762abf5-71c1-aa54-1bac-d4c90c20870b@yandex.ru>> <<831rmavsuq.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="50592"; mail-complaints-to="usenet@ciao.gmane.io" Cc: philip@warpmail.net, theo@thornhill.no, emacs-devel@gnu.org To: Eli Zaretskii , Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jun 21 00:58:28 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 1jmmRP-000D0v-V0 for ged-emacs-devel@m.gmane-mx.org; Sun, 21 Jun 2020 00:58:28 +0200 Original-Received: from localhost ([::1]:58156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmmRP-0008Cp-0f for ged-emacs-devel@m.gmane-mx.org; Sat, 20 Jun 2020 18:58:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40352) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmmQn-0007Ot-Ny for emacs-devel@gnu.org; Sat, 20 Jun 2020 18:57:49 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:57856) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmmQl-0000rJ-98; Sat, 20 Jun 2020 18:57:49 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05KMrU3V156834; Sat, 20 Jun 2020 22:57:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=FMZTALDer4a9lf1XUMEeAto3KlSFjumxFm1kj2qTj3w=; b=sw0Ok63HEOD55Iqb5GfQoW+bnlRTUZtBy27aN0au8nTDaqQYfbzMpN2yI3ivd5nsdOi+ p9/cbLPbnU+Pus3FNx0ALvrGPViNjnNYU+YNWPni147zWxI03AXlJJkQ9XMZHrpAB0jc D5MHkMKR47eUG/oGcaxT9eiTy7tfxkWDPzBs9yySdlvk+/ffNFn7lqV2ldI7eMsMCYY8 B8mgSDTeN1MD69a4tnme3a9fVW9OeKQczzokTmtiAXoqAmeR+ee74ycImeif5ecmX1XD c+zKh2vVzM/GVWUqWW95Js9SH/12FScl2JkYyjUmkKMOKBk3TvZmVHYnMwF9hIhIUTDw fg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 31sebb1prn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 20 Jun 2020 22:57:43 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05KMqm6g122556; Sat, 20 Jun 2020 22:55:42 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 31seb7dewq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 20 Jun 2020 22:55:42 +0000 Original-Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05KMtacW030029; Sat, 20 Jun 2020 22:55:36 GMT In-Reply-To: <<831rmavsuq.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9658 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 malwarescore=0 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0 suspectscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006200172 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9658 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 cotscore=-2147483648 lowpriorityscore=0 phishscore=0 bulkscore=0 clxscore=1011 impostorscore=0 malwarescore=0 priorityscore=1501 spamscore=0 mlxscore=0 adultscore=0 suspectscore=1 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006200173 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/20 18:57:45 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -63 X-Spam_score: -6.4 X-Spam_bar: ------ X-Spam_report: (-6.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:252471 Archived-At: (Caveat: I haven't been following this thread, I'll likely continue to not follow it, and I know almost nothing about project.el.) >From one msg: > > And bookmarks/switch-to-buffer/registers are not good > > options for this goal? >=20 > The problem I raised is that such a Grep buffer will not be offered as > a completion candidate when it is definitely relevant to my work on a > project. You suggest that I don't use the project.el commands, which > is exactly what bothers me: it means that project.el commands don't > support well a very simple project-related activity, which for me is > a very frequent one. >From another msg: > 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. >=20 > More to the point, my question is how would adding a buffer to the > project be recorded and where, under your proposal? I imagine that project.el defines a project as including something like these things, and perhaps some other stuff: 1. A set of files. 2. Possibly a set of other Emacs/Lisp objects: buffers, vars, whatever. 3. Associations among such things, and among them and other things, including things (e.g. tools) outside Emacs. I imagine that project.el can persist a project. I'll just mention that bookmarks, bookmark files, and bookmark-list displays are objects that can be persisted. A bookmark can record nearly anything: a set of variables, a location or set of locations,... anything. Bookmark+ takes advantage of this generality in ways that could be useful for project mgt. I mention this because vanilla Emacs bookmarks could too. I'm not proposing using Bookmark+, but just mentioning some of what you can do using bookmarks that I think can be relevant to working with or defining projects. You can bookmark a Dired buffer, with its markings, omit-set, switches, inserted subdirs, hidden subdirs, etc. And Dired can list an arbitrary set of files and dirs; it need not show only part of a single tree. You can bookmark a set of Dired bookmarks that represent a dir hierarchy and are opened together. You can bookmark buffers, and locations in them. Of course, if restored from persistence the bookmark must know how to regenerate the buffer. One thing I haven't gotten around to implementing, but is possible, is to bookmark the marked buffers in either Ibuffer or Buffer Menu. (Again, supposing knowledge of how to regenerate or recuperate the buffer in a new session.) You can bookmark a function. For example, a bookmark to restore a given `*grep*' listing, by recomputing it, records a function that performs the given `grep' invocation. >From a `grep', `occur', compilation, etc. buffer you can bookmark one or more of the individual hits, so that jumping to such a bookmark takes you to the hit destination (e.g. position in the grepped file). You can bookmark all hits visible in the `grep', `occur', etc. buffer, so after editing to remove some hits you can get the effect of having "marked" some and then bookmarked each of the marked ones. In Dired, you can bookmark each of the marked files or dirs. In the bookmark-list display, you can dired the marked bookmarks, i.e., create a Dired buffer with just the files and dirs that are the targets of the marked bookmarks. You can bookmark a bookmark-list display itself (what `C-x r l' shows). This includes filtering, sorting, etc. You can bookmark a bookmark file, so that jumping to the bookmark switches to that set of bookmarks or loads them additionally. There are bookmark jump commands specific to different types or sets of bookmarks. E.g. jump to the bookmarks for a specific project, choosing only among "project" bookmarks. There are many ways to define a project in this regard. One is to mark the "project" bookmarks in a bookmark list and use `C-c C-j' to define a command that jumps to them (they are the only completion candidates). You can bookmark a desktop. Besides bookmark-file bookmarks, bookmark-list bookmarks, Dired bookmarks, desktop bookmarks, etc., as ways of organizing bookmarks into sets (~projects), you have tags. You can tag any set of bookmarks any way you like, including with any Lisp object as tag value instead of just a string. You can list or complete against bookmarks that have certain combinations of tags. So your wanting to get to a `*grep*' buffer that belongs to a given project is realized trivially: just tag it for the project, then use a command that jumps to a bookmark with that tag (i.e., only those bookmarks are completion candidates). Tags are the most flexible way to organize bookmarks. You can even use bookmarks to tag files or other objects in various ways just for purposes of organizing them, whether or not you ever use the bookmarks as a way to visit them. Different projects can have different tags for the same sets of files, directories,..., whatever. No need for copies - just different tagging. Bookmarks are persistent pointers. If a "project" is mostly about grouping things to be able to act on them together (search, visit, apply a tool, etc.), and if a "project" should be able to be persisted, then consider that you might do well to leverage bookmarks - a flexible, open-ended way to persist and restore or otherwise act on nearly anything. If "project" means code-development project for you, or even if it means something else, what it does is likely to be more or less a subset of what you can do with bookmarks. You might want to build features for code-development project using, or on top of, bookmarks. And if you're thinking of adding very general capabilities to project.el, you might want to think instead about adding them at a more general level, and then adapting them for the more specific use for projects. Just a thought. ____ For more info, search here for "project", "tag", or any other terms used above: https://www.emacswiki.org/emacs/BookmarkPlus