[ELPA] Want to submit two packages "ilist" and "blist"

[ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

Hello,

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.

The two packages can be found via the following links:

<https://gitlab.com/mmemmew/ilist/>
<https://gitlab.com/mmemmew/blist/>

I heard that I should sign some copyright assignment paper.  Could you
please send me the form for the copyright assignment to the Free
Software Foundation?

I know nothing about the submission process, so send a mail to ask for
details.  Any responses are appreciated, and thanks in advance in any
case.

-- 
Durand

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Stefan Kangas]

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.

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

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

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

Some other scattered comments:

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

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

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

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

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

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

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Stefan Monnier]

Hi,

> I heard that I should sign some copyright assignment paper.  Could you
> please send me the form for the copyright assignment to the Free
> Software Foundation?

Fill the form below and send it as instructed to the FSF so they can
send you the appropriate paperwork [ I just heard that the FSF staff
handling this is currently understaffed, so don't be surprised if it
takes a week to get an answer :-(  ]

> I know nothing about the submission process, so send a mail to ask for
> details.

You're doing it right, thank you,


        Stefan


Please email the following information to assign@gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your postal address here.]





[Which files have you changed so far, and which new files have you written
so far?]

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Adam Porter]

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.

I see in your readme that you mention grouping.  Rather than
reimplementing that, you may be interested in what I've done in
taxy.el.  For example, it makes it trivial to define a custom grouping
DSL and a custom column-based view using magit-section.el.  See the
example "bookmarky" application:

https://github.com/alphapapa/taxy.el/blob/master/examples/bookmarky.el

It ends up looking like this:

https://raw.githubusercontent.com/alphapapa/taxy.el/master/images/bookmarky.png

Grouping keys and display columns are defined with simple top-level
forms, and these keys and columns can be customized by users by using
the same top-level forms in their configs.  For example:

  (bookmarky-define-key filename (&key name regexp)
    "Return NAME if bookmark ITEM's filename matches REGEXP, or without REGEXP, the filename."
    (when-let (filename (bookmark-prop-get item 'filename))
      (pcase regexp
        (`nil filename)
        (_ (when (string-match-p regexp filename)
             name)))))

  (bookmarky-define-column "File" (:max-width nil :face font-lock-doc-face)
    (bookmark-prop-get item 'filename))

Then a grouping "program" written in the DSL looks like:

  (defvar bookmarky-default-keys
    '(
      ((handler '(burly-bookmark-handler) :name "Burly"))
      ((directory "~/src/emacs/" :name "Emacs" :descendant-p t)))
    "Default keys.")

Turning the resulting hierarchy into the magit-section-based view is
done with a few functions in a standard way, so there's very little
bespoke code to write.

I'll probably publish taxy-magit-section.el on ELPA as a separate
package after it matures a bit more.

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

>>>>> On Sun, 19 Sep 2021 11:33:01 -0500, Adam Porter <adam@alphapapa.net> said:

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

    Adam> I see in your readme that you mention grouping.  Rather than
    Adam> reimplementing that, you may be interested in what I've done
    Adam> in taxy.el.  For example, it makes it trivial to define a
    Adam> custom grouping DSL and a custom column-based view using
    Adam> magit-section.el.  See the example "bookmarky" application:

    Adam> https://github.com/alphapapa/taxy.el/blob/master/examples/bookmarky.el

    Adam> It ends up looking like this:

    Adam> https://raw.githubusercontent.com/alphapapa/taxy.el/master/images/bookmarky.png

Thanks for the information.  I did not know about taxy.el previously.
It seems to be an interesting library.  It reminds me of hierarchy.el by
the way: <https://github.com/DamienCassou/hierarchy>.

    Adam> Grouping keys and display columns are defined with simple
    Adam> top-level forms, and these keys and columns can be customized
    Adam> by users by using the same top-level forms in their configs.
    Adam> For example:

    Adam>   (bookmarky-define-key filename (&key name regexp) "Return
    Adam> NAME if bookmark ITEM's filename matches REGEXP, or without
    Adam> REGEXP, the filename."  (when-let (filename (bookmark-prop-get
    Adam> item 'filename)) (pcase regexp (`nil filename) (_ (when
    Adam> (string-match-p regexp filename) name)))))

    Adam>   (bookmarky-define-column "File" (:max-width nil :face
    Adam> font-lock-doc-face) (bookmark-prop-get item 'filename))

    Adam> Then a grouping "program" written in the DSL looks like:

    Adam>   (defvar bookmarky-default-keys '( ((handler
    Adam> '(burly-bookmark-handler) :name "Burly")) ((directory
    Adam> "~/src/emacs/" :name "Emacs" :descendant-p t))) "Default
    Adam> keys.")

    Adam> Turning the resulting hierarchy into the magit-section-based
    Adam> view is done with a few functions in a standard way, so
    Adam> there's very little bespoke code to write.

    Adam> I'll probably publish taxy-magit-section.el on ELPA as a
    Adam> separate package after it matures a bit more.

From what I can tell, the taxy.el plays the role of "ilist" in "blist",
right?

I think I will enjoy reading it afterwards.

-- 
Durand

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Adam Porter]

Durand <mmemmew@gmail.com> writes:

> Thanks for the information.  I did not know about taxy.el previously.
> It seems to be an interesting library.  It reminds me of hierarchy.el by
> the way: <https://github.com/DamienCassou/hierarchy>.

They're similar in that they're both related to hierarchies, but they
work very differently.

> From what I can tell, the taxy.el plays the role of "ilist" in "blist",
> right?

Almost: taxy-magit-section.el is like a magit-section-based front-end to
the programmable classification provided by taxy.el as a back-end.
Other front-ends could use taxy.el as a back-end as well.

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Adam Porter]

