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 11:03:05 -0700 (PDT) Message-ID: <94c7efe8-7b4b-4442-b2a1-4cb07ec9801a@default> 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> 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="28606"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Karl Fogel , 39293@debbugs.gnu.org, Matthias Meulien To: "Basil L. Contovounesios" , Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 12 22:58:11 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 1jjqkc-0007Mw-VH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jun 2020 22:58:11 +0200 Original-Received: from localhost ([::1]:57862 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjqkb-0002bz-Tt for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jun 2020 16:58:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjqkU-0002Xp-G5 for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 16:58:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57303) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjqkU-0000Vz-6x for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 16:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjqkU-00086Q-5c for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 16:58: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: Fri, 12 Jun 2020 20:58: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.159199542731083 (code B ref 39293); Fri, 12 Jun 2020 20:58:02 +0000 Original-Received: (at 39293) by debbugs.gnu.org; 12 Jun 2020 20:57:07 +0000 Original-Received: from localhost ([127.0.0.1]:40616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjqjb-00085H-7n for submit@debbugs.gnu.org; Fri, 12 Jun 2020 16:57:07 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:58370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjqjZ-00084l-An for 39293@debbugs.gnu.org; Fri, 12 Jun 2020 16:57:05 -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 05CKqwtf103066; Fri, 12 Jun 2020 20:56:58 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=UbGXrGBcQaTeBWjoTFFCxUMgRiOm/WC0dWOL4o8tkmA=; b=jqorfiqzWYnUBPircH4XLqNB8rJUaQE5nGPmLXMnwTvm8+GAsuwvnJUgpnMS4TfSNMfd IotFUluLqipEaiLy7E6i6rFhJ9LokT/AVp7r9zHMOQ0ONsncfMaRmR6/VPFwsaBR3elQ ZTHkQaDI/cRsTDrHRy6GSNz2h4YNrQmunmJoRIsoCCHOUbasI0WjY21eIgaNecrxJpaK ItL3qkgeVEXX4eUO9hCi+6l5LiD79PsTTZYuliWQkTGkbgE/xLZ3CtMYbTLfHKq66i1R ftVZGt9TY2dgA/CPnKsInUDvoU+ipfN+3aoIEssPtRLiWKHtOkXERL1ERLxHapK83jM9 CA== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 31jepp8t34-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Jun 2020 20:56:58 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 05CKmGgd140537; Fri, 12 Jun 2020 20:56:57 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 31mh2h073p-10 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 12 Jun 2020 20:56:57 +0000 Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 05CI36dm021987; Fri, 12 Jun 2020 18:03:06 GMT In-Reply-To: <87sgf0wlak.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 phishscore=0 malwarescore=0 bulkscore=0 suspectscore=2 spamscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006120152 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=1011 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-2006120152 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:181896 Archived-At: > unless bookmark.el provides a specific > public API (not just functions, but rather any format > that's documented and can be relied on externally), then > external extensions to it should not rely on its internal > implementation. Packages should not be limited by > assumptions made by external extensions. Besides, why > are these extensions external to bookmark.el to begin > with? Surely useful extensions should be included upstream. 1. I wonder how familiar you are with bookmark.el, its code, and the bookmark formats it defines. 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 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. 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. 4. The format of bookmarks _is_ documented, in bookmark.el comments. 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. 5. Anyone is free to extend the "format" of bookmarks. That's entirely expected. New kinds of bookmarks can be defined, and any new fields can be added. What's important is that the basic structure defined by/for bookmark.el be respected, but nothing prevents adding additional fields etc. That's as it should be. There is also nothing wrong with enhancing or otherwise changing the use (behavior) of existing fields, as long as such behavior changes are clearly documented for users and use of the 3rd-party library is optional. 6. I'm very conservative in my enhancements of vanilla behavior. I try as much as possible not to modify existing code, etc. (But some of my code that tries be compatible with older Emacs releases can't use nadvice etc., so there is more actual modification.) I avoid changing things gratuitously for several reasons, not the least of which is the maintenance burden of updating my code as Emacs code changes. You have only to notice that many of my libraries are named ____+.el, where the ____ is the name of a standard Emacs library. Those `+' libraries of mine typically start out as minor add-ons to the existing vanilla code, sometimes as a result of not being able to persuade "core" to add some feature, and sometimes because the library is, so far, only for my own use - just personal customization. Bookmark+ started out that way, for example. From 2004 to 2009 it consisted only of some code I used myself, to remain compatible with Emacs 20. Starting in 2009 were added (1) the ability to bookmark a region and (2) display-list commands to list only W3M, Info, Gnus, files, and region bookmarks. And so on - more features were added. The point is that I always based the library on vanilla bookmark.el. Even as many more features were added, and the bookmark.el code it made use of accounted for little, I kept the dependency. Why? To be sure it continued to work well with vanilla bookmarks, and to oblige it to keep up-to-date with any new features that bookmark.el might add. 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.) 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). `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. 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. 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.