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

[Drew Adams <drew.adams@oracle.com>]

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

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.