Durand <mmemmew@gmail.com> writes:

> The two packages can be found via the following links:
>
> <https://gitlab.com/mmemmew/ilist/>
> <https://gitlab.com/mmemmew/blist/>

By the way, I see in ilist.el this comment:

  ;; This is similar to using `cl-defstruct', but this struct is so
  ;; simple that depending on the cl library seems unnecessary to me.

You may not know that `cl' has been part of Emacs for over 30 years.
It's curious why some users seem to have an aversion to it.  Somehow
there's this persistent myth that using it in a library would be not
minimalistic enough, yet cl-lib is used by Emacs's own code, so it's
loaded anyway, and its code is standard and reliable.

So rather than defining a number of aliases for a bespoke list format
like:

  ;;;; column accessors

  (defalias 'ilist-column-name 'car
    "Return the NAME of COLUMN.

  \(fn COLUMN)")

  (defalias 'ilist-column-fun 'cadr
    "Return the FUN in COLUMN.

  \(fn COLUMN)")

  (defalias 'ilist-column-min 'caddr
    "Return the MIN in COLUMN.

  \(fn COLUMN)")

  (defalias 'ilist-column-max 'cadddr
    "Return the MAX in COLUMN.

  \(fn COLUMN)")

  ;; Unfortunately (or not) there is no caddddr and cadddddr.
  (defun ilist-column-align (column)
    "Return the ALIGN in COLUMN."
    (nth 4 column))

  (defun ilist-column-elide (column)
    "Return the ELIDE in COLUMN."
    (nth 5 column))

It would be much more efficient and simple to just use cl-defstruct.

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

Thanks for the reminder, but no, I did not try to avoid the cl library
deliberately.  I have no concern with using it.  It just happened that I
wrote those codes first without realizing that I could do the same with
cl-defstruct.  When I found it out later, I thought that, now that the
codes are working, I would rather keep it there, instead of trying to
refactor without really improving the codes (in my opinion).

By the way, I guess that some people don't like using cl library because
it had some major changes in the past, and some packages did not catch
up with the changes, so that the users got notified of non-conforming
codes using the cl library.

-- 
Durand

RE: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Drew Adams]

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

As the author of Bookmark+, I want to say that
I'm positively impressed by your attention to
documenting, which I can tell just by looking
at the provided PDFs.

And I commend the features the doc describes.

From just reading that doc, it appears that all
of the Blist features are already features of
Bookmark+.  (Of course, Blist is young.)

That's _good_.  It suggests that such features
are in fact helpful (it corroborates having them
in Bookmark+).

It's also a bit disappointing to me, though, as
I was hoping to find some new features that I
might want to consider for possible addition or
adaptation to Bookmark+, to improve it.  But I
haven't found any that are missing, so far.

It's no doubt worth my looking at the code too
at some point, to see if there are undocumented
features or if there's something else to be
learned from what you've done.

So Bravo!  Thanks for your attention to bookmark
presentation.  And thanks in particular for the
good job documenting what you've created.
___

A minor hiccup we both might want to work around:

Emacs 28 replaced the hard-coded string
"*Bookmark List*" as the name of the list buffer
with the defconst `bookmark-bmenu-buffer' with
that string value.

Both Bookmark+ and blist.el use that "constant",
which means they use the same buffer.  It might
be good for our code to use different variables
for the buffer name.  E.g., I could add and use
a user option `bmkp-bmenu-buffer', whose default
value is that of `bookmark-bmenu-buffer'.  And
you could do similarly.  (Just a suggestion.)
___

A minor suggestion for `blist-filter-groups':
Instead of just telling users to put the default
group at the end of the groups list, you might
want to either do that automatically or provide
an easy way to do that in the Customize UI.

[BTW, you (and users) can directly use the many
 existing Bookmark+ type predicates in Blist
 filter groups: e.g., `bmkp-info-bookmark-p' for
 Info bookmarks, `bmkp-dired-bookmark-p' for
 Dired bookmarks, `bmkp-desktop-bookmark-p' for
 Desktop bookmarks,...

 With Bookmark+ there are no named groups, but
 you can sort by bookmark kind using `s k'.
 You can sort in many (23) ways; sorting by
 bookmark type is one way. ]
___

It's interesting that you took as your point of
departure Ibuffer.  (And it's no doubt useful
to have built blist.el on top of the more
general ilist.el.)

I took Dired as one of my points of departure,
for the bookmark-list display.  The UI is very
close to that of Dired.  But I think that
Ibuffer itself took the Dired UI as a starting
point, so there's a lot of similarity between
where you ended up and where I did, wrt the UI.

Just as I might learn something looking at
what you've done, I invite you to look at what
Bookmark+ does, if you're interested.

https://www.emacswiki.org/emacs/BookmarkPlus

Re: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

>>>>> On Sun, 19 Sep 2021 17:01:27 +0000, Drew Adams <drew.adams@oracle.com> said:

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

    Drew> As the author of Bookmark+, I want to say that I'm positively
    Drew> impressed by your attention to documenting, which I can tell
    Drew> just by looking at the provided PDFs.

    Drew> And I commend the features the doc describes.

    Drew> From just reading that doc, it appears that all of the Blist
    Drew> features are already features of Bookmark+.  (Of course, Blist
    Drew> is young.)

I have seen your library before writing BList.  But my main motivation
was the Ibuffer-like display, and Bookmark+ does not seem to provide one
(at least I cannot tell from its docs), so I wrote BList anyways.  :)

    Drew> That's _good_.  It suggests that such features are in fact
    Drew> helpful (it corroborates having them in Bookmark+).

    Drew> It's also a bit disappointing to me, though, as I was hoping
    Drew> to find some new features that I might want to consider for
    Drew> possible addition or adaptation to Bookmark+, to improve it.
    Drew> But I haven't found any that are missing, so far.

Well, Bookmark+ is already huge and provides many useful
functionalities.  I would surprised if my simple package has any new
features.  ;P

That being said, have you looked into `blist-select' and
`blist-select-manner'?  I think that is probably the "strangest" feature
of this package, and hence the most likely to be new.  It might be fun
anyways.  :)

    Drew> It's no doubt worth my looking at the code too at some point,
    Drew> to see if there are undocumented features or if there's
    Drew> something else to be learned from what you've done.

    Drew> So Bravo!  Thanks for your attention to bookmark presentation.
    Drew> And thanks in particular for the good job documenting what
    Drew> you've created.  ___

Thanks for the appreciation.  :D

    Drew> A minor hiccup we both might want to work around:

    Drew> Emacs 28 replaced the hard-coded string "*Bookmark List*" as
    Drew> the name of the list buffer with the defconst
    Drew> `bookmark-bmenu-buffer' with that string value.

    Drew> Both Bookmark+ and blist.el use that "constant", which means
    Drew> they use the same buffer.  It might be good for our code to
    Drew> use different variables for the buffer name.  E.g., I could
    Drew> add and use a user option `bmkp-bmenu-buffer', whose default
    Drew> value is that of `bookmark-bmenu-buffer'.  And you could do
    Drew> similarly.  (Just a suggestion.)  ___
    
Sure, I will do so.  Thanks for the suggestion.

    Drew> A minor suggestion for `blist-filter-groups': Instead of just
    Drew> telling users to put the default group at the end of the
    Drew> groups list, you might want to either do that automatically or
    Drew> provide an easy way to do that in the Customize UI.

I am still thinking of better ways to do that indeed.  Maybe I can use a
function to produce the filter groups automatically.  I am not familiar
with the Customize UI though, so I will have to look up how to make it
easy in the Customize UI.

    Drew> [BTW, you (and users) can directly use the many existing
    Drew> Bookmark+ type predicates in Blist filter groups: e.g.,
    Drew> `bmkp-info-bookmark-p' for Info bookmarks,
    Drew> `bmkp-dired-bookmark-p' for Dired bookmarks,
    Drew> `bmkp-desktop-bookmark-p' for Desktop bookmarks,...

I am not using Bookmark+ myself.  Surely I can recommend to use
Bookmark+ features in the documentations / README.  Or are you
suggesting for blist to depend on and extend Bookmark+?

    Drew>  With Bookmark+ there are no named groups, but you can sort by
    Drew> bookmark kind using `s k'.  You can sort in many (23) ways;
    Drew> sorting by bookmark type is one way.  ] ___

    Drew> It's interesting that you took as your point of departure
    Drew> Ibuffer.  (And it's no doubt useful to have built blist.el on
    Drew> top of the more general ilist.el.)

I really like Ibuffer: it makes managing buffers simple and easy.  :D

By the way, I thought I would like to display registers by ilist in a
similar way (and adapt in another of my package "rlist"), but after some
experiments that kind of display does not look good for registers to me,
so I am still estimating the possibilities.  (rlist can be found here:
<https://gitlab.com/mmemmew/rlist/>)

    Drew> I took Dired as one of my points of departure, for the
    Drew> bookmark-list display.  The UI is very close to that of Dired.
    Drew> But I think that Ibuffer itself took the Dired UI as a
    Drew> starting point, so there's a lot of similarity between where
    Drew> you ended up and where I did, wrt the UI.

Indeed.

    Drew> Just as I might learn something looking at what you've done, I
    Drew> invite you to look at what Bookmark+ does, if you're
    Drew> interested.

    Drew> https://www.emacswiki.org/emacs/BookmarkPlus

Sure, I will look into that in the coming future.

-- 
Durand

RE: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Drew Adams]

> my main motivation was the Ibuffer-like display, and
> Bookmark+ does not seem to provide one (at least I
> cannot tell from its docs), so I wrote BList anyways.  :)

