Atom backend for Gnus (nnatom)

Atom backend for Gnus (nnatom)

[Daniel Semyonov]

Hi,

About a year ago I wrote an Atom backend for Gnus based on the "Back End
Interface" section of the Gnus manual, and I've been working on it
on-and-off since then.
I have been reluctant to share it since unfortunately I don't have a
good understanding of Gnus' internals (and I don't have the time or
motivation to get a good understanding of it), and I ran into some
issues which I don't know how to fix.

That said, once those issues are worked around it seems to work very
well (I have been using it regularly for almost a year at this point,
without any further issues).

If there is anyone is interested in this, I'd appreciate help with the
remaining major issues; the repository for the backend can be found at:
https://git.sr.ht/~dsemy/nnatom
I have already assigned copyright to the FSF for Emacs a few months ago.

Some more details about the major issues:
- Group methods of new groups are usually corrupted, being replaced
  completely by the string "nnatom:<url or file of some nnatom group>".
  This can be worked around in the following way:
  1. Open the server containing the group and subscribe to it without
     opening the group itself.
  2. Press 'M-e' (gnus-group-edit-group-method) while point is on the
     new group in the *Group* buffer.
  3. Either write a new Gnus method or replace the URL with the correct
     one and confirm the change.
  This only needs to be done once for every group (if it is needed at
  all).  I've tried debugging this issue many times; I assume at this
  point that I'm missing something pretty obvious, but I can't figure it
  out unfortunately.
