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

[Basil L. Contovounesios]

Drew Adams <drew.adams@oracle.com> 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