I see.  I took a look, but it's not clear to
me what the display differences are.  What's
an example of an Ibuffer-like display feature
that you're thinking of here?

> That being said, have you looked into `blist-select' and
> `blist-select-manner'?  I think that is probably the
> "strangest" feature of this package, and hence the most
> likely to be new.  It might be fun anyways.  :)

I see.  No, I hadn't noticed that.  Apparently
it's about which windows to use for bookmark
targets, when you open ("jump to") multiple
bookmarks.  You can do that in various
configurations, such as a spiral of windows.

By default, Bookmark+ uses only the same or
other window - or other frame.  When jumping
to the marked bookmarks, other windows are
used (other-frames if `pop-up-frames').

[But you can use anything as a bookmark "jump"
function.  And different types of bookmarks
can have their type-specific jump functions.
(And some kinds of bookmarks don't need to
use windows at all: their "locations" are
something else.)]

> > can directly use the many existing Bookmark+
> > type predicates in Blist filter groups
> 
> I am not using Bookmark+ myself.  Surely I can recommend to use
> Bookmark+ features in the documentations / README.  Or are you
> suggesting for blist to depend on and extend Bookmark+?

No, no.  I was just mentioning that some type
predicates exist, and they work fine with Blist.

Re: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

>>>>> On Mon, 20 Sep 2021 04:18:37 +0000, Drew Adams <drew.adams@oracle.com> said:

    >> my main motivation was the Ibuffer-like display, and Bookmark+
    >> does not seem to provide one (at least I cannot tell from its
    >> docs), so I wrote BList anyways.  :)

    Drew> I see.  I took a look, but it's not clear to me what the
    Drew> display differences are.  What's an example of an Ibuffer-like
    Drew> display feature that you're thinking of here?

I mean that the bookmarks are grouped under various sections, and I can
hide / unhide the sections by pressing return when the point is over the
group header, and can jump to headers by M-n / M-p, things like this.
Perhaps Bookmark+ already provides this kind of ability?  In that case I
need to play with Bookmark+ then.  :)

    >> That being said, have you looked into `blist-select' and
    >> `blist-select-manner'?  I think that is probably the "strangest"
    >> feature of this package, and hence the most likely to be new.  It
    >> might be fun anyways.  :)

    Drew> I see.  No, I hadn't noticed that.  Apparently it's about
    Drew> which windows to use for bookmark targets, when you open
    Drew> ("jump to") multiple bookmarks.  You can do that in various
    Drew> configurations, such as a spiral of windows.

    Drew> By default, Bookmark+ uses only the same or other window - or
    Drew> other frame.  When jumping to the marked bookmarks, other
    Drew> windows are used (other-frames if `pop-up-frames').

    Drew> [But you can use anything as a bookmark "jump" function.  And
    Drew> different types of bookmarks can have their type-specific jump
    Drew> functions.  (And some kinds of bookmarks don't need to use
    Drew> windows at all: their "locations" are something else.)]

    >> > can directly use the many existing Bookmark+ > type predicates
    >> in Blist filter groups
    >> 
    >> I am not using Bookmark+ myself.  Surely I can recommend to use
    >> Bookmark+ features in the documentations / README.  Or are you
    >> suggesting for blist to depend on and extend Bookmark+?

    Drew> No, no.  I was just mentioning that some type predicates
    Drew> exist, and they work fine with Blist.

I see.  Okay.  :D

-- 
Durand

RE: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Drew Adams]

