emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: "Przemysław Kamiński" <pk@intrepidus.pl>
To: emacs-orgmode@gnu.org
Subject: Re: official orgmode parser
Date: Tue, 15 Sep 2020 11:17:57 +0200	[thread overview]
Message-ID: <482cea5c-4214-57ac-dfeb-1e305180fee5@intrepidus.pl> (raw)
In-Reply-To: <87d02n2yyr.fsf@gmail.com>

On 9/15/20 11:03 AM, Tim Cross wrote:
> Przemysław Kamiński <pk@intrepidus.pl> writes:
>> Hello,
>> I oftentimes find myself needing to parse 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/org-tools/
>> and having tested some of these, I must say they are lacking. The
>> Haskell ones seem to be done best, but then the compile overhead of
>> Haskell and difficulty in embedding this into other languages is a drawback.
>> I think it might benefit the community when such an official parser
>> would exist (and maybe 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 important part of org mode would be outside
>> of the small world of elisp.
>> This is just an idea, what do you think? :)
> The problem with this idea is maintenance. It is also partly why
> external tools are not terribly reliable/good. Org mode is constantly
> being enhanced and improved. It is very hard for external tools to keep
> pace with org-mode development, so they soon get out of date or stop
> working correctly.
> Org mode IS an elsip application. This is the main goal. The reason it
> works so well is because elisp is largely a DSL that focuses on text
> manipulation and is therefore ideally suited for a text based organiser.
> This means if you want to implement parsing of org files in any
> other language, there is a lot of fundamental functionality which willl
> need to be implemented that is not necessary when using elisp as it is
> already built-in. Not only that, it is also 'battle hardened' and well
> tested. The other problem would be in selecting another language which
> behaves consistently across all the platforms Emacs and org-mode is
> supported on. As org-mode is a stnadard part of Emacs, it also needs to
> be implemented in something which is also available on all the platforms
> emacs is on without needing the user to install additional software.
> The other issue is that you would need another skill in order to
> maintain/extend org-mode. In addition to elisp, you will also need to
> know whatever the parser implementation language is.
> A third negative is that if the parser was in a different language to
> elisp, the interface between the rest of org mode (in elisp) and the
> parser would become an issue. At the moment, there are far fewer
> barriers as it is all elisp. However, if part of the system is in
> another language, you are now restricted to whatever defined interface
> exists. This would likely also have performance issues and overheads
> associated with translating from one format to another etc.
> So, in short, the chances of org mode using a parser written in
> something other than elisp is pretty close to 0. This leaves you with 2
> options -
> 1. Implement another external tool which can parse org-files. As
> metnioned above, this is a non-trivial task and will likely be difficult
> to maintain. Probably not the best first choice.
> 2. Provide some details about your workflow where you believe you need
> to use external tools to process the org-files. It is very likely there
> are alternative approaches to give you the result you want, but without
> the need to do external parsing of org-files. There isn't sufficient
> details in the examples you mention to provide any specific details.
> However, I have used org-mode for reporting, invoicing, time tracking,
> documentation, issue/request tracking, project planning and project
> management and never needed to parse my org files with an external tool.
> I have exported the data in different formats which have then been
> processed by other tools and I have tweaked my setup to support various
> enterprise/corporate standards or requirements (logos, corporate
> colours, report formats, etc). Sometimes these tweaks are trivial and
> others require more extensive effort. Often, others have had to do
> something the same or similar and have working examples etc.
> So my recommendation is post some messages to this list with details on
> what you need to try and do and see what others can suggest. I would
> keep each post to a single item rather than one long post with multiple
> requests. From watching this list, I've often see someone post a "How
> can I ..." question only to get the answer "Oh, that is already
> built-in, just do .....". Org is a large application with lots of
> sophisticated power that isn't always obvious from just reading the
> manual.

So, I keep clock times for work in org mode, this is very handy. 
However, my customers require that I use their service to provide the 
times. They do offer API. So basically I'm using elisp to parse org, 
make API calls, and at the same time generate CSV reports with a Python 
interop with org babel (because my elisp is just too bad to do that). If 
I had access to some org parser, I'd pick a language that would be more 
comfortable for me to get the job done. I guess it can all be done in 
elisp, however this is just a tool for me alone and I have limited time 
resources on hacking things for myself :)

Another one is generating total hours report for day/week/month to put 
into my awesomewm toolbar. I ended up using orgstat
however the author is creating his own DSL in YAML and I guess things 
were much better off if it all stayed in some Scheme :)

Anyways, my parser needs aren't that sophisticated: just parse the file, 
return headings with clock drawers. I tried the common lisp library but 
got frustrated after fiddling with it for couple of hours.


  reply	other threads:[~2020-09-15  9:44 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15  7:58 official orgmode parser Przemysław Kamiński
2020-09-15  8:44 ` Gerry Agbobada
2020-09-16 16:36   ` Matt Huszagh
2020-09-23  8:09   ` Bastien
2020-09-15  9:03 ` Tim Cross
2020-09-15  9:17   ` Przemysław Kamiński [this message]
2020-09-15  9:55     ` Russell Adams
2020-09-15 11:15       ` Przemysław Kamiński
2020-09-15 12:37         ` tomas
2020-09-15 18:09           ` Diego Zamboni
2020-09-16 12:09           ` Przemysław Kamiński
2020-09-16 12:20             ` tomas
2020-09-16 12:27             ` Ihor Radchenko
2020-09-16  0:16     ` Tim Cross
2020-09-16  7:24     ` Marcin Borkowski
2020-09-16  7:56       ` Ihor Radchenko
2020-09-16 11:36         ` Przemysław Kamiński
2020-09-16 12:02           ` Ihor Radchenko
2020-09-16 12:15             ` Przemysław Kamiński
2020-09-17  1:18               ` Ihor Radchenko
2020-09-17 15:24                 ` Przemysław Kamiński
2020-09-23  8:09 ` Bastien
2020-09-23 17:46   ` Przemysław Kamiński
2020-09-23 19:50     ` rey-coyrehourcq
2020-11-11  8:58       ` Bastien
2020-10-24 21:12   ` Daniele Nicolodi
2020-10-24 21:35     ` Tom Gillespie
2020-11-11  9:13       ` Bastien
2020-11-12 17:14         ` Tom Gillespie
2020-11-11  9:15     ` Bastien
2020-11-11 13:05       ` Daniele Nicolodi
2020-11-28 19:19       ` Gerry Agbobada
2020-10-26 11:23   ` Ken Mankoff
2020-10-26 14:21     ` Nicolas Goaziou
2020-10-26 16:17       ` Ken Mankoff
2020-10-26 16:24         ` Nicolas Goaziou
2020-10-26 16:47           ` Ken Mankoff
2020-10-26 17:59             ` Tom Gillespie
2020-10-26 20:26               ` Ken Mankoff
2020-10-26 21:00                 ` Tom Gillespie
2020-10-26 21:37                   ` Ken Mankoff
2020-10-26 22:19                     ` Tom Gillespie
2020-10-27  5:42                   ` Przemysław Kamiński
2020-11-11  8:59             ` Bastien
2020-11-11  9:00         ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=482cea5c-4214-57ac-dfeb-1e305180fee5@intrepidus.pl \
    --to=pk@intrepidus.pl \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).