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: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support) Date: Sun, 05 Jan 2025 10:52:38 +0100 Message-ID: <874j2d8u55.fsf@recursewithless.net> References: <87ed4dss2x.fsf@ohm.mail-host-address-is-not-set> <87mshq9w5c.fsf@ohm.mail-host-address-is-not-set> <86ed31j6zk.fsf@gnu.org> <87ldx9vsnb.fsf@localhost> <868qt8kj6f.fsf@gnu.org> <87ikscx5io.fsf@localhost> <867c8skhy6.fsf@gnu.org> <87frngx4fx.fsf@localhost> <864j3wkczm.fsf@gnu.org> <87cyhg0zjz.fsf@localhost> <87ttamtf7g.fsf@recursewithless.net> <87h66l2isk.fsf@localhost> <87cyh8guci.fsf@recursewithless.net> <87r05mg9ve.fsf@localhost> <87seq290b6.fsf@recursewithless.net> <87msg9qej0.fsf@localhost> <871pxlhto4.fsf@recursewithless.net> <8734i1q8p1.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10665"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jan 05 10:53:40 2025 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 1tUNKE-0002bz-3Q for ged-emacs-devel@m.gmane-mx.org; Sun, 05 Jan 2025 10:53:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUNJZ-0003Vv-PT; Sun, 05 Jan 2025 04:52:58 -0500 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 1tUNJW-0003Ve-JY for emacs-devel@gnu.org; Sun, 05 Jan 2025 04:52:54 -0500 Original-Received: from fout-b2-smtp.messagingengine.com ([202.12.124.145]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUNJU-0002d6-HH for emacs-devel@gnu.org; Sun, 05 Jan 2025 04:52:54 -0500 Original-Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfout.stl.internal (Postfix) with ESMTP id 8BD8411400DD; Sun, 5 Jan 2025 04:52:48 -0500 (EST) Original-Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Sun, 05 Jan 2025 04:52:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= recursewithless.net; h=cc:cc:content-transfer-encoding :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=fm1; t=1736070768; x=1736157168; bh=vszxjMskRn HGFWhlF5Wq3VKz2QlbIuw3+hAEB75iIDo=; b=gavHnspdy1ptFk7oD23wLt0Hbk Vco9ik7KnWWwNaDbupnF8pw44+U4IQIIzYHx6GJTqFZCz8NkNROoG0ZkfV5NdPix H5GK+PbQAz/n1+a7T8WQQTopN2a60sYUtMSaa7JyiQ29ohQ2ox1uZMdrItC+84I8 hLM9sGd/NvJxEi1059Bqh0niRA9AIm53b9iyH0vvz9xtNvYTJN0NgFP+R8DHEMkw tmE+NDzGg4bHLLH/QIpAJwv3g6+731AHVx5L5r8+1BujU3LSR4rfyWMxoHpJJygf dyxrOIBeHvzvUMVsnfxeiOCt+TKUTcDXSGno/LEWWl7TgrgekAKBFXWQuNLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :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-sender:x-me-sender:x-sasl-enc; s=fm2; t=1736070768; x= 1736157168; bh=vszxjMskRnHGFWhlF5Wq3VKz2QlbIuw3+hAEB75iIDo=; b=J j0ZyJAfgLGqxLk4Ivi9+wYcEcH4wlaWWkUZoGWToifIOKsHols6M1jI5PxM5J60a Uo1nZ+dYIeo0LcJEN65KrtiV4U4wRIMAwkEVsTFDjAUsG2FXEmp8/XJOX68pvLtk 8LDckX79+QGNYfPc9oaBSzmqj7pkCtyKXHEUu1tjxifC5fXjl5ZTBvvl3mymYVGx N9heH8bNPfLIoZejVGc0Xm5FVmOJVoh5ljVAOJYooURj/7gOSJehkqZu0vfjwU/8 3IOEBK9AoZ9TEeGlUhs4qo9oTU3OUTEvYMCPhdI6mavBYfPkNNDResO3v3WHlXqC l/RqeDCAQX8uLjYoPCSUg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudefkedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucenucfjughrpefhvfevuf gjfhffkfggtgfgsehtqhertddttdejnecuhfhrohhmpeftihgthhgrrhguucfnrgifrhgv nhgtvgcuoehrfihlsehrvggtuhhrshgvfihithhhlhgvshhsrdhnvghtqeenucggtffrrg htthgvrhhnpeefhfevjefgveekieevfeeiueehgeeigefhudevteeitedutdegfeekhefh veeiudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hrfihlsehrvggtuhhrshgvfihithhhlhgvshhsrdhnvghtpdhnsggprhgtphhtthhopedv pdhmohguvgepshhmthhpohhuthdprhgtphhtthhopeihrghnthgrrhelvdesphhoshhtvg hordhnvghtpdhrtghpthhtohepvghmrggtshdquggvvhgvlhesghhnuhdrohhrgh X-ME-Proxy: Feedback-ID: if7394488:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 5 Jan 2025 04:52:47 -0500 (EST) In-Reply-To: <8734i1q8p1.fsf@localhost> Received-SPF: pass client-ip=202.12.124.145; envelope-from=rwl@recursewithless.net; helo=fout-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_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_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:327713 Archived-At: Ihor Radchenko writes: > Richard Lawrence writes: > >> In any case, the issue with passing nil as the &rest argument is what >> causes most of the tests to fail. This remains so even once I change the >> call to use (apply #'org-element-create ...) as you suggested. This *is* >> documented in the Elisp manual, and I guess it makes sense, but I still >> find it somewhat unintuitive to reason about.=20=20 > > May you please give an example illustrating the issue? I am not sure if > I understand it fully. OK, revisiting this after a few days...I'm not 100% sure I understand it either. Here is what I see: if I define ical:make-ast-node like (defun ical:make-ast-node (type &optional props &rest children) ;; ... (apply #'org-element-create type full-props children)) which is what I was doing in the hope that I could eventually just use defalias, most of my parser tests fail with "X may not contain `nil'" errors as I showed in a previous message. If instead I change the definition to: (defun ical:make-ast-node (type props &optional children) ;; ... (apply #'org-element-create type full-props children)) which better reflects the usage pattern I need, then all the tests pass aga= in. The reason is that, with the former definition, children will be bound to `(nil)' in the call to org-element-create, while in the latter it will be bound to `nil'. The root of the problem is that (org-element-create 'foo (list ...)) (org-element-create 'foo (list ...) nil) are not equivalent; in particular (org-element-contents (org-element-create 'foo (list ...))) ; =3D> nil (org-element-contents (org-element-create 'foo (list ...) nil)) ; =3D> (nil) This is the documented behavior of passing nil for a &rest argument (see info node `(elisp)Argument list': "Note that exactly five arguments with an explicit =E2=80=98nil=E2=80=99 argument provided for =E2=80=98e=E2=80=99= will cause that =E2=80=98nil=E2=80=99 argument to be passed as a list with one element, =E2=80=98(nil)=E2=80=99, = as with any other single value for =E2=80=98e=E2=80=99"). So it's not a problem per se. But this interface to org-element-contents is not a good match for the way my iCalendar parser works: a list of child nodes is always built up *before* calling ical:make-ast-node/org-element-create. Sometimes this list is empty, and sometimes it isn't, but it is always a list, and I always have a variable bound to this list which I want to provide as an argument to the constructor. I imagine other parsers often work similarly. Thus, it would be nice to have an interface where children is not a &rest argument, so that calling it like (org-element-create* 'foo (list ...) the-child-nodes) will work even if the-child-nodes is nil, rather than having to either (a) say (if the-child-nodes (org-element-create* 'foo (list ...) the-child-nodes) (org-element-create* 'foo (list ...))) or (b) write a wrapper for org-element-create with a different argument list definition, as I have now. Is that clearer? Best, Richard