> bookmarks are grouped under various sections, and I can
> hide / unhide the sections by pressing return when the point is over
> the group header, and can jump to headers by M-n / M-p, things like this.
> Perhaps Bookmark+ already provides this kind of ability?

Yes and no.

Grouping by types, yes.  But types are
distinguished by face and other means, not
with headers.  There are multiple sort
orders, of which sorting by type (group)
is just one.  A face shows you the type
no matter what the sort order is.

There's no cursor movement among groups.
But you can show (or mark, or jump to, or
cycle among, ...) the bookmarks of a given
type/group.

And there are lots of operations you can
perform on the marked bookmarks, so you
can mark all those of a given type and
then do whatever you like to/with them.

> >> I am not using Bookmark+ myself.  Surely I can recommend to use
> >> Bookmark+ features in the documentations / README.  Or are you
> >> suggesting for blist to depend on and extend Bookmark+?
> 
>> No, no.  I was just mentioning that some type
>> predicates exist, and they work fine with Blist.
> 
> I see.  Okay.  :D

To be more clear about this: I was trying
to point out that what Blist provides is
a different way of showing and interacting
with a bookmark list - any list of regular
bookmarks.

Because it does so with ordinary Emacs
bookmarks (e.g. not the pseudo-bookmarks
of EWW or Org or whatever), it can be used
with bookmarks of all sorts.