- Not plugged in at all to Gnus' inheritance system.
  I tried implementing this around half a year ago by following the
  manual and looking at other backends, but I ran into very weird issues
  (which I can't really remember the details of).
  Currently the function which reads and parses feeds,
  'nnatom--read-feed', uses simple subroutines to actually read the
  different parts of the feed.  If nnatom is plugged into Gnus'
  inheritance system, it should be very simple to modify
  'nnatom--read-feed' to run subroutines stored in variables, which in
  turn would make it very easy IMO to create new backend for read-only
  feeds which inherits from nnatom.  I made a POC RSS feed backend using
  this method a few days ago in less than an hour.

A few other minor issues are listed in the README.

Regards,
Daniel

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Hi Daniel,

Daniel Semyonov <daniel@dsemy.com> writes:

[...]

> If there is anyone is interested in this,

I'm interested.  I've been using an xsltproc workaround from Emacs Wiki
for Atom feeds, but I always thought a proper "nnatom" backend should be
made.  Nice to see you've done it!

> I'd appreciate help with the remaining major issues; the repository
> for the backend can be found at: https://git.sr.ht/~dsemy/nnatom I
> have already assigned copyright to the FSF for Emacs a few months ago.
>
> Some more details about the major issues:
> - Group methods of new groups are usually corrupted, being replaced
>   completely by the string "nnatom:<url or file of some nnatom group>".
>   This can be worked around in the following way:
>   1. Open the server containing the group and subscribe to it without
>      opening the group itself.
>   2. Press 'M-e' (gnus-group-edit-group-method) while point is on the
>      new group in the *Group* buffer.
>   3. Either write a new Gnus method or replace the URL with the correct
>      one and confirm the change.
>   This only needs to be done once for every group (if it is needed at
>   all).  I've tried debugging this issue many times; I assume at this
>   point that I'm missing something pretty obvious, but I can't figure it
>   out unfortunately.

I just tried nnatom with my blog's Atom feed and I didn't notice any
issue.  Selecting the feed in the *Group* buffer works fine and articles
load properly.  The *Server* buffer shows the link "opened".

Can you share the link to a failing feed, along with steps to reproduce
the issue?

Thomas

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Thomas Fitzsimmons writes:

    > I'm interested.  I've been using an xsltproc workaround from Emacs
    > Wiki for Atom feeds, but I always thought a proper "nnatom"
    > backend should be made.  Nice to see you've done it!

    >> I'd appreciate help with the remaining major issues; the
    >> repository for the backend can be found at:
    >> https://git.sr.ht/~dsemy/nnatom I have already assigned copyright
    >> to the FSF for Emacs a few months ago.
    >> 
    >> Some more details about the major issues: - Group methods of new
    >> groups are usually corrupted, being replaced completely by the
    >> string "nnatom:<url or file of some nnatom group>".  This can be
    >> worked around in the following way: 1. Open the server containing
    >> the group and subscribe to it without opening the group itself.
    >> 2. Press 'M-e' (gnus-group-edit-group-method) while point is on
    >> the new group in the *Group* buffer.  3. Either write a new Gnus
    >> method or replace the URL with the correct one and confirm the
    >> change.  This only needs to be done once for every group (if it
    >> is needed at all).  I've tried debugging this issue many times; I
    >> assume at this point that I'm missing something pretty obvious,
    >> but I can't figure it out unfortunately.

    > I just tried nnatom with my blog's Atom feed and I didn't notice
    > any issue.  Selecting the feed in the *Group* buffer works fine
    > and articles load properly.  The *Server* buffer shows the link
    > "opened".

Thanks for your interest and for testing.

    > Can you share the link to a failing feed, along with steps to
    > reproduce the issue?

This only happened when multiple nnatom groups were used, but in any
case I managed to fix it finally (I hope).  Note however that now server
addresses cannot be prefixed by "http{,s}://" and you may need to kill
preexisting nnatom groups.

I'd appreciate it if you could also test these latest changes (and with
multiple feeds).

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Thomas Fitzsimmons writes:
>
>     > I'm interested.  I've been using an xsltproc workaround from Emacs
>     > Wiki for Atom feeds, but I always thought a proper "nnatom"
>     > backend should be made.  Nice to see you've done it!
>
>     >> I'd appreciate help with the remaining major issues; the
>     >> repository for the backend can be found at:
>     >> https://git.sr.ht/~dsemy/nnatom I have already assigned copyright
>     >> to the FSF for Emacs a few months ago.
>     >> 
>     >> Some more details about the major issues: - Group methods of new
>     >> groups are usually corrupted, being replaced completely by the
>     >> string "nnatom:<url or file of some nnatom group>".  This can be
>     >> worked around in the following way: 1. Open the server containing
>     >> the group and subscribe to it without opening the group itself.
>     >> 2. Press 'M-e' (gnus-group-edit-group-method) while point is on
>     >> the new group in the *Group* buffer.  3. Either write a new Gnus
>     >> method or replace the URL with the correct one and confirm the
>     >> change.  This only needs to be done once for every group (if it
>     >> is needed at all).  I've tried debugging this issue many times; I
>     >> assume at this point that I'm missing something pretty obvious,
>     >> but I can't figure it out unfortunately.
>
>     > I just tried nnatom with my blog's Atom feed and I didn't notice
>     > any issue.  Selecting the feed in the *Group* buffer works fine
>     > and articles load properly.  The *Server* buffer shows the link
>     > "opened".
>
> Thanks for your interest and for testing.
>
>     > Can you share the link to a failing feed, along with steps to
>     > reproduce the issue?
>
> This only happened when multiple nnatom groups were used, but in any
> case I managed to fix it finally (I hope).  Note however that now server
> addresses cannot be prefixed by "http{,s}://" and you may need to kill
> preexisting nnatom groups.

I normally use gnus-group-make-rss-group, G R <full RSS URL> RET to
subscribe to RSS feeds in Gnus.  The minibuffer prompts for a title, and
then the group is immediately visible in the *Group* buffer.  Can you do
write gnus-group-make-atom-group for nnatom, eliminating the server
browsing step?  (I didn't notice the *Gnus Browse Server* intermediate
before -- i.e. that I wasn't already subscribed and put back into the
*Group* buffer.)

> I'd appreciate it if you could also test these latest changes (and with
> multiple feeds).

Hmm, now I can't just paste in the full URL without an error being
thrown; I think removing http:// or https:// (if required) should be
done by automatically nnatom.el, for useability.

I tried the latest version against my blog's
https://www.fitzsim.org/blog/?feed=atom URL.  I can browse the group
fine, but after I subscribe to it, when I hit RET in the *Group* buffer
I get "Couldn't open server" in the minibuffer.  *Server* shows:

{nnatom:www.fitzsim.org/blog/?feed=atom} (opened)

This is still all only using one feed so far.  I will test multiple
after one feed works from *Group*.

Thanks,
Thomas

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Thomas Fitzsimmons writes:

    > I normally use gnus-group-make-rss-group, G R <full RSS URL> RET
    > to subscribe to RSS feeds in Gnus.  The minibuffer prompts for a
    > title, and then the group is immediately visible in the *Group*
    > buffer.  Can you do write gnus-group-make-atom-group for nnatom,
    > eliminating the server browsing step?  (I didn't notice the *Gnus
    > Browse Server* intermediate before -- i.e. that I wasn't already
    > subscribed and put back into the *Group* buffer.)

I could do it, but I want to finish fixing the major issues before I
start adding convenience features.

    >> I'd appreciate it if you could also test these latest changes
    >> (and with multiple feeds).

    > Hmm, now I can't just paste in the full URL without an error being
    > thrown; I think removing http:// or https:// (if required) should
    > be done by automatically nnatom.el, for useability.

This is done due to the way Gnus parses the group name.  Since nnatom
supports adding "servers" in the usual Gnus way, this can't really be
fixed by nnatom.  The only real "fix" would be to automatically trim the
prefix when adding a group using a command like
'gnus-group-make-rss-group'.

    > I tried the latest version against my blog's
    > https://www.fitzsim.org/blog/?feed=atom URL.  I can browse the
    > group fine, but after I subscribe to it, when I hit RET in the
    > *Group* buffer I get "Couldn't open server" in the minibuffer.
    > *Server* shows:

    > {nnatom:www.fitzsim.org/blog/?feed=atom} (opened)

    > This is still all only using one feed so far.  I will test
    > multiple after one feed works from *Group*.

I've tried your feed with the new version and it works.

Did you kill the group after updating? This might be an issue of Gnus
keeping some old data about the group.  Try searching your ".newsrc.eld"
file for your feed to make sure it's deleted.

Otherwise,
- How did you add the feed?
- What is shown in the buffer opened when you press 'M-e' with point on the
  group in the *Group* buffer?

    > Thanks, Thomas

Thanks for your continued testing.

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Thomas Fitzsimmons writes:
>
>     > I normally use gnus-group-make-rss-group, G R <full RSS URL> RET
>     > to subscribe to RSS feeds in Gnus.  The minibuffer prompts for a
>     > title, and then the group is immediately visible in the *Group*
>     > buffer.  Can you do write gnus-group-make-atom-group for nnatom,
>     > eliminating the server browsing step?  (I didn't notice the *Gnus
>     > Browse Server* intermediate before -- i.e. that I wasn't already
>     > subscribed and put back into the *Group* buffer.)
>
> I could do it, but I want to finish fixing the major issues before I
> start adding convenience features.
>
>     >> I'd appreciate it if you could also test these latest changes
>     >> (and with multiple feeds).
>
>     > Hmm, now I can't just paste in the full URL without an error being
>     > thrown; I think removing http:// or https:// (if required) should
>     > be done by automatically nnatom.el, for useability.
>
> This is done due to the way Gnus parses the group name.  Since nnatom
> supports adding "servers" in the usual Gnus way, this can't really be
> fixed by nnatom.  The only real "fix" would be to automatically trim the
> prefix when adding a group using a command like
> 'gnus-group-make-rss-group'.

OK, makes sense.

>     > I tried the latest version against my blog's
>     > https://www.fitzsim.org/blog/?feed=atom URL.  I can browse the
>     > group fine, but after I subscribe to it, when I hit RET in the
>     > *Group* buffer I get "Couldn't open server" in the minibuffer.
>     > *Server* shows:
>
>     > {nnatom:www.fitzsim.org/blog/?feed=atom} (opened)
>
>     > This is still all only using one feed so far.  I will test
>     > multiple after one feed works from *Group*.
>
> I've tried your feed with the new version and it works.
>
> Did you kill the group after updating? This might be an issue of Gnus
> keeping some old data about the group.  Try searching your ".newsrc.eld"
> file for your feed to make sure it's deleted.

I'm starting from an empty home directory every test run.

