emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improving Emacs' iCalendar support


From: Sebastián Monía
Subject: Re: Improving Emacs' iCalendar support
Date: Fri, 18 Oct 2024 08:58:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Hello Richard!

Richard Lawrence <rwl@recursewithless.net> writes:
> Dear emacs-devel,
>
> This is an itch that's been bugging me for a while, and so for the past
> couple of weeks I've been working on scratching it, and I now have a
> reasonable chunk of work to share: I've drafted a new implementation of
> the iCalendar grammar, and a major mode which uses this grammar to
> provide syntax highlighting. I wrote up what I've done and why here:
>
> https://recursewithless.net/emacs/icalendar-parser-and-mode.org
>
> That's a literate Org mode file containing the code and my commentary.
> If you just want to read the code itself, see:
>
> https://recursewithless.net/emacs/icalendar/icalendar-parser.el
> https://recursewithless.net/emacs/icalendar/icalendar-mode.el

Will take a look, thank you for sharing!

> I could release this work as a package, but as I describe in more
> detail in the write-up, I think there's a good case that an improved
> iCalendar library belongs in Emacs' core. There are currently at least
> *three* partial iCalendar implementations in Emacs (icalendar.el,
> gnus-icalendar.el, and ox-icalendar.el), which are each focused on a
> particular major mode (diary, Gnus, and Org). I think it would be good
> to consolidate this work in one place and generalize it so that all
> three of these applications, as well as third party packages, can
> benefit.

I am only familiar with icalendar.el, which I consumed in this CalDAV
sync package: https://git.sr.ht/~sebasmonia/cdsync.el
I haven't used it much lately, but while testing it I found a few cases
not supported by icalendar.el At some point I wanted to try my hand at
fixing some bugs reported in the ical -> diary conversion.

> So, some questions for the list:
> 2) Would anyone here be willing to mentor me/collaborate with me on
> it?

I would be happy to help.

> 3) What should the library's API look like? What would be most useful?

Like Eli said in another reply, you are probably the best person to
define this now - until the library is merged, the API can change, so
don't stress too much over that _yet_ :)

Regards,
Seb

-- 
Sebastián Monía
https://site.sebasmonia.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]