E.g., one can use Blist as an alternative
"front end".  That's true for Bookmark+
bookmarks as it is for vanilla bookmarks.
I was saying that I tried using Bookmark+
bookmarks with Blist, and confirming that
I encountered no problem.

Bookmark+ is much more than its enhancement
of the standard "Bmenu" bookmark-list
display.  There's no requirement to use its
list display to take advantage of Bookmark+.

(But that display does offer handy features
for using and managing sets of bookmarks, I
think.)
___

I think that too often some people seem to
think that to use bookmarks you need to
show the list of bookmarks and interact
with that displayed list.  Not at all.

That's no more true than to use files you
need to access them with Dired, or to use
buffers you need to access them with
Ibuffer or Buffer Menu.

In particular, _jumping_ to bookmarks
("opening" them) is not really what the
bookmark-list display is for.  That front
end is for _managing sets_ of bookmarks.

Jumping to bookmarks from there is a
minor feature.  Especially if one has a
good completion "framework", going
through a display-list front end just to
jump to bookmarks can be an unnecessary
detour.

Such a display list is a hub for doing
all kinds of useful things with a set
of objects.

Re: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If we can get a copyright assignment for the code from blist,
we have the option of adding that to Emacs itself.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [External] : [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

I have sent the form that Stefan Monnier kindly provided to
assign@gnu.org.  Since I am a graduate student at a university, I now
have to find out the one in charge of licensing matters in the
university, so as to get the university disclaimer.

By the way, I pressed the wrong key in Gnus when replying to Stefan,
so my reply did not end up on the mailing list.  To reduce traffic, I
think I will not re-send it here.

-- 
Durand

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > The package "blist" is to display the list of bookmarks, in the sense of
  > "bookmark.el", in a similar way as Ibuffer.

Might it be more natural to add that code to bookmark.el?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] Want to submit two packages "ilist" and "blist"

[Durand]

While I prefer to list bookmarks by BList, I think that the default
bookmark list is more compact if the list of bookmarks is not long, so
maybe some users prefer that list.  If we add BList to bookmark.el
then perhaps there should be an option for the user to choose which
display to use.

Also, I regard the difference between blist and bookmark-bmenu-list as
similar to that between ibuffer and buffer-menu.  So it seems to me to
be natural to offer blist as a separate command from
bookmark-bmenu-list.

-- 
Durand