From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.bugs Subject: bug#39293: [PATCH] Base bookmark-bmenu-mode on 'tabulated-list-mode' Date: Fri, 12 Jun 2020 22:40:56 +0100 Message-ID: <87h7vgnes7.fsf@tcd.ie> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="81852"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Karl Fogel , 39293@debbugs.gnu.org, Stefan Kangas , Matthias Meulien To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 12 23:42:13 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 1jjrRE-000LC3-Lk for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jun 2020 23:42:12 +0200 Original-Received: from localhost ([::1]:42446 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jjrRD-0006Fi-Iy for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 12 Jun 2020 17:42:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jjrR4-0006Dn-UQ for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 17:42:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57328) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jjrR4-0007YH-4W for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 17:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jjrR4-0000i3-1V for bug-gnu-emacs@gnu.org; Fri, 12 Jun 2020 17:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "Basil L. Contovounesios" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Jun 2020 21:42:01 +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.15919980672657 (code B ref 39293); Fri, 12 Jun 2020 21:42:01 +0000 Original-Received: (at 39293) by debbugs.gnu.org; 12 Jun 2020 21:41:07 +0000 Original-Received: from localhost ([127.0.0.1]:40641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjrQB-0000gn-7u for submit@debbugs.gnu.org; Fri, 12 Jun 2020 17:41:07 -0400 Original-Received: from mail-wr1-f43.google.com ([209.85.221.43]:40174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jjrQ8-0000g7-V0 for 39293@debbugs.gnu.org; Fri, 12 Jun 2020 17:41:05 -0400 Original-Received: by mail-wr1-f43.google.com with SMTP id h5so11426727wrc.7 for <39293@debbugs.gnu.org>; Fri, 12 Jun 2020 14:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd-ie.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=x86pLoLgQ7T4S+J92l4xB9/F2pY2omUH65UvJgzPwoY=; b=U/WW6zeOyglzsBHYveiagKn6rrq0IVgbzZeMuhojIobjfgTx6sT2hlowLdZ04Y7SOs HaPsV7aIxeFUqmAtzCGwducmg4jBnLCPIWheVQeEtP1r0kJ8JbJDnuUzviQHegOOK0jy x1h43uCLH8jPuPIS5Nb98kPTX0NRbMLK/9Qe6dZIWhVRF9eK3iAIdAwUH8vP0yD3qlv0 y1hGCtFL7Pjk+HZPiEOO9Snv1+pn8w2js93j0Q0lLolvhOJnYSCRL1xq/JJsr2BJlpiQ 1G8zit6z+TaIqqmWqMCiyVCXpOX336KGpOM+o6T80JDiX/CJ0oz3XGXw/m6qZSX5DxiA JHkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=x86pLoLgQ7T4S+J92l4xB9/F2pY2omUH65UvJgzPwoY=; b=HeZiCOomPgoFloNe/OF65mvCf2Cmi1YfOCfiWkLcON/Lu+fKBDDUNNUvcqyJfuc1Ch VU7eo5aRVfkdpeaunFZEfyZFoPfbVsHVBGD+qXFfXkIePJO1MN5dmrgluugWEsC7CD+2 oYWZnbwT0UbtT7VfQ2yLJV3lwPFreOGEz3XgrUgTnfVhzftoTl+VNGxNRCC88nqerFae fOQLeHOEwtKB9UseVLx8Cd2UDzQxOr9e1nL8pYhfkA5itzQrQocsWUlz85eWrSyq5SfE 9lryCm3ywuYp/gqlw6tLxVV9s67kF0qS/47tC7ccQU0Vqf//t8ICEOJ9qUfVm9jtj6QF X/cw== X-Gm-Message-State: AOAM533GYEQOkQKOpDnniV41nf0/wnkLDa99phqoZ+8d2W47LvrQ8hMm TwX6lvWqjz8wBI4cvVSjpQkQBg== X-Google-Smtp-Source: ABdhPJz9Tln7XVOnOVkcg/2aIU1usaDqRWhn3G+q3ILitHTNTRqKp/8NuVyGWs9f0cNKOFSvDmOHKQ== X-Received: by 2002:adf:ab08:: with SMTP id q8mr16376260wrc.216.1591998058761; Fri, 12 Jun 2020 14:40:58 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:92bd:1bfd:38fc:fae2]) by smtp.gmail.com with ESMTPSA id e10sm11764998wrn.11.2020.06.12.14.40.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2020 14:40:57 -0700 (PDT) In-Reply-To: <94c7efe8-7b4b-4442-b2a1-4cb07ec9801a@default> (Drew Adams's message of "Fri, 12 Jun 2020 11:03:05 -0700 (PDT)") 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:181897 Archived-At: Drew Adams writes: >> 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. Very little, hence my (attempt at) careful phrasing. > 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. In what ways exactly would future enhancements be limited? > 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. No, I meant that for any package. > 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. I neither said nor suggested anything like this. > 4. The format of bookmarks _is_ documented, in bookmark.el > comments. 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? > 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. Then in theory it could also handle future changes, no? [...] > 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.) Do you have any links to these discussions, or would you be willing to bring them up again? 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. > 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). That's just one superficial gain. There are other benefits for both developers and users from reusing core infrastructure, such as better integration, uniform UIs and customisations, etc. You could say "improvement potential would be reduced" any time any decision is made. Is there a real current use case under threat? > `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. There is no need to discourage such contributions. Even if the current proposal is not installed, it's worthwhile to make it. > 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. Of course. > 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. Yes, of course, I'm always in favour of importing good features. -- Basil