Ihor Radchenko <yanta...@posteo.net> writes:
> Nathaniel Nicandro <nathanielnican...@gmail.com> writes:
>
>> The attached patch now uses `org-element-at-point' and
>> `org-element-context' to query for the bounds of elements.
>
> Thanks!
>
>> Note, I've also attached an updated example file which shows that the
>> escape sequences in inline source blocks are now handled similarly to
>> regular source blocks, i.e. they are not fontified.
>
> I do not think that a single exception - source blocks is good enough.
> When having something like
> ANSI opening term is =<ANSI>=, and closing term is =<ANSI>=
> it will be not expected to get things fontified.
>
> A better approach will be:
> 1. Do not allow ANSI sequences to intersect markup boundaries of the
> same AST depth:
> *bold <ANSI>* plain text <ANSI> should not trigger fontification
> *bold <ANSI> /italic/ <ANSI>* should trigger
> plain text <ANSI> *bold* plain text <ANSI> also should
Just to make sure I'm getting you right. You're saying that
fontification should trigger if the sequences live in the same
org-element-context?
What about cases like:
*<ANSI>bold* plain text <ANSI>
plain <ANSI>text *bold <ANSI>* paragraph end
In the first case, should only "bold" be fontified? Since the sequence
lives in the bold context.
In the second, should only "text"? Since the sequence lives at a higher
depth (the paragraph context, compared to the bold context). Or should
it be that the fontification should extend to the end of the paragraph
because the sequence lives at a higher depth?
> 2. Disallow fontification is certain contexts - 'inline-src-block
What I will do then is not consider sequences in inline-src-block, code,
or verbatim contexts. Are there any other elements or objects that I
should not consider (other than the greater elements as you mention
below)?
For verbatim (and code) contexts, if there are regions like
<ANSIx> plain =<ANSIy>= text <ANSIz>
ANSIy will not get considered and the region between ANSIx and ANSIz
will get highlighted using ANSIx's settings. So the verbatim object
gets highlighted as well.
For inline source blocks, I'll do what I did in the last patch and
decompose a paragraph into regions that exclude inline source blocks and
only consider those regions when processing the sequences. That way the
highlighting doesn't spill over into the inline source blocks (and not
interfere with the syntax highlighting of them).
>
> Further, your current code will do something weird when encountering
> greater element:
>
> :DRAWER:
> Paragraph <ANSI>
>
> Another paragraph <ANSI>
> :END:
>
> You should not consider greater elements when fontifying.
>
Thanks. In the case of greater elements, then, I will only consider
their contents.
For plain-lists and tables I will:
1. (for plain-lists) only consider the contents of the list items
2. (for tables) only consider the table-cells of each table-row
>> + (cl-letf (((symbol-function #'delete-region)
>> + (lambda (beg end)
>> + (add-text-properties beg end '(invisible t))))
>
> This is fragile and relies on internal implementation details of
> ansi-color.el. Is there another way?
Since the context in which the sequences live in need to be considered,
it doesn't look like ansi-color-apply-on-region can be used any more
since it isn't aware of Org objects.
I've come up with a function that calculates the highlightable regions
(considering contexts) and fontifies them, but it requires the use of
private functions from ansi-color. Specifically
ansi-color--face-vec-face, ansi-color--update-face-vec, and
ansi-color--code-as-hex (used internally by ansi-color--face-vec-face).
Does it make sense to copy over these functions into Org for the
purposes of handling ANSI escapes? There would be some backward
compatibility issues, e.g. ansi-color only started using faces as colors
in Emacs 28.
--
Nathaniel
