From: Richard Lawrence <rwl@recursewithless.net>
To: emacs-devel@gnu.org
Subject: Re: Improving Emacs' iCalendar support
Date: Sat, 23 Nov 2024 09:44:47 +0100 [thread overview]
Message-ID: <87mshq9w5c.fsf@ohm.mail-host-address-is-not-set> (raw)
In-Reply-To: <87ed4dss2x.fsf@ohm.mail-host-address-is-not-set>
Dear emacs-devel,
Richard Lawrence <rwl@recursewithless.net> writes:
> I would like to start a discussion about improving Emacs' iCalendar
> support, beyond what is already available in icalendar.el. I personally
> would like to see Emacs gain a more full-fledged RFC5545 implementation
> that is primarily designed as a library for other applications to use.
Time for an update about this: I've been working steadily on the parser,
and I reached an important milestone this week: the parser can now parse
and reproduce all the examples in RFC5545, as well as my own calendar
data! There is still a lot of work to do, but this seems like a good
moment to ask again for feedback from anyone who's interested.
The repository where I've been doing this work is here:
https://sr.ht/~wyleyr/icalendar-el/
There are some instructions in the README for how to get started playing
around with the parser, for those interested in trying it out.
Based on the feedback I got earlier, I've made a few important design
decisions at this stage:
1) The basic form of the syntax tree is based on the format of the Org
parse tree in org-element-ast.el (though for now I have not implemented
any of the performance optimizations). Syntax nodes are a four-element
list of a type symbol, a metadata structure, a value, and a list of
children. Type symbols are used to store metadata about all the
iCalendar grammar categories and to do type-based dispatch in the
parser.
2) As far as possible, I have represented iCalendar data using "native"
data types in Emacs: dates are represented as calendar.el dates,
date-times as decoded-times, text as strings or buffer regions, etc.
This should hopefully make it as easy as possible to use iCalendar data
and parse trees from elsewhere in Emacs. In cases where no data type
already exists, the data types I defined are usually simple lists with
accessors defined for different fields.
(My initial attempts used cl-structs for the data types, following Adam
Porter's suggestion, but I quickly found myself writing tons of
boilerplate to convert between these structs and the "native" formats,
so I abandoned it. I am using a struct for syntactic metadata stored by
the parser, though.)
3) I have focused a lot on making good documentation, since I think
Emacs' documentation system is one of its best features, and the lack of
documentation in icalendar.el is one of the things that makes it
difficult to work with. All the symbols in the library should have good
documentation available via M-x describe-symbol -- please let me know if
you find anything confusing or broken in these docs.
Many thanks in advance for your thoughts!
Best,
Richard
next prev parent reply other threads:[~2024-11-23 8:44 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-18 9:01 Improving Emacs' iCalendar support Richard Lawrence
2024-10-18 9:24 ` Eli Zaretskii
2024-10-19 8:22 ` Richard Lawrence
2024-10-19 10:11 ` Eli Zaretskii
2024-10-20 5:08 ` Richard Lawrence
2024-10-20 5:21 ` Eli Zaretskii
2024-10-18 12:58 ` Sebastián Monía
2024-10-19 8:28 ` Richard Lawrence
2024-10-19 5:44 ` Adam Porter
2024-10-19 8:39 ` Richard Lawrence
2024-10-20 3:09 ` Adam Porter
2024-10-22 18:40 ` Ihor Radchenko
2024-10-23 7:29 ` Björn Bidar
2024-10-23 9:01 ` Richard Lawrence
2024-10-23 20:24 ` Ferdinand Pieper
2024-10-24 14:52 ` Richard Lawrence
2024-10-24 17:45 ` Ihor Radchenko
2024-10-25 12:53 ` Richard Lawrence
2024-10-25 18:59 ` Ihor Radchenko
[not found] ` <87plnr6zvk.fsf@>
2024-10-23 8:09 ` Ihor Radchenko
2024-10-23 9:05 ` Richard Lawrence
2024-10-23 10:03 ` Björn Bidar
2024-10-21 6:10 ` Björn Bidar
2024-10-21 6:22 ` Visuwesh
2024-10-23 9:15 ` Richard Lawrence
2024-10-23 9:45 ` Visuwesh
[not found] ` <87wmi29eaf.fsf@>
2024-10-26 17:49 ` Ihor Radchenko
2024-10-28 10:44 ` Björn Bidar
[not found] ` <87r080tslf.fsf@>
2024-10-28 19:09 ` Ihor Radchenko
2024-11-23 8:44 ` Richard Lawrence [this message]
2024-11-24 9:50 ` Eli Zaretskii
2024-11-24 10:21 ` Ihor Radchenko
2024-11-24 10:41 ` Eli Zaretskii
2024-11-24 10:58 ` Ihor Radchenko
2024-11-24 11:08 ` Eli Zaretskii
2024-11-24 11:21 ` Upstreaming org-element-ast (was: Improving Emacs' iCalendar support) Ihor Radchenko
2024-11-24 12:55 ` Eli Zaretskii
2024-11-25 9:09 ` Improving Emacs' iCalendar support Richard Lawrence
2024-11-25 12:42 ` Eli Zaretskii
2024-11-25 13:03 ` Rudolf Schlatte
2024-11-25 13:36 ` Eli Zaretskii
2024-11-25 17:14 ` Richard Lawrence
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=87mshq9w5c.fsf@ohm.mail-host-address-is-not-set \
--to=rwl@recursewithless.net \
--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).