> Otherwise,
> - How did you add the feed?
> - What is shown in the buffer opened when you press 'M-e' with point on the
>   group in the *Group* buffer?

Here's a screencast of what I did:

https://www.fitzsim.org/screenshots/nnatom-1.html

(the web player requires Free JavaScript, or you can download the .cast
file and play it using the command-line asciinema player.)

Thomas

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Thomas Fitzsimmons writes:

    >> Otherwise, - How did you add the feed?  - What is shown in the
    >> buffer opened when you press 'M-e' with point on the group in the
    >> *Group* buffer?

    > Here's a screencast of what I did:

    > https://www.fitzsim.org/screenshots/nnatom-1.html

Don't use 'gnus-group-subscribe', just press 'u'.  It is bound to a
different command when browsing a server
('gnus-browse-toggle-subscription-at-point').

FTR I also tried subscribing to a feed using the same method you used,
and it didn't work for me either.

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Thomas Fitzsimmons writes:
>
>     >> Otherwise, - How did you add the feed?  - What is shown in the
>     >> buffer opened when you press 'M-e' with point on the group in the
>     >> *Group* buffer?
>
>     > Here's a screencast of what I did:
>
>     > https://www.fitzsim.org/screenshots/nnatom-1.html
>
> Don't use 'gnus-group-subscribe', just press 'u'.  It is bound to a
> different command when browsing a server
> ('gnus-browse-toggle-subscription-at-point').

OK, thanks.

For comparison, the convenience function, gnus-group-make-rss-group,
asks for the blog title, with a reasonable default suggestion, and the
resulting line in *Group* for my blog is:

nnrss:fitzsim's development log

With the procedure you suggested, I end up with:

nnatom+www.fitzsim.org/blog/?feed=atom:fitzsim's development log

FWIW, I prefer the former.  I think the +.. part is necessary for stuff
like email where the field after the ":" is frequently the same (e.g.,
nnimap+mail.host1:INBOX, nnimap+mail.host2:INBOX) whereas blog titles
are usually unique, so the host/url designator becomes redundant.

Have you considered defining a `gnus-group-make-atom-group' convenience
function in nnatom.el (even though that's sort of a namespace
violation), and install a hook that binds that function to a key in the
*Group* buffer ("G A" seems to be available).

Anyway, thanks for this backend.  Once it is published I will do a sweep
of my xsltproc-using groups and reconfigure them for nnatom.

Thomas

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Thomas Fitzsimmons writes:

    > For comparison, the convenience function,
    > gnus-group-make-rss-group, asks for the blog title, with a
    > reasonable default suggestion, and the resulting line in *Group*
    > for my blog is:

    > nnrss:fitzsim's development log

    > With the procedure you suggested, I end up with:

    > nnatom+www.fitzsim.org/blog/?feed=atom:fitzsim's development log

    > FWIW, I prefer the former.  I think the +.. part is necessary for
    > stuff like email where the field after the ":" is frequently the
    > same (e.g., nnimap+mail.host1:INBOX, nnimap+mail.host2:INBOX)
    > whereas blog titles are usually unique, so the host/url designator
    > becomes redundant.

The procedure I suggested is pretty much the standard way to subscribe
to groups through Gnus.
Also, the '+...' part is necessary, nnrss doesn't need it for the same
reason it requires a special function to add groups.  If it really
bothers you customize the group line format.

    > Have you considered defining a `gnus-group-make-atom-group'
    > convenience function in nnatom.el (even though that's sort of a
    > namespace violation), and install a hook that binds that function
    > to a key in the *Group* buffer ("G A" seems to be available).

As I said before I have considered it, but not before fixing remaining
issues.  Honestly even then I don't really see why its so much more
convenient, other than it being familiar.
If you compare the two methods directly (G R <url> RET RET vs
B <url> RET u) they're very similar really.

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Daniel Semyonov <daniel@dsemy.com> writes:

