From: "Basil L. Contovounesios" <contovob@tcd.ie>
To: Drew Adams <drew.adams@oracle.com>
Cc: Karl Fogel <kfogel@red-bean.com>,
39293@debbugs.gnu.org, Stefan Kangas <stefan@marxist.se>,
Matthias Meulien <orontee@gmail.com>
Subject: bug#39293: [PATCH] Base bookmark-bmenu-mode on 'tabulated-list-mode'
Date: Sat, 13 Jun 2020 13:17:02 +0100 [thread overview]
Message-ID: <871rmjkvnl.fsf@tcd.ie> (raw)
In-Reply-To: <c64f0f6e-b00a-4f81-9a71-e3719cab59ae@default> (Drew Adams's message of "Fri, 12 Jun 2020 17:05:31 -0700 (PDT)")
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
next prev parent reply other threads:[~2020-06-13 12:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 3:13 bug#39293: [PATCH] Base bookmark-bmenu-mode on 'tabulated-list-mode' Stefan Kangas
2020-01-26 18:05 ` Drew Adams
2020-01-26 19:33 ` Stefan Kangas
2020-01-26 22:35 ` Drew Adams
2020-04-26 14:59 ` Stefan Kangas
2020-05-23 21:18 ` Stefan Kangas
2020-05-23 21:31 ` Drew Adams
2020-05-23 21:44 ` Drew Adams
2020-05-23 22:16 ` Stefan Kangas
2020-05-23 20:31 ` Matthias Meulien
2020-05-23 21:01 ` Stefan Kangas
2020-05-23 21:26 ` Drew Adams
2020-05-26 17:43 ` Karl Fogel
2020-05-26 20:02 ` Drew Adams
2020-05-26 20:38 ` Karl Fogel
2020-05-26 21:41 ` Drew Adams
2020-05-27 9:50 ` Stefan Kangas
2020-06-12 11:55 ` Basil L. Contovounesios
2020-06-12 18:03 ` Drew Adams
2020-06-12 21:40 ` Basil L. Contovounesios
2020-06-13 0:05 ` Drew Adams
2020-06-13 12:17 ` Basil L. Contovounesios [this message]
2020-08-18 15:24 ` Lars Ingebrigtsen
2020-10-13 3:41 ` Lars Ingebrigtsen
2020-10-13 9:14 ` Stefan Kangas
2020-10-14 3:42 ` Lars Ingebrigtsen
2020-10-17 15:58 ` Stefan Kangas
2020-10-18 8:17 ` Lars Ingebrigtsen
2020-10-13 15:36 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871rmjkvnl.fsf@tcd.ie \
--to=contovob@tcd.ie \
--cc=39293@debbugs.gnu.org \
--cc=drew.adams@oracle.com \
--cc=kfogel@red-bean.com \
--cc=orontee@gmail.com \
--cc=stefan@marxist.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.