* bug#74994: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support)
[not found] ` <87ttamtf7g.fsf@recursewithless.net>
@ 2024-12-29 20:53 ` Richard Lawrence
2024-12-30 17:16 ` Ihor Radchenko
[not found] ` <87r05qtdm3.fsf@recursewithless.net>
2 siblings, 0 replies; 4+ messages in thread
From: Richard Lawrence @ 2024-12-29 20:53 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: 74994, emacs-devel
Richard Lawrence <rwl@recursewithless.net> writes:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> In bug#74994, Richard made a decision not to use org-element-ast and
>> instead implement a custom parser generator.
>>
>> Richard, is there any specific reason why you had to make things from
>> scratch? May org-element-ast be changed to fit your needs?
>>
>> If org-element-ast is not going to be useful outside Org mode, I see no
>> good reason to invest time into upstreaming it, after all.
>
> No, it was more that, as things stood, I wanted to wait and see what
> would happen with upstreaming org-element-ast. My idea was to make it
> easy to switch once that happened, but not to wait to make progress in
> the meantime, that's all.
Ah, looking over this again, there was one thing that I felt didn't fit
very well with org-element-ast: in iCalendar, "properties" can have both
a "value" and a list of "parameters". These are different types of
objects and it's most natural and useful not to lump them together, but
in the Org element AST they would probably both just be "contents" of a
property node (i.e., child nodes). Thus, in my draft icalendar-ast.el,
instead of using
(TYPE PROPERTIES CONTENTS)
as the basic representation for a node, I used
(TYPE META VALUE CHILDREN).
The org-element-ast representation is obviously capable of making the
distinction between values and parameters in some other way; but it's
pretty much the only example I can think of where I felt the
org-element-ast representation might not be the best for the needs of
iCalendar.
Best,
Richard
^ permalink raw reply [flat|nested] 4+ messages in thread* bug#74994: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support)
[not found] ` <87ttamtf7g.fsf@recursewithless.net>
2024-12-29 20:53 ` Richard Lawrence
@ 2024-12-30 17:16 ` Ihor Radchenko
[not found] ` <87r05qtdm3.fsf@recursewithless.net>
2 siblings, 0 replies; 4+ messages in thread
From: Ihor Radchenko @ 2024-12-30 17:16 UTC (permalink / raw)
To: Richard Lawrence; +Cc: 74994, emacs-devel
Richard Lawrence <rwl@recursewithless.net> writes:
>> Richard, is there any specific reason why you had to make things from
>> scratch? May org-element-ast be changed to fit your needs?
> ...
> No, it was more that, as things stood, I wanted to wait and see what
> would happen with upstreaming org-element-ast. My idea was to make it
> easy to switch once that happened, but not to wait to make progress in
> the meantime, that's all.
org-element-ast is already a part of Emacs. The process of upstreaming
in this particular case is simply a question of (1) making the library
more useful outside Org mode; (2) renaming it.
Renaming is trivial.
The main question is making things usable outside Org mode.
And that's where your work is the most valuable.
So, it was me who is waiting for your input before upstreaming :)
> One thing about your question confuses me, namely:
>
>> ...instead implement a custom parser generator.
>
> As I understand org-element-ast, it basically just defines the parse
> tree representation and various accessors for working with it, not the
> parser itself. Was your suggestion that I could also use the Org parser,
> not just the parse tree representation? If so, then I misunderstood, and
> presumably more code is involved than is found in org-element-ast.el,
> right?
No, I did not mean that you should use org-element to generate parser.
I mostly referred to the way you implement the parser where part of the
parser configuration is stored in the AST. But I was reading your patch
very quickly and could have misunderstood something.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <87r05qtdm3.fsf@recursewithless.net>]
* bug#74994: Upstreaming org-element-ast (was: Improving Emacs' iCalendar support)
[not found] ` <87r05qtdm3.fsf@recursewithless.net>
@ 2024-12-30 17:18 ` Ihor Radchenko
0 siblings, 0 replies; 4+ messages in thread
From: Ihor Radchenko @ 2024-12-30 17:18 UTC (permalink / raw)
To: Richard Lawrence; +Cc: 74994, emacs-devel
Richard Lawrence <rwl@recursewithless.net> writes:
> Ah, looking over this again, there was one thing that I felt didn't fit
> very well with org-element-ast: in iCalendar, "properties" can have both
> a "value" and a list of "parameters". These are different types of
> objects and it's most natural and useful not to lump them together, but
> in the Org element AST they would probably both just be "contents" of a
> property node (i.e., child nodes). Thus, in my draft icalendar-ast.el,
> instead of using
>
> (TYPE PROPERTIES CONTENTS)
>
> as the basic representation for a node, I used
>
> (TYPE META VALUE CHILDREN).
>
> The org-element-ast representation is obviously capable of making the
> distinction between values and parameters in some other way; but it's
> pretty much the only example I can think of where I felt the
> org-element-ast representation might not be the best for the needs of
> iCalendar.
Have you looked into secondary nodes?
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 4+ messages in thread