JV <[email protected]> writes: >> I looked at org-item-re again, and my understanding is that group >> *numbering* is always the same. It is just that some groups may be >> nil. But that's what the existing code must handle as of now. >> >> I further looked into the callers, and I note that `org-at-item-p' >> has >> ;; Set match data. >> (looking-at (org-item-re)) >> >> which is very explicit. > > Yes, but only match group 0 is ever referenced. I did check this.
Well. org-context uses group 2. And who knows about third-party code. >> This will not be 4 vs 7 groups. This will be 0 or 1 groups. >> I tried your patch and did (insert (org-item-re)). I got >> \(?:[ ]*\(?:[+-]\|\(?:[0-9]+\)[).]\)\|[ ]+\*\)\(?:[ ]\|$\) >> No capturing groups present. > > It is 0 vs 1 capturing groups, but 4 vs 7 groups. The distinction here > is for performance, and since there is no measurable performance > difference between capturing and non-capturing groups, 4 and 7 should be > the relevant counts. At least this is what my performance analysis > suggested. I understand. But that's why I suggested optional parameter. We can disable groups where we do not need them and where the performance is a bottleneck. >> I think we should use my earlier idea and keep the group numbering >> intact without optional argument. > > This may be simpler than I thought. It seems checkbox fontification > already uses org-list-full-item-re. We can just add another subexp > highlighter to this. A faster regexp would be nice, but it only makes > sense if it could completely replace the slower one for font locking. +1 >>> * lisp/org-element.el (org-element-block-elements): Add new constant. >> >> I do not like having a whole new constant. We will need to keep it >> updated if new block types are added. I'd rather just match against >> *-block type pattern. At least, we should compute the value dynamically. > > I don't love constant proliferation either, but I do think org-element > needs some canonical way to answer "what elements are blocks?" or at > least "is this element a block?" We can certainly compute the value > dynamically as you suggest, as long as it is precomputed. At runtime, we > want type comparisons to be as cheap as possible. I am ok with load/compile-time constant. >> The existing version of org-in-block-p will "Return first block name >> matched, or nil". You are changing the return value. Why? > > There are two functions that I consolidated together: org-in-block-p and > org-in-src-block-p. The latter was more capable, so I retained most of > it including its return value. The earlier version of org-in-block-p is > summarized as "Non-nil when point belongs to a block whose name belongs > to NAMES"; the function is named using the convention for boolean > predicate functions; and there are no non-boolean uses within the org > code base (it's only used twice). If you agree that this is ok, perhaps > the return type merits mentioning in ORG-NEWS? I'd rather keep the previous return value to avoid risks of breakage. The general rule is that we do not make breaking changes unless we have a very good justification. I do not see this particular breaking change as necessary. It is merely convenient. >>> +(defconst org-list--forbidden-block-types >>> + '(example-block export-block src-block verse-block) >>> + "Types of blocks where lists are not allowed.") >> >> This is awkward as we will need to maintain this constant. >> You can instead check org-element-restriction. >> For example, you can bind this variable to a dynamically computed list >> that examines org-element-restriction. > > org-element-restriction returns allowed objects but not allowed > elements, correct? If so, we need something else. > Could we simply use org-element-greater-elements? Specifically, I am > thinking that org-list-forbidden-blocks should be the > org-element-block-elements that are not in org-element-greater-elements. > Does this sound correct? Sounds good. > Currently, there is one exception to this: comment-block. This type is > not in the existing org-list-forbidden-blocks list, but it is also not > in org-element-greater-elements. What is the proper treatment of org > syntax within comment blocks? Should it be fontified or not? Comment blocks cannot contain any Org syntax. They are treated verbatim. >> So, what happens if we have, say, an example block inside a list? >> How will it look like during fontification? > > In this case, the contents inside the example block will not be > fontified as a list. The #+begin, #+end, and affiliated lines will be. Whether indentation is a part of the example block or not is controlled by switches. If it is not, then the indentation is structurally meaningful. -- 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>
