From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id Ug2UASx/YF/lagAA0tVLHw (envelope-from ) for ; Tue, 15 Sep 2020 08:45:32 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id qJgPNyt/YF9zewAAB5/wlQ (envelope-from ) for ; Tue, 15 Sep 2020 08:45:31 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id A17B99404C3 for ; Tue, 15 Sep 2020 08:45:30 +0000 (UTC) Received: from localhost ([::1]:32788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kI6af-0004QM-Cl for larch@yhetil.org; Tue, 15 Sep 2020 04:45:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54910) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI6ZG-00043h-Ea for emacs-orgmode@gnu.org; Tue, 15 Sep 2020 04:44:02 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:44795) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kI6ZE-0005y9-6R for emacs-orgmode@gnu.org; Tue, 15 Sep 2020 04:44:02 -0400 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id BB9A350C for ; Tue, 15 Sep 2020 04:43:54 -0400 (EDT) Received: from imap9 ([10.202.2.59]) by compute1.internal (MEProxy); Tue, 15 Sep 2020 04:43:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gagbo.net; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=uXvmYSvSJX5dNueAryPcwtksTTE6M/1 OZykQnz3vWqI=; b=S8JiV6uU9Kg0SCV1rJNI0SHRSqwU8GNvrzhTp4zryagx1s3 a7/G9LbyqG6qriQj4ilEmXqdGl0O/X3/OW22PvdPGqZNJiEYdDxhIO4bsZ7imbvE 52VcXcryWYRwaJKvYU5kZBhEufNkn/EOkC4VaZhdvWg7289Nv5afHtrWpRQKuR3+ LoR7Rv7xMviBL8Wo303QlITjaB4S6IhrlFnKonUloij2+5zPegivG4HSOU2STC/7 DYUbcWJOcrxzg3y3SPj3Yu27ba3Nmdd192Au6xXHXfWE9ufzA71lpDa0SyvO0Zmx 19/433DvG6DTxDp67st1+Hs/Qf7zZXgaVGvttwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=uXvmYS vSJX5dNueAryPcwtksTTE6M/1OZykQnz3vWqI=; b=M/0Pb0SjCck1VOpcliyhf/ X0YSe2c25tChVIFcTl76FO+27Ft/vxdHJTv+/02c/7FWe1FWvwU1nb9pCZx2ozcG DgQjnmsNjeW4nwPkUso2eKB++QmoJ50lWwN8Lj+29L3qDn6zxwCzn6xPUg1aQ3FG Y+XkkK65tiSaHusjmeFzlPa3kV9wtDTsVIGLE/6QF5LbfjffJN0mP2kpILGvJw6t DOFxTrpDu8mHRGWVuK1jrzhWh5yQcxjzAABRJAeiFNPzIdwhEGChc7AvqIJUxdrO XflMRmLIASytaHOBMqHShUEnKS3TyZ+fI3yb6zW3oQDTMhLUVjsWZORcWaGpwyWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeikedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfifgvrhhrhicutehgsghosggruggrfdcuoegvmhgrtghs qdhorhhgmhhouggvsehgrghgsghordhnvghtqeenucggtffrrghtthgvrhhnpeeifffftd euteejteefgfdtheelteduvdeuteevkefghfeuhfehgeejjefggeekjeenucffohhmrghi nhepohhrghhmohguvgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegvmhgrtghsqdhorhhgmhhouggvsehgrghgsghordhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 128211C0467; Tue, 15 Sep 2020 04:43:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3 Mime-Version: 1.0 Message-Id: <5b17ccc4-a3fd-41b2-bc2a-281b0c666e33@www.fastmail.com> In-Reply-To: <68dc1ea1-52e8-7d9e-fb2d-bcf08c111eca@intrepidus.pl> References: <68dc1ea1-52e8-7d9e-fb2d-bcf08c111eca@intrepidus.pl> Date: Tue, 15 Sep 2020 10:44:01 +0200 From: "Gerry Agbobada" To: emacs-orgmode@gnu.org Subject: Re: official orgmode parser Content-Type: multipart/alternative; boundary=60a8331c9ea94d9eb25a5e3ec25ba419 Received-SPF: pass client-ip=64.147.123.24; envelope-from=emacs-orgmode@gagbo.net; helo=wout1-smtp.messagingengine.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/15 04:43:55 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gagbo.net header.s=fm2 header.b=S8JiV6uU; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=M/0Pb0Sj; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: 0.80 X-TUID: /l4AN0qQmAol --60a8331c9ea94d9eb25a5e3ec25ba419 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I'm currently toying with the idea of trying a tree-sitter parser for Or= g. The very static nature of a shared object parser (knowing TODO keywor= ds are pretty dynamic for example) is a challenge I'm not sure to overco= me ; to be honest even without that I can't say I'll manage to do it. Having a tree-sitter parser would be really great in my opinion, at leas= t it's a clearer way to "freeze" the syntax with some tests describing t= he syntax tree with S-expressions. And tree-sitter seems to be the popul= ar sought after solution to slowness in parsing (and incremental parsing= of org files would help with big files in my opinion) On Tue, Sep 15, 2020, at 09:58, Przemys=C5=82aw Kami=C5=84ski wrote: > Hello, >=20 > I oftentimes find myself needing to parse org files with some external= =20 > tools (to generate reports for customers or sum up clock times for giv= en=20 > month, etc). Looking through the list >=20 > https://orgmode.org/worg/org-tools/ >=20 > and having tested some of these, I must say they are lacking. The=20 > Haskell ones seem to be done best, but then the compile overhead of=20= > Haskell and difficulty in embedding this into other languages is a dra= wback. >=20 > I think it might benefit the community when such an official parser=20= > would exist (and maybe could be hooked into org mode directly). >=20 > I was thinking picking some scheme like chicken or guile, which could = be=20 > later easily embedded into C or whatever. Then use that parser in org=20= > mode itself. This way some important part of org mode would be outside= =20 > of the small world of elisp. >=20 > This is just an idea, what do you think? :) >=20 > Best, > Przemek >=20 >=20 Gerry Agbobada --60a8331c9ea94d9eb25a5e3ec25ba419 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

