Ihor Radchenko <yanta...@posteo.net> writes:
> 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? > Sounds good to me. >>>> + (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. -- Nathaniel