GNU bug report logs - #74994
Improve Emacs iCalendar support

Previous Next

Full log

Message #53 received at 74994 <at> debbugs.gnu.org (full text, mbox):

From: Richard Lawrence <rwl <at> recursewithless.net>
To: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 74994 <at> debbugs.gnu.org
Subject: Re: bug#74994: Improve Emacs iCalendar support
Date: Wed, 22 Jan 2025 08:03:59 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Richard Lawrence <rwl <at> recursewithless.net>

>> I've been thinking it would make sense eventually to:
>>   - rename icalendar.el to something like diary-icalendar.el
>>   - rewrite the code there to use the new parser in icalendar-parser.el
>>   - rename the user-facing functions
>>     (icalendar-{import/export}-file and their variants)
>>     to make clear that they are diary-specific
>>   - delete(?)/deprecate the old parsing code
>
> I'd prefer to do this without renaming the old file.  That is, rename
> your new implementation to, say, icalendar2.el.  The rest of your plan
> sounds good to me.

Is this more about maintaining the source history, or about not wanting
to break the setups of people who have (require 'icalendar) or similar
in their configuration?

So far, all my new code lives in files with names like
icalendar-parser.el and there is no contention for the name
icalendar.el.

My thought was that icalendar.el could/should primarily serve as a
top-level module for the library, require-ing all the new modules
itself, so that users of the library can just (require 'icalendar) and
not have to worry about how the code is organized.

My reason for "renaming" was simply to move the existing diary-specific
parts of icalendar.el (which is most of the file) to diary-icalendar.el,
to be consistent with gnus-icalendar.el in Gnus, ox-icalendar.el in Org,
and the organization of the other new files.

If backward compatibility for users is the concern, icalendar.el could
itself (require 'diary-icalendar) and then there's no problem.

If instead it's about keeping the old code in the same file for the sake
of history, I understand; I don't have to move it, just thought it would
be cleaner if I did.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.