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

[Drew Adams]

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

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

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