From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support) Date: Wed, 01 Jan 2025 09:29:41 +0000 Message-ID: <87r05mg9ve.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Lawrence Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jan 01 10:29:14 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 1tSv2Q-0008Um-9F for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Jan 2025 10:29:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSv1a-0006RI-AS; Wed, 01 Jan 2025 04:28:22 -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 1tSv1Y-0006R1-9G for emacs-devel@gnu.org; Wed, 01 Jan 2025 04:28:20 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tSv1U-0000dS-1t for emacs-devel@gnu.org; Wed, 01 Jan 2025 04:28:20 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 7AA2A240103 for ; Wed, 1 Jan 2025 10:28:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735723691; bh=pnPeJAWNPfhc4w21Qd5ZjxiA1azLCmAtl+q0FhvgGVs=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Xwv0PQIi6PbAG2BI5lwZpvJF9DlIEOPScr2sJ1p8J0T2HTihC+otsXXjahiQG0ztz F5pU+lAuRI/W4ugdcuDUCXQOaH1p4XEhBwgIgJ0dbtWbTlMXzxMlR56omkJNN1OaKF 9CUwJfT6g9C0zKHBZt6eS2xbUQN+7lbWelryciVIjub2G/77USaipnG8VtSeg01dAZ DGrwMMXhaQdjnuzkbSYgvMTdBt3oA3BVcwLWbcRgmTBu+k1YsFkPzAcWJZVK/57A8o IFpVurTtrW0XSZ4MKATAQc+LUiQ2TAah3hmUJ+Gv70ncKUVNVU3njztfGFYpdWjIax xC3KR2OEYGNHA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YNPdl07Fcz6tyH; Wed, 1 Jan 2025 10:28:10 +0100 (CET) In-Reply-To: <87cyh8guci.fsf@recursewithless.net> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=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:327541 Archived-At: Richard Lawrence writes: > 1) Is there any way to use my own list of standard-properties? In > particular, besides :begin, :end, :contents-begin, :contents-end, I'd > like to have :value-begin and :value-end as standard properties, and > always include (:value) in :secondary. If there's no way to do that > yet, I think it would be useful to add for use outside of org. Currently, there is no such way. But it is one of the obvious problems that need to be solved to make the library truly generic. I am not 100% sure how though. The idea behind standard properties is inlining the calls to `org-element-property' for faster access. Dynamic standard-properties will defeat the purpose of this whole arrangement. The only thing coming to my mind is asking the libraries to use (let ((org-element--standard-properties )) (defun library-x (...) ...)) Or maybe the library can somehow flag to org-element-ast during compile time about the properties to be optimized. > 2) I'm finding org-element-create rather unintuitive to work with, I > think because of its &rest argument for children and the handling of > "anonymous" nodes. > ... > As it is, I can't figure out how to call org-element-create and > org-element-contents in the right way to set the contents of a node > to a list of other nodes, and return that list from > org-element-contents. Should be just (org-element-create type props contents) and then (org-element-contents new-node) > I always seem to end up with an extra level of nesting. > e.g. Instead of (child1 child2 child3 ...) > org-element-contents returns ((child1 child2 child3 ...)). > Likewise, if there are no children, instead of nil it returns (nil). > I can't figure out why this happens; as far as I can tell, I'm > calling both org-element-create and org-element-contents in the right > way. May you give some examples when things misbehave? -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at