Hi again,

I'm separating the Org document concept from the document property drawer to 
not block the document property drawer by syntax changes.

New RFC coming in a moment. Now only for the document property drawer 


> -----Original Message-----
> From: Nicolas Goaziou <m...@nicolasgoaziou.fr>
> Sent: den 6 september 2019 22:10
> To: Gustav Wikström <gus...@whil.se>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: [RFC] Org document concept + document property drawers
> Hello,
> Gustav Wikström <gus...@whil.se> writes:
> > I'm starting out slow by making this a non-breaking change. At least
> > I'm trying to. I.e. everything that worked before should continue to
> > work.
> This still is a syntax change, which is not to be taken lightly. Since
> Org 9.3 is way overdue (I'm not blaming anyone for it, mind you),
> I suggest to wait, and discuss about it with users meanwhile.

I'll separate the patches and propose to go ahead with the document property 
drawer without the conceptual addition of Org documents in the parser.

> >> > Patch 0001 introduces the document element into org-element.el, and
> >> > some restructuring related to that.
> >>
> >> This should be explained in comments, and, if it lands at some point,
> >> Worg pages about syntax and exporter should be updated, too.
> >
> > Which comments do you mean? I've tried to be rigorous in the patch
> > notes. But you mean in the mail itself?
> In the "org-element.el" file. There are some comments there. You could
> add some info about the changes there.

Got it.

> > Noted, except in this case I think it's warranted since
> > org-back-to-heading behaves exactly the same with the exception of
> > raising an error if before the first heading. Since both functions are
> > defined next to another I'm sure a later refactor will take care of
> > both since they're structurally identical and defined two lines apart.
> Your call.

My call is to follow current pattern and make sure it's at least not adding any 
complexity for possible later refactor.

> > I've just "pattern-matched" myself into that docstring. It matches the
> > existing definitions of org-at-drawer-p, org-at-comment-p,
> > org-at-block-p. Which are defined around this.
> Then, these docstrings should be fixed too. Actually, "Non-nil if..." is
> for variables with a boolean value. For predicates, like these
> functions, it should be : "Return t if ...".
> See (info "(elisp) Documentation Tips") for more information about the
> subject.

Fixed existing docstrings in separate patch already pushed to master.

> > Hmm... I see your point. Have to think a bit here - because I have the
> > feeling that defining the predicate using org-element-at-point will
> > incur quite a performance hit.
> Of course it will be slower. But "almost correct" predicates are also
> bad, in other ways. Besides, it may be premature optimization at this
> point.

I've not made any changes to this just yet. It may be worth a revisit later 
though, because I do see your point. The issue is bigger than the one added 
predicate here though, and should most likely be looked at more holistically. I 
propose to take that in a separate change as refactoring isn't made more 
complicated by the patch I've suggested (although the amount of work will 
increase slightly).


Reply via email to