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

[Karl Fogel <kfogel@red-bean.com>]

On 26 May 2020, Drew Adams wrote:
>Sorry, I really don't have the time to deal with
>this now.
>
>Bookmark+ has lots of added features, and many
>have to do with the bookmark-list display.  If
>you're interested in that, please see its doc.
>
>Maybe at some point later I'll have the time and
>will to tick off things in Bookmark+ that t-l-mode
>interferes with or prohibits.
>
>I think at this point you'll just have to take my
>word for it (or not) that it would be far too much
>work, too risky, and for no benefit, for me to try
>to rewrite such features to adapt to t-l-mode.

Okay, fair enough -- I understand about limited time.

>And I'm pretty sure that some things would need to
>be sacrificed.  In my experience just with `apu.el'
>(which uses t-l-mode) I ran into limitations that
>I had to work around (no, I don't recall what they
>were).
>
>[Can a t-l-mode buffer even have a title (not just
>column headings)?  With Bookmark+ the listing
>reflects the current sorting and filterings, and
>the title at the top tells you what the listing is
>about.]
>
>I'm sorry to say it, but I won't try, for Bookmark+.
>I don't have the time to waste on that.  Sorry.
>
>Do what you think you have to do.  I'll do what I
>have to do, given my limited resources.  I expect
>I'll likely just incorporate the former bookmark.el
>code that Bookmark+ currently takes for granted.

Well, I don't think we "have to" convert bookmark.el to use t-l-mode at all.

>FWIW, I also don't think that bookmark.el's list
>of bookmarks is a great candidate for t-l-mode.
>I don't think it adds anything important for such
>a simple list with 2-3 columns.  As I said in my
>Jan 26 mail, sorting by those columns (which is
>really all that t-l-mode offers here) is not so
>helpful.  (OK, it has some use.)
>
>Maybe consider ibuffer.el instead?  As I said
>earlier, trying ibuffer, which offers a bit more
>than a rudimentary listing, might point to some
>t-l-mode limitations or complications.  And if
>it doesn't then so much the better. ;-)

Well, I mean, bookmark.el seems to be working fine the way it is right now, without t-l-mode nor ibuffer.  So I'm not sure the proposed change is warranted.

Stefan, is there a strong motivation here, other than the obvious attractions of re-using code and avoiding multiple implementations of similar functionality?

(If we decide not to make the change, then we should add a comment to bookmark.el pointing to this bug-ticket discussion and explaining *why* we have left the code as-is.)

>To be clear, I don't think I said that anything
>would be limited or broken in _bookmark.el_ by
>using t-l-mode.  Potential uses of its features,
>and existing uses by 3rd-party libraries (e.g.
>Bookmark+), could be limited or broken.  But I
>doubt that anything bookmark.el offers out of
>the box would be affected much, if at all.
>(bookmark.el could probably drop a good deal of
>its code without breaking anything that people
>use much).

Agreed; that's what I understood you to be saying.

Best regards,
-Karl