bug#39293: [PATCH] Base bookmark-bmenu-mode on 'tabulated-list-mode'

[Basil L. Contovounesios]

Drew Adams <drew.adams@oracle.com> writes:

>> > 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?
>
> 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).

Does bookmark-bmenu-mode provide any other features over
tabulated-list-mode?

>> > 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 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+.

Yes, but that generalises to any package, not just core ones.

> 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?

Yes, which also applies to 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.
>
> 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.

I didn't say they shouldn't be taken into account.  But if Bookmark+
relies on internal features then it is unfair to let that limit
bookmark.el development.

> And that Bookmark+ shouldn't depend on the implementation
> of bookmark.el.

Yes, just like any package shouldn't rely on internal details of another
package if it cares about longterm compatibility.

> 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.

It does.

>> > 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?
>
> 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.

Sure, but not all comments should be taken as gospel.

>> >    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?
>
> 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.

I was referring to the currently proposed patch in particular and future
changes in general.  I realise now you were referring specifically to
the sexp data that bookmark.el uses, which was not under discussion.

> (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.)
>> 
>> 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.

Thanks, that could make an interesting project for anyone interested.

>> 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).
>> 
>> 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.

That's not the only feature tabulated-list-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.

I count 4 defcustoms, 1 defface, 2 key maps, 1 hook, several functions
that can be advised, and a common UI in Emacs 27/28.  Furthermore, any
future developments to tabulated-list-mode will benefit all modes based
on it.  All of these are big gains in my book, for both users and
developers.

> 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.

I made general comments because I'm not familiar enough with the
relevant code to make more specific ones, and for whatever they're
worth.

>> 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'm asking specifically about bookmark-bmenu-mode, which is what is
being discussed.

> 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.

Every tabulated-list-mode column can be defined with its own custom
sorting predicate.

> 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.

[...]

>> > 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.
>
> 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."

I don't see how this relates to the current discussion.

-- 
Basil