>>>>>> Thomas Fitzsimmons writes:
>
>     > For comparison, the convenience function,
>     > gnus-group-make-rss-group, asks for the blog title, with a
>     > reasonable default suggestion, and the resulting line in *Group*
>     > for my blog is:
>
>     > nnrss:fitzsim's development log
>
>     > With the procedure you suggested, I end up with:
>
>     > nnatom+www.fitzsim.org/blog/?feed=atom:fitzsim's development log
>
>     > FWIW, I prefer the former.  I think the +.. part is necessary for
>     > stuff like email where the field after the ":" is frequently the
>     > same (e.g., nnimap+mail.host1:INBOX, nnimap+mail.host2:INBOX)
>     > whereas blog titles are usually unique, so the host/url designator
>     > becomes redundant.
>
> The procedure I suggested is pretty much the standard way to subscribe
> to groups through Gnus.
> Also, the '+...' part is necessary, nnrss doesn't need it for the same
> reason it requires a special function to add groups.  If it really
> bothers you customize the group line format.

OK.

>     > Have you considered defining a `gnus-group-make-atom-group'
>     > convenience function in nnatom.el (even though that's sort of a
>     > namespace violation), and install a hook that binds that function
>     > to a key in the *Group* buffer ("G A" seems to be available).
>
> As I said before I have considered it, but not before fixing remaining
> issues.

FWIW, I think it could/should go into GNU ELPA now.  You could open bug
reports about the remaining issues.  I think it's already useful.

> Honestly even then I don't really see why its so much more convenient,
> other than it being familiar.  If you compare the two methods directly
> (G R <url> RET RET vs B <url> RET u) they're very similar really.

True.  I didn't realize nnrss had non-standard behaviour.  I'll learn
the standard way.

Thanks,
Thomas

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

Hi,

I just wanted to update that I've managed to fix all the issues outlined
in my original mail.  The back end now only suffers from a few minor
issues that haven't impacted my usage at all (and possibly some hidden
bugs).

Is there no interest in having this added to Emacs?
Should this backend be added as a package instead?

Thanks,
Daniel

Re: Atom backend for Gnus (nnatom)

[Eli Zaretskii]

> From: Daniel Semyonov <daniel@dsemy.com>
> Date: Tue, 13 Jun 2023 10:07:41 +0300
> 
> Is there no interest in having this added to Emacs?
> Should this backend be added as a package instead?

I admit I don't understand what it means "Atom backend for Gnus".
What exactly does this give Emacs and Gnus users?

Re: Atom backend for Gnus (nnatom)

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> I admit I don't understand what it means "Atom backend for Gnus".

Atom is a fairly popular syndication format, similar to RSS 2 in
purpose.  It is one of the things that has kept me off of using Gnus for
news.  It is developed by the IETF:
https://datatracker.ietf.org/doc/html/rfc4287

> What exactly does this give Emacs and Gnus users?

Access to more feeds.  For instance, many publications choose to publish
syndication via Atom only.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Eli Zaretskii writes:

    > I admit I don't understand what it means "Atom backend for Gnus".
    > What exactly does this give Emacs and Gnus users?

It adds support for adding Atom feeds (a fairly well established RSS
alternative) as Gnus groups, allowing you to view them through the usual
Gnus interface.  Gnus has supported RSS for a while.

It's also very generic under the hood, and is now plugged in to Gnus'
inheritance system, so it should be a good base for future "feed-based"
Gnus backends.

Re: Atom backend for Gnus (nnatom)

[Thomas Fitzsimmons]

Hi Daniel,

Daniel Semyonov <daniel@dsemy.com> writes:

> I just wanted to update that I've managed to fix all the issues outlined
> in my original mail.  The back end now only suffers from a few minor
> issues that haven't impacted my usage at all (and possibly some hidden
> bugs).
>
> Is there no interest in having this added to Emacs?
> Should this backend be added as a package instead?

I think nnatom.el should be added to the Emacs repository, alongside
nnrss.el and the other Gnus backends.

Thomas

Re: Atom backend for Gnus (nnatom)

[Eric Abrahamsen]

Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:

> Hi Daniel,
>
> Daniel Semyonov <daniel@dsemy.com> writes:
>
>> I just wanted to update that I've managed to fix all the issues outlined
>> in my original mail.  The back end now only suffers from a few minor
>> issues that haven't impacted my usage at all (and possibly some hidden
>> bugs).
>>
>> Is there no interest in having this added to Emacs?
>> Should this backend be added as a package instead?
>
> I think nnatom.el should be added to the Emacs repository, alongside
> nnrss.el and the other Gnus backends.

I agree -- if possible it would be nice to keep all this code together.

Re: Atom backend for Gnus (nnatom)

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: Daniel Semyonov <daniel@dsemy.com>,  emacs-devel@gnu.org
> Date: Tue, 13 Jun 2023 10:07:09 -0700
> 
> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
> 
> > Hi Daniel,
> >
> > Daniel Semyonov <daniel@dsemy.com> writes:
> >
> >> I just wanted to update that I've managed to fix all the issues outlined
> >> in my original mail.  The back end now only suffers from a few minor
> >> issues that haven't impacted my usage at all (and possibly some hidden
> >> bugs).
> >>
> >> Is there no interest in having this added to Emacs?
> >> Should this backend be added as a package instead?
> >
> > I think nnatom.el should be added to the Emacs repository, alongside
> > nnrss.el and the other Gnus backends.
> 
> I agree -- if possible it would be nice to keep all this code together.

It seems like the consensus is that we should include this.  So please
work with the OP to add this to Emacs, and thanks.

Re: Atom backend for Gnus (nnatom)

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: Daniel Semyonov <daniel@dsemy.com>,  emacs-devel@gnu.org
>> Date: Tue, 13 Jun 2023 10:07:09 -0700
>> 
>> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>> 
>> > Hi Daniel,
>> >
>> > Daniel Semyonov <daniel@dsemy.com> writes:
>> >
>> >> I just wanted to update that I've managed to fix all the issues outlined
>> >> in my original mail.  The back end now only suffers from a few minor
>> >> issues that haven't impacted my usage at all (and possibly some hidden
>> >> bugs).
>> >>
>> >> Is there no interest in having this added to Emacs?
>> >> Should this backend be added as a package instead?
>> >
>> > I think nnatom.el should be added to the Emacs repository, alongside
>> > nnrss.el and the other Gnus backends.
>> 
>> I agree -- if possible it would be nice to keep all this code together.
>
> It seems like the consensus is that we should include this.  So please
> work with the OP to add this to Emacs, and thanks.

Working on it...

Re: Atom backend for Gnus (nnatom)

[Daniel Semyonov]

>>>>> Eric Abrahamsen writes:

    > Eli Zaretskii <eliz@gnu.org> writes:
    >> It seems like the consensus is that we should include this.  So
    >> please work with the OP to add this to Emacs, and thanks.

    > Working on it...

In the past few days I've identified and implemented as many features as
I could which will probably require breaking existing groups if added
later; the only one left (I think) is support for group descriptions
(I'll probably implement this today or tomorrow).

What needs to be done otherwise?
If all that's left after that is a news entry and adding to the manual I
can do it myself, though I'd appreciate it if someone with more
experience than me would look over the code...

Thanks,
Daniel

Re: Atom backend for Gnus (nnatom)

[Eli Zaretskii]

> From: Daniel Semyonov <daniel@dsemy.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Jun 2023 14:11:33 +0300
> 
> >>>>> Eric Abrahamsen writes:
> 
>     > Eli Zaretskii <eliz@gnu.org> writes:
>     >> It seems like the consensus is that we should include this.  So
>     >> please work with the OP to add this to Emacs, and thanks.
> 
>     > Working on it...
> 
> In the past few days I've identified and implemented as many features as
> I could which will probably require breaking existing groups if added
> later; the only one left (I think) is support for group descriptions
> (I'll probably implement this today or tomorrow).
> 
> What needs to be done otherwise?
> If all that's left after that is a news entry and adding to the manual I
> can do it myself, though I'd appreciate it if someone with more
> experience than me would look over the code...

Add whatever you think needs adding, and post the patch to the bug
tracker, so it could be reviewed by the relevant stakeholders and
other interested parties.  When the review is successfully completed,
the patches will be installed on the master branch.

Don't worry about your documentation talents: as part of the review
you will get comments and suggestions for improvements, and will learn
a lot from them.

Thanks.