Nathaniel Nicandro <nathanielnican...@gmail.com> writes: >> 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? I completely missed the point that <ANSI> codes are not <open ... close> pairs, but switches; this is completely different from Org syntax. So, let me re-consider where <ANSI> codes are likely to be used in practice: 1. Inside shell code blocks (src-block element) 2. Inside results of evaluation, which are usually fixed-width element, but might also be example-block, export-block, drawer, table, or other element. 3. Inside shell inline code blocks (inline-src-block object) 4. Inside results of evaluation of an inline code block - usually code/verbatim markup. I think that the most reasonable approach to fontify ANSI sequences will be the following: 1. We will consider ANSI within (a) all greater elements and lesser elements that have RESULTS affiliated keyword (indicating that they are result of code block evaluation); (b) otherwise, just lesser elements, like paragraph, src block, example block, export block, etc., but _not_ tables (c) otherwise, within verbatim-like objects, like code, export-snippet, inline-src-block, table-cell, verbatim. The three groups above should be declared via variables, so that users can tweak them as necessary. 2. If ANSI sequence is encountered inside a verbatim-like object and we did not see any ANSI sequences within parent element or greater element, limit ANSI triggers to the current object. Example: #+RESULTS: Lorem upsum =<ANSI>valor=. Some more text. (only "valor" will be affected) 3. If the first ANSI sequence is encountered inside element and outside verbatim-like object, the rest of the element is affected, including all the objects. Example: #+RESULTS: <ANSI>Lorem upsum =<ANSI>valor=. Some more text. (the first ANSI affects everything, including verbatim; the second ANSI also affects everything) 4. If the first ANSI sequence is encountered inside greater element with RESULTS affiliated keyword, all the lesser elements inside will be affected. Example: #+RESULTS: :drawer: <ANSI>Lorem upsum =valor=. Some more text. Another paragraph inside drawer. :end: (everything down to :end: is affected) or #+RESULTS: - <ANSI>list - one - two - three (everything is affected down to the end of the list) Does it make sense? >>> + (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. If we really need to, we can propose an extension of ansi-color-apply-on-region upstream for Emacs itself. -- Ihor Radchenko // yantar92, Org mode contributor, 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>