Hi,
Indeed, orgparse can parse only subset of org syntax. It is primary
developed for OrgViz [1] which is an app to view your org files in
various formats including calendar, graph and table. That's why it
doesn't understand babel stuff. I thought I'd advertise it in org
ML at some point but I
Achim Gratz writes:
> Nicolas Goaziou gmail.com> writes:
>> I can write a document describing Org syntax, as seen by the parser, if
>> needed. It may serve as a first draft for an appendix in the Org manual.
>
> This would be very welcome. If you think I can be of help with any of this,
> pleas
[CC'ed to Takafumi Arakaki, author of orgparse]
Hello François,
> Do you know happen to know how conforming it is?
I can't comment on that, since I haven't really used it for anything.
> I wrote many ad hoc parsers for Org already, but what I would like
> is something really close to the parse
Yagnesh Raghava Yakkala writes:
>> There is a need I often have, and never found the time to fill so far,
>> for a dependable Python parser for Org syntax.
> Not sure how complete it is [...] https://github.com/tkf/orgparse
Thanks for the pointer. With about 150 commits already, it seems th
On Mar 01 2013, François Pinard wrote:
> Nicolas Goaziou writes:
>
>> I can write a document describing Org syntax, as seen by the parser [...]
>
> That would undoubtedly be useful.
>
> There is a need I often have, and never found the time to fill so far,
> for a dependable Python parser for O
Nicolas Goaziou writes:
> I can write a document describing Org syntax, as seen by the parser [...]
That would undoubtedly be useful.
There is a need I often have, and never found the time to fill so far,
for a dependable Python parser for Org syntax. I thought I could read
the Emacs Lisp code
Nicolas Goaziou gmail.com> writes:
> I can write a document describing Org syntax, as seen by the parser, if
> needed. It may serve as a first draft for an appendix in the Org manual.
This would be very welcome. If you think I can be of help with any of this,
please let me know.
Regards,
Achim
Bastien writes:
> But be prepared for dealing with some stubbornness on my side:
> documenting the parser does not mean every issue should be solved
> thinking in terms of the parser. Sometimes there should be a
> tradeoff between what the parser can parse and what the UI should
> offer.
Obviou
Hi Nicolas,
Nicolas Goaziou writes:
> I can write a document describing Org syntax, as seen by the parser, if
> needed. It may serve as a first draft for an appendix in the Org manual.
It will be useful in general; it will spare us miscommunication on
various aspects of the parser. So please f
Hello,
Bastien writes:
> thanks for the thorough feedback.
>
> I reverted the change I made.
Thank you.
> I need to think more about the issue.
I can write a document describing Org syntax, as seen by the parser, if
needed. It may serve as a first draft for an appendix in the Org manual.
Hi Nicolas,
thanks for the thorough feedback.
I reverted the change I made.
I need to think more about the issue.
Best,
--
Bastien
Bastien writes:
> Nicolas Goaziou writes:
>
>> Ok then another binding. I still think freeing "," key is the best thing
>> to do. More on this below.
>
> Users will still be able to use the "," so this will not really fix
> the issue.
That's the whole point: leave the ability to escape the he
Hi Nicolas,
Nicolas Goaziou writes:
> Ok then another binding. I still think freeing "," key is the best thing
> to do. More on this below.
Users will still be able to use the "," so this will not really fix
the issue.
>> I think "," is good for priorities, and that preventing speed commands
Hello,
Bastien writes:
> "#" is already taken, for comments.
Ok then another binding. I still think freeing "," key is the best thing
to do. More on this below.
> I think "," is good for priorities, and that preventing speed commands
> in the several blocks is safe and non-intrusive, that's
Hi Nicolas,
Nicolas Goaziou writes:
> What about "#" for priorities?
"#" is already taken, for comments.
I think "," is good for priorities, and that preventing speed commands
in the several blocks is safe and non-intrusive, that's what my patch
did. Let me know if you (strongly) think othe
Hello,
"Sebastien Vauban"
writes:
> Consider this Org block:
>
> #+begin_src org
> * Headline inside an Org block
>
> Text of that entry.
> #+end_src
Technically, this is not an Org block for any serious function in Org.
Headlines have precedence over block markers.
> I don't remember exactl
Hi Sébastien,
"Sebastien Vauban"
writes:
> IMHO, such a question should not be asked, and the `,' should be inserted
> literally, as we're in the context of a code block.
Fixed in master, thanks.
--
Bastien
Hello,
Consider this Org block:
#+begin_src org
* Headline inside an Org block
Text of that entry.
#+end_src
I don't remember exactly why (I think, sometimes, TAB'ing did not work
properly to prefix the dangerous lines with a `,'), I had to do it manually:
go and prefix every headline of the Or
18 matches
Mail list logo