I'm = currently toying with the idea of trying a tree-sitter parser for Org. T= he very static nature of a shared object parser (knowing TODO keywords a= re pretty dynamic for example) is a challenge I'm not sure to overcome ;= to be honest even without that I can't say I'll manage to do it.
Having a tree-sitter parser would be really great in my opinion, at lea= st it's a clearer way to "freeze" the syntax with some tests describing = the syntax tree with S-expressions. And tree-sitter seems to be the popu= lar sought after solution to slowness in parsing (and incremental parsin= g of org files would help with big files in my opinion)
On Tue, Sep 15, 2020, at 09:58, Przemys=C5=82aw Kami=C5=84s= ki wrote:
H= ello,

I oftentimes find myself needing to p= arse org files with some external 
tools (to generate= reports for customers or sum up clock times for given 
month, etc). Looking through the list

https://orgmode.org/worg/o= rg-tools/

and having tested some of the= se, I must say they are lacking. The 
Haskell ones se= em to be done best, but then the compile overhead of 
Haskell and difficulty in embedding this into other languages is a draw= back.

I think it might benefit the communit= y when such an official parser 
would exist (and mayb= e could be hooked into org mode directly).

= I was thinking picking some scheme like chicken or guile, which could be=  
later easily embedded into C or whatever. Then use = that parser in org 
mode itself. This way some import= ant part of org mode would be outside 
of the small w= orld of elisp.

This is just an idea, what d= o you think? :)

Best,
Przemek=



Gerry Agbobada

<= /body> --60a8331c9ea94d9eb25a5e3ec25ba419--