From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Lawrence Newsgroups: gmane.emacs.devel Subject: Re: Improving Emacs' iCalendar support Date: Thu, 24 Oct 2024 16:52:19 +0200 Message-ID: <87y12d8sf0.fsf@ohm.mail-host-address-is-not-set> References: <87ed4dss2x.fsf@ohm.mail-host-address-is-not-set> <0bacd69a-7941-44d2-ac5e-3ae3f256481a@alphapapa.net> <87r08cqye8.fsf@ohm.mail-host-address-is-not-set> <87zfmwyoa9.fsf@localhost> <87bjzbp509.fsf@ohm.mail-host-address-is-not-set> <87plnqpnxr.fsf@pie.tf> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18523"; mail-complaints-to="usenet@ciao.gmane.io" To: Ferdinand Pieper , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 24 16:53:05 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1t3zCx-0004d4-VJ for ged-emacs-devel@m.gmane-mx.org; Thu, 24 Oct 2024 16:53:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t3zCS-0007MD-2d; Thu, 24 Oct 2024 10:52:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3zCO-0007Lr-LP for emacs-devel@gnu.org; Thu, 24 Oct 2024 10:52:28 -0400 Original-Received: from fhigh-b2-smtp.messagingengine.com ([202.12.124.153]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1t3zCM-0003Da-RP for emacs-devel@gnu.org; Thu, 24 Oct 2024 10:52:28 -0400 Original-Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41]) by mailfhigh.stl.internal (Postfix) with ESMTP id E683D25400C8; Thu, 24 Oct 2024 10:52:23 -0400 (EDT) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-01.internal (MEProxy); Thu, 24 Oct 2024 10:52:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= recursewithless.net; h=cc:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1729781543; x=1729867943; bh=PARvWjCPPvcE4J4Lc8JsUBjGGTabOV/PdJyTkp4OP3A=; b= ah1JCfrpxfq7022AZvBOvFxHJ0728tmY6JxNcayO7H1bP7QqeUHiguK7ePxFG92n zF5QtQNp8xB5tBUB7WSoYBdmIK5mxT9aULhJGkbyOoOe3FsDJCd3IZ7hmWxsBP7V i5rPimMof+jwIarW+yYcIZrpY5H+yb6PQUKgW8mUcFvKFQKf0r4jeCLTKsWtk2o+ XZ1xC6t9/HGj6sHnmY1P+LhM0relcyWHIwRqGwwDcFhFhw99Km2onAeU1FZ0B8Fg mSILhv45seJExtxeMEEd1kyjef59G4vIko9pZl39CYc1y3iE5IlCPQoy9aMjZi9H SNYhCX0yjygLko/o3nfRfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1729781543; x=1729867943; bh=PARvWjCPPvcE4J4Lc8JsUBjGGTab OV/PdJyTkp4OP3A=; b=PR0esoP38Xc9GQLeilVbXic9ioO49j0QyVgFoSuLkmtj sTko3Yt3bzq0+ir0g8nv/wLH5AP9YWWu1qd/yHoSjIJP9A2shMA4SUeFMQr1CIJb kuE6DpCjreOixlwQr/25BHmjtSgk8q8o7Atbl4BTJrS48tkQZyQBUCC6FPbtXCd7 JCGPUuFHJLiR1VLacpoYdHaA0B8/3iRiJ8BTj7a1f3Dx0ClRwmP1DtSGRf+p+DQb cki4yoohqtNx0dMpeo0LdsxAiw9MdNht/+2Vzw6MdiN3XRzopbY8M0GjSfdRZVlL i0mlzUTu3t9r2BY3pEcJvCpYzA5JjmYmyQ34IehwYA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrvdejtddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnh htshculddquddttddmnecujfgurhephffvufgjfhffkfggtgesthdtredttddttdenucfh rhhomheptfhitghhrghrugcunfgrfihrvghntggvuceorhiflhesrhgvtghurhhsvgifih hthhhlvghsshdrnhgvtheqnecuggftrfgrthhtvghrnhepffduvdeitdevjeetgefgffff udfhheelhfffieevgfeljedvfeekvefgkedtfffhnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhiflhesrhgvtghurhhsvgifihhthhhlvghs shdrnhgvthdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpth htohepfhgvrhguihesnhgrnhgurdighiiipdhrtghpthhtohepvghmrggtshdquggvvhgv lhesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: if7394488:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Oct 2024 10:52:22 -0400 (EDT) In-Reply-To: <87plnqpnxr.fsf@pie.tf> Received-SPF: pass client-ip=202.12.124.153; envelope-from=rwl@recursewithless.net; helo=fhigh-b2-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324820 Archived-At: Hi Ferdinand, Ferdinand Pieper writes: > Emacs is really lacking a central parser for iCalendar and a common > internal representation of iCalendar items. I have ran over this > several times, but was always very quick to shy away from working on a > central overhaul of icalendar.el. I resorted to small extensions of > gnus-icalendar.el to bring event (request) creation to gnus, which > still is very much in a prototype state [1]. > > While I started extending the gnus-icalendar-event EIEIO class to > support property parameters, it ended up being very cumbersome to > create new event objects with all parameters correctly set. This is good feedback, thank you. Can you say more about what exactly was cumbersome about it? (Was it the need to call various constructors, instead of just consing up lists? or the need to interact with objects via setters/getters? or lack of validation of parameter lists? or...?) > I think structs could be a good fit for the internal representation. > Creating these from scratch should still be kept fairly > straightforward for ease of use. There could also be a translation > function that creates the appropriate struct from a very basic list > representation like this: > > --8<---------------cut here---------------start------------->8--- > (VCALENDAR > ((PRODID nil "-//...") > (VERSION nil "2.0")) > (VEVENT > (;; ... > (DTSTART ((VALUE "DATE")) "20241201") > (DTEND ((VALUE "DATE")) "20241231")))) > --8<---------------cut here---------------end--------------->8--- Yes, as I'm sure you're aware, icalendar.el creates a list representation like this. I've been thinking we might need such a function anyway for the sake of backward compatibility. And the more I think about it, the more I realize that a list representation with a few accessors should be just fine for the "container" types (components, properties, attribute lists). The disadvantage of a representation like the one above is there is no structure yet in the *value* types: e.g. "20241201" is just a string, not a date. This is fine for export (assuming you've already validated the data...) but when reading the data, one needs to parse these values too, and this is what I've been using structs for so far. So do you think it would still be too cumbersome to have a representation like > ... (DTSTART ((VALUE "DATE")) (icalendar-read-date "20241201")) or even just > ... (DTSTART ((VALUE "DATE")) ('icalendar-date . "20241201")) where in the latter, 'icalendar-date is a cl type symbol and some magic type dispatch will call the associated read function on the string at an appropriate time? Best, Richard