unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Durand <mmemmew@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: [ELPA] Want to submit two packages "ilist" and "blist"
Date: Mon, 20 Sep 2021 16:39:19 +0800	[thread overview]
Message-ID: <m2o88nej48.fsf@gmail.com> (raw)
In-Reply-To: <CADwFkmm3494_q0OXLVTBkjG3w7wa6h5xCvkZZ4Wb7uMv8twAxA@mail.gmail.com> (Stefan Kangas's message of "Sun, 19 Sep 2021 03:15:42 -0700")

>>>>> On Sun, 19 Sep 2021 03:15:42 -0700, Stefan Kangas <stefankangas@gmail.com> said:

    Stefan> Durand <mmemmew@gmail.com> writes:
    >> I have written two Emacs pacakges, called "ilist" and "blist"
    >> (the former is the "engine", and hence a dependency, of the
    >> latter).  Now I am thinking about submitting the packages to GNU
    >> ELPA.
    >> 
    >> The package "blist" is to display the list of bookmarks, in the
    >> sense of "bookmark.el", in a similar way as Ibuffer.

    Stefan> Thanks, this looks useful at a first glance, and something
    Stefan> that I think we should definitely welcome on GNU ELPA.

Thanks.

    Stefan> I wonder why you chose to write this as an entirely new
    Stefan> package instead of improving the bookmark list we already
    Stefan> have in bookmark.el.  Could you explain your rationale for
    Stefan> this?

    Stefan> One thing that stands out is that you list bookmarks by
    Stefan> category, like in ibuffer, something that I don't think is
    Stefan> currently possible with `tabulated-list-mode'.

Yes, this is one reason: it would be a breaking change if I want to
modify the existing library.

And when I was thinking about this idea my main concern was in fact the
package "ilist", which is an abstract library package.  It seems natural
that "ilist" should be a separate package, and I did not think too much
when I built "blist" upon "ilist".  I guess I am not used to the idea of
modifying existing Emacs packages.

    Stefan> Some other scattered comments:

    Stefan> - Is any of this suitable for inclusion in bookmark.el?  I'm
    Stefan> thinking of `blist-show-all-annotations', for example.

I think maybe some functions of bookmark.el can be improved, like its
annotation-showing functions: it would be a good idea to refrain from
showing empty annotations.  Also I think the function "bookmark-load"
can be improved as well: its documentation string says that the newly
loaded bookmarks will be appended at the front of the list, but from the
codes it seems that the new list will be appended at the end (as seen in
the function "bookmark-import-new-list").  But in general my codes are
built upon the outputs of ilist, so might not be directly suitable for
inclusion in bookmark.el.

    Stefan> - I would add (defalias 'blist 'blist-list-bookmarks) for
    Stefan> discoverability.

This is a good idea.  Thanks!

    Stefan> - blist-show-annotation says "No bookmarks to show" when it
    Stefan> should probably say "No annotation for this bookmark".  I
    Stefan> think?

Thanks, I will modify this later.

    Stefan> - Instead of the in-buffer header, you could use
    Stefan> `header-line-format', which means that the header stays on
    Stefan> top even as you scroll down.

I am not sure a header is that useful to see all the time.  But I
understand that some users might prefer the header.  I will attempt to
provide a user option to control this behaviour.  Thanks for the
suggestion.

-- 
Durand



  reply	other threads:[~2021-09-20  8:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-19  4:41 [ELPA] Want to submit two packages "ilist" and "blist" Durand
2021-09-19 10:15 ` Stefan Kangas
2021-09-20  8:39   ` Durand [this message]
2021-09-19 12:45 ` Stefan Monnier
2021-09-19 16:33 ` Adam Porter
2021-09-20  0:10   ` Durand
2021-09-20  1:56     ` Adam Porter
2021-09-19 16:43 ` Adam Porter
2021-09-19 23:40   ` Durand
2021-09-19 17:01 ` [External] : " Drew Adams
2021-09-19 23:59   ` Durand
2021-09-20  4:18     ` Drew Adams
2021-09-20 11:19       ` Durand
2021-09-20 15:25         ` Drew Adams
2021-09-20 23:48   ` Richard Stallman
2021-09-21  0:45     ` Durand
2021-09-20 23:47 ` Richard Stallman
2021-09-21  0:39   ` Durand

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2o88nej48.fsf@gmail.com \
    --to=mmemmew@gmail.com \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).