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.bugs Subject: bug#39293: [PATCH] Base bookmark-bmenu-mode on 'tabulated-list-mode' Date: Fri, 12 Jun 2020 17:05:31 -0700 (PDT) Message-ID: References: <87lfpu9ag8.fsf@marxist.se> <87367qmm0l.fsf@gmail.com> <323e521b-503b-4ed3-bd42-aa3707de37c1@default> <87sgfmfv6v.fsf@red-bean.com> <1fd3ebe3-e447-43af-8086-32a98febe475@default> <87a71ue8jr.fsf@red-bean.com> <87sgf0wlak.fsf@tcd.ie> <94c7efe8-7b4b-4442-b2a1-4cb07ec9801a@default> <87h7vgnes7.fsf@tcd.ie> 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="27193"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Karl Fogel , 39293@debbugs.gnu.org, Stefan Kangas , Matthias Meulien To: "Basil L. Contovounesios" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 13 02:08:14 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 1jjtiX-0006yR-Qa for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 13 Jun 2020 02:08:13 +0200 Original-Received: from localhost ([::1]:36224 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjtiW-0008W2-1i for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jun 2020 20:08:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35984) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjtiP-0008Vw-Lk for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 20:08:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57367) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjtiM-0000cu-7D for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 20:08:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjtiM-0004CV-1i for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 20:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Jun 2020 00:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39293 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 39293-submit@debbugs.gnu.org id=B39293.159200686516126 (code B ref 39293); Sat, 13 Jun 2020 00:08:02 +0000 Original-Received: (at 39293) by debbugs.gnu.org; 13 Jun 2020 00:07:45 +0000 Original-Received: from localhost ([127.0.0.1]:40680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjti5-0004C1-5a for submit@debbugs.gnu.org; Fri, 12 Jun 2020 20:07:45 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:56766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjti3-0004Bn-5N for 39293@debbugs.gnu.org; Fri, 12 Jun 2020 20:07:43 -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 05CNwlU8082176; Sat, 13 Jun 2020 00:07:37 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=0AMaciAJnLzwV++BW+t6E/3Di0DaqeeF1aN0vfzQyOE=; b=aw+OofWwx0UVYp6AV/xcc4rvEIGN8TrrCVZ59ECH1rDXPZUJPpf2hJjrzbtJmnbdT0r6 zc1O9nTk5sPStcfJT0gLHoO8Yt+dy80rcTG5+g2WaYFYsrqjJWfhzie2JZUdFKqXiyxD Nkbo+X8OY6xzC/WkMcVG1tlVyJ9ZqNRv9+Tfyh2XRWrN3rSpzUIuuX0UxrjXKvxKPK78 1i9jYMY7G+3fjmmBvzSFi7IDJ3wJ3pWTFU9AB+u/pq4KKnpFRaksYKlzOIL6fepjq6c4 Lc/8jbp074mJ5dQkJzfZkCK1n0U8hX4a0cUOqtScV1YWVK0mg/YfXD9ecL7smpKeSgZP HA== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 31jepp9edv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 13 Jun 2020 00:07:37 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05CNwUoA164177; Sat, 13 Jun 2020 00:05:36 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 31mhkk403k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 13 Jun 2020 00:05:36 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 05D05WcA014270; Sat, 13 Jun 2020 00:05:33 GMT In-Reply-To: <87h7vgnes7.fsf@tcd.ie> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5005.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9650 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 adultscore=0 phishscore=0 spamscore=0 suspectscore=2 bulkscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006120180 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9650 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 suspectscore=2 priorityscore=1501 bulkscore=0 clxscore=1015 phishscore=0 impostorscore=0 malwarescore=0 mlxscore=0 cotscore=-2147483648 adultscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006120180 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:181900 Archived-At: > > 2. Basing the bookmark-list display on `tabulated-list-mode' > > could not, by any stretch of the imagination, be > > considered "internal implementation". The immediate > > behavior change for users would be minor, yes. But the > > repercussions of the change would be large for users, > > in terms of limiting future behavior enhancements. >=20 > In what ways exactly would future enhancements be limited? Covered in the rest of the msg you quoted. `t-l-mode' takes over a buffer. It sees only dumb columns with, at most, an associated data type (by which it can sort). > > 3. My opinion is anyway that there's nothing "internal" > > in GNU Emacs, or in free software in general. > > > > You say, "Packages should not be limited by assumptions > > made by external extensions." > > > > You meant that for packages distributed as part of Emacs. >=20 > No, I meant that for any package. But in particular, for `emacs -Q' packages, I think - you were generalizing the idea that bookmark.el shouldn't be limited by any assumptions made by Bookmark+. And you specifically spoke of "internal implementation". The meaning I took was that outside code shouldn't depend on "internal implementation". Isn't that what you meant? > > But the reverse is also true: 3rd-party packages should > > not be limited by all of the assumptions made by vanilla > > Emacs code at any given time. > > > > Sure, no one forces anyone else to abide by any sense of > > cooperation. But there has been some mutual cooperation > > and respect over the years. 3rd-party code depends, at > > any given time, on what Emacs provides, not vice versa, > > of course. > > > > But in the long run what Emacs provides depends in part > > on what goes on outside its parochial development. An > > attitude that "core" Emacs development shouldn't care to > > look at what's happening in the wider community is > > self-limiting. > > > > Telling 3rd-party developers that you don't need to > > listen to them, don't need to care about what they say > > or ask for is, yes, within your rights. Core Emacs need > > not care, in any sense of legal obligation. But then > > don't wonder about separation between the core and the > > larger community. >=20 > I neither said nor suggested anything like this. Again, I interpret your "Packages should not be limited by assumptions made by external extensions." to be an argument that statements about impact of changes to bookmark.el on Bookmark+ shouldn't be taken into account. And that Bookmark+ shouldn't depend on the implementation of bookmark.el. To that, I said fine, if that's the way you want it. But in that case the reverse is true too. A spirit of cooperation matters. Or it doesn't. > > 4. The format of bookmarks _is_ documented, in bookmark.el > > comments. >=20 > There's a difference between comments intended for general readership > that document a stable API, and those that explain what code is doing. > Which kind are you referring to? Call the comments in bookmark.el what you will. I didn't write them (though I might have filed a bug or two to offer some improvement for them). But I understand them to let users, as well as developers, of bookmark.el, know what the structure of a bookmark is, as well as what's important about it and what's not. > > Bookmark+ respects that format, and extends > > it. That format has changed over time, and Bookmark+ > > has adapted, to handle the old formats as well as the > > new ones. >=20 > Then in theory it could also handle future changes, no? Future changes to the structure of a bookmark? "In theory", I'd try to accommodate that, yes. Why - did you have something in mind? Are you thinking about changing the bookmark format? That's not really the subject of this enhancement request. (And bonjour les degats, if you do - you may hear from some bookmark users and library authors.) > > 7. Everything in Bookmark+ has, from the beginning, been > > offered to vanilla Emacs for inclusion. Everything and > > anything it does could be added to GNU Emacs. I've even > > offered it as a whole, as a drop-in replacement for > > bookmark.el (after incorporating the bit of code from > > that file that Bookmark+ makes use of). > > > > Stefan Monnier said at one point that such replacement > > would be good to do. Other than that comment by Stefan, > > there hasn't been any interest by Emacs Dev in the code > > or features provided by Bookmark+. So I continue to > > maintain it "outside" of Emacs. So be it. (I may have > > forgotten some minor uptake of Bookmark+ features; Karl > > can correct me.) >=20 > Do you have any links to these discussions, or would you be willing to > bring them up again? No. The code is there. It's well documented. And if there's interest and there are specific questions then I'll try to find the time to answer them. I'm OK with vanilla Emacs including Bookmark+. And I'd remove, e.g., code that provides for compatibility with older releases. And I'm OK with instead continuing as is, regardless of whether bookmark.el switches to `t-l-mode'. (In the latter case, Bookmark+, or at least its display list, will need to be separated from bookmark.el.) But I won't spend a lot of time helping integrate this or that piece of Bookmark+. I'll help someone understand something that Bookmark+ does, of course. > I don't see why it should be too late to discuss > these inclusions again, especially if that would mean smoother > integration with whatever ways bookmark.el evolves in the future. See above. You, or others, are welcome to start. > > 8. My arguments against basing Emacs bookmark-list display > > on `tabulated-list-mode' go beyond nuisance to Bookmark+. > > If bookmark.el changes to base its bookmark-list display > > on `t-l-mode' then I'll just have to change Bookmark+ > > so that it works around that, e.g., by incorporating the > > former bookmark.el code that's relevant. IOW, I'll need > > to abandon dependence on bookmark.el. Not the end of > > the world. > > > > My argument against `t-l-mode' for bookmark.el is that > > almost nothing is gained, and much of what could > > otherwise be possible is lost. Not that anything in the > > current bookmark.el display-list would be lost, but that > > its improvement potential would be reduced - a sacrifice > > for very little gain (sorting by clicking column heads). >=20 > That's just one superficial gain. That's the only gain for _users_. And sure, that includes the fact that if they know about clicking column headers to sort then they'll know how to use that (sole) feature `t-l-mode' provides. > There are other benefits for both > developers and users from reusing core infrastructure, such as better > integration, uniform UIs and customisations, etc. There are no deffaces or defcustoms. OK, there's one hook. No customization, and nothing special for users to gain, other than click-to-sort column headers. See what I said in my first post of this thread, starting with "This kind of proposal is, IMO, a consequence of one or both of the following:" > You could say "improvement potential would be reduced" > any time any decision is made. You can say that. I didn't say that. You seem to want to argue by making generalizations. > Is there a real current use case under threat? I mentioned titles. There are many other display-list features whose implementation would need to be totally revamped (reimplemented using `t-l-mode' "features"). I mentioned sorting in my first message in this thread. `t-l-mode' lets you sort in only one way, by column type. What's the column type for a bookmark name or a target location? Click the bookmark-name column header - what does it sort by? Not much that's useful. Many of the features Dired provides exist in Bookmark+, from omitting (with show/hide) to specialized markings. And there are other display-list features that Dired doesn't have: interactive filtering, help, editing, and highlighting of entries, etc. Can some of those accommodate `t-l-mode' or be reimplemented to do so? Maybe. I probably won't try/bother, sorry. > > `t-l-mode' is rudimentary. It's not built for, or > > adaptable to use with, "tabular" displays that are more > > sophisticated than just what it provides/expects. > > > > You can't even use `t-l-mode' to control only part of a > > buffer - it has to own the whole buffer. You can't even > > add a title or other text to a buffer displaying tabular > > info, if you give control to `t-l-mode'. > > > > I do use `t-l-mode' myself - in my library apu.el, for > > instance. But even for that simple case I had to jump > > through a few hoops to work around some simplistic > > behavior & limitations. Nothing dramatic; just sayin'. > > `t-l-mode' is what it is. It isn't bad; it's limited - > > and limiting. > > > > Those wanting to convert Emacs buffers that apparently > > use columns to `t-l-mode' are, IMO, too often suffering > > from near-sightedness and have-a-hammer-see-only-nails > > syndrome. They might do well to focus their attention > > on some of the many other things that need improving > > in Emacs. >=20 > There is no need to discourage such contributions. Even if > the current proposal is not installed, it's worthwhile to make it. Sure, it was worthwhile to make it. It was worthwhile to disagree with it. And it's worthwhile not to do it. There's nothing wrong with proposing _any_ particular change to Emacs. > > Once you impose `t-l-mode' on a buffer you've limited > > what you can do with it - then and thereafter. And it > > makes zero sense to impose it on a buffer that already > > offers behavior not supported by `t-l-mode'. (The > > prime example of this is Dired mode.) Just because you > > see some columns, it doesn't follow that `t-l-mode' is > > called for, or a wise addition. You have to consider > > what `t-l-mode' locks you into. >=20 > Of course. Glad you agree. > > Could `t-l-mode' be improved, to allow it to play well > > and flexibly with other columnar-list displays? Maybe. > > But I'm not counting on it. Too much in its design > > depends on total control, I believe. Perhaps its > > effect could be limited to a particular buffer zone, > > but even then I think it would be imposing limiting > > behavior on that zone. Anyway, that's a different > > discussion, and no doubt someone else would need to > > take that up, not I. > > > > 9. Much, perhaps most, of the progress in Emacs over the > > decades has been outside the "core". Yes, there have > > also been great developments within the core, including > > in the last couple of decades. But the widespread use > > of 3rd-party code speaks to the fact that much that's > > progressive and creative in Emacs development happens in > > the larger community, outside the core - for whatever > > reasons. IMO that's a fact, for better, worse, or both. > > > > Rather than lament the fact that a library like Bookmark+ > > has introduced new features outside the core, it would be > > better to look at what it has to offer - at least as food > > for thought, and perhaps for simple adoption/integration. >=20 > Yes, of course, I'm always in favour of importing good features. There are tons of good features out there, in libraries by lots of people, and with GPL. A motherlode to mine. But there's little such mining that goes on by Emacs "core" developers. What there is, is some contribution of 3rd-party libraries to GNU ELPA. But "core" pulling in features from 3rd-party code - "importing"? Not so much. When was the last time you saw a "core" developer import some feature from a 3rd-party library? Library authors and maintainers often find it more worthwhile to just keep working on their stuff outside the "core". And "core" Emacs developers often expect 3rd-party authors to do the work of integrating their features into Emacs. The motherlode's still out there, and growing, for those who are "always in favour of importing good features."