Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> Nathaniel Nicandro  writes:
>>
>>> Feedback appreciated!
>>
>> Thanks for the update!
>> ...
>>> I've finally implemented a solution to what I've discussed previously,
>> ...
>
> It has been a while since the last update in this thread.
> Nathaniel, may I know if you are still working on this?

Hello Ihor,

Yes I'm still working on this.  Attached is an updated patch with some
tests this time.  It's still a work in progress.  Below are responses to
your previous comments about my last update and some comments about this
current patch.

> This is very fragile.
> I believe that hooking into `org-fold-check-before-invisible-edit'
> would lead to simpler implementation.

Thank you for the feedback.  I indeed was able to come up with a
more simpler solution by hooking into that function.

To integrate with `org-fold-check-before-invisible-edit' I had to
introduce two variables, `org-fold-visibility-detail' which is set to
the argument of `org-fold-show-set-visibility' when that function is
called and `org-ansi-fontify-begin' to determine the start of the
fontification region to see if it's close to the beginning of an
invisible sequence that should be turned visible.

Let me know if this is an OK approach.

I ran into an issue when trying to hook into
`org-fold-check-before-invisible-edit' in that when it revealed a
sequence at the end of a line, there would be an extra fontification
cycle that would occur after the reveal which would cause the sequence
to be re-hidden again.  To counteract this I had to use
`buffer-chars-modified-tick' in the way I do.  I couldn't figure out
why redisplay was causing that extra fontification cycle when there
were no modifications to the buffer.

> 1. Open the file and move to the end of the headline "Greater elements"
> 2.  
> 3. Observe fontification extending past the title.

This is fixed.  I think it was due to specifying the contents-end
position as the end of the region to highlight instead of the
line-end-position for headlines.

> I also edited it around in various places and I managed to trigger
> parser errors when the parser lost track of the modifications. This
> was presumably because your patch edited the buffer.

I no longer make edits to the buffer.  The ANSI sequences are no
longer accompanied by the zero width spaces from the idea that I had
before.

With this patch, editing around sequences should be more stable and
non-surprising.  Basically if a sequence is invisible around point and
you edit it, the sequence remains visible.  It is only after the first
edit outside of a sequence that should make the sequence invisible.
Whenever a sequence is being edited, it should always be visible and
not turn invisible while in the middle of editing it, e.g. due to an
invalid sequence turning valid.

Some comments about the patch, as it currently stands, follow.

- I've introduced two text properties `org-ansi' and
  `org-ansi-context'.

  The first is placed on the regions that actually contain ANSI
  sequences and holds information about the sequence that is useful to
  keep around to detect when a sequence has been modified or deleted
  between fontification cycles, as well as information about whether
  or not a sequence should be revealed due to modifications or because
  of visibility changes.

  The second property holds the ANSI context, as defined by
  `ansi-color-context-region', for regions that actually have been
  highlighted or processed by `org-ansi-process-region'.  Storing the
  ANSI context is done so that on fontifying some new region, the
  context that should be used can be determined simply by examining
  the property on an appropriate region before the start of the
  fontification.  The property is also used to determine the extent of
  a context or sequence, how far forward into the buffer its effects
  last.  The extent of a context is useful for extending the region
  being fontified to include the extent of a sequence which has been
  modified or deleted between fontification cycles.

  Currently I only extend the fontification region to include the
  extent when there has been a deletion or modification of a sequence
  in the region up for fontification (`org-ansi-extend-region').  I've
  not found a way to extend the fontification to a region including
  the full extent of a newly inserted sequence, in such cases the code
  as it stands now will fontify past the limit of fontification to the
  end of the element.

- The `org-ansi-process-*' functions boil down to calls to
  `org-ansi-process-region' which does the actual highlighting and
  bookkeeping of text properties on the regions.  Each of the process
  functions are just aware of the varying types of element structure
  in an Org document.  They are supposed to process an element's
  region from point to some limit or to the end of the element,
  applying properties to the highlightable regions.  If it's to the
  end of the 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>> Feedback appreciated!
>
> Thanks for the update!
> ...
>> I've finally implemented a solution to what I've discussed previously,
> ...

It has been a while since the last update in this thread.
Nathaniel, may I know if you are still working on this?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Feedback appreciated!

Thanks for the update!

> I've finally implemented a solution to what I've discussed previously,
> inserting zero width spaces as boundary characters after an ANSI
> sequence to act as a separator from the text after the sequence.  This
> would handle the scenario where deleting into the end byte of a
> sequence causes ansi-color to recognize the partially deleted sequence
> plus the character directly after the end byte to be a new sequence.
> This looked like the invisible region containing a sequence eating up
> other characters not intended to be part of the region.
> ...
> So the implementation of that rule of maintaining a zero width space
> after valid sequences and the rules around deleting into the space or
> insertion in front of a space are the main changes in this patch
> compared to previous versions.

This is very fragile.
I believe that hooking into `org-fold-check-before-invisible-edit' would
lead to simpler implementation.

I also do not like the idea that fontification code modifies the buffer.

I tried your latest patch with test-ansi.org file you shared earlier:

1. Open the file and move to the end of the headline "Greater elements"
2.  
3. Observe fontification extending past the title.

I also edited it around in various places and I managed to trigger
parser errors when the parser lost track of the modifications. This was
presumably because your patch edited the buffer.

I also observed strange glitches and hangs when I tried to surround an
ANSI-colored region like =[42mtask 1[0m= and then edited near the
boundaries.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:

Hello,

I've finally implemented a solution to what I've discussed previously,
inserting zero width spaces as boundary characters after an ANSI
sequence to act as a separator from the text after the sequence.  This
would handle the scenario where deleting into the end byte of a
sequence causes ansi-color to recognize the partially deleted sequence
plus the character directly after the end byte to be a new sequence.
This looked like the invisible region containing a sequence eating up
other characters not intended to be part of the region.

So for example, suppose you had a control sequence, ^[[42m, where m is
the end byte that says the sequence is a color sequence.  Let point be
signified by *.  If we have

^[[42m*text

then deletion into the end byte would result in 

^[[42*text

t is still a valid end byte so the fontification process will
recognized the whole thing as a valid sequence still and the t would
then become part of the invisible region containing the sequence.

To avoid this from happening I have introduced the rule that any valid
sequence shall have a zero width space immediately after it and this
space remains in the buffer even on deleting into it with, for
example, backward-delete-char.  Let the zero width space be signified
by |.  If we have 

^[[42m|*text

then deletion into the space would now result in

^[[42*|text

i.e., the effect is that the deletion went past the space, leaving it
alone, and deleted the end byte of the control sequence.  Since the
control sequence is no longer valid, due to the space being at the
position of the end byte, it becomes visible.

If you then insert a valid end byte, e.g. m, then the effect is

^[[42m|*text

i.e., point moved past the space character.

So the implementation of that rule of maintaining a zero width space
after valid sequences and the rules around deleting into the space or
insertion in front of a space are the main changes in this patch
compared to previous versions.

>
> I tried to test your newest patch with the example file you provided and
> I notice two things that would be nice:
>
> 1. It is a bit confusing to understand why one or other text is colored
>without seeing the escape characters. Some customization like
>`org-link-descriptive' and a command like `org-toggle-link-display'
>would be nice. I can see some users prefer seeing the escape codes.

I've gone ahead and implemented the toggling of the visibility of the
escapes sequences.  The variable is `org-ansi-hide-sequences` and the
function is `org-toggle-ansi-display`.

I just used buffer-invisibility-spec for this.

>
> 2. Using overlays for fontification is problematic. In your example
>file, table alignment becomes broken when escape sequences are hidden
>inside overlays:
>
>| [31mcell 1 | cell 2 |
>| cell 3   | cell 4 |
>
>looks like
>
>|   cell 1 | cell 2 |
>| cell 3   | cell 4 |
>
>Using text properties would make table alignment work without
>adjustments in the org-table.el code.
>

I've gone ahead and used text properties instead of overlays.

>> One thing I would like to start doing is writing some tests for this
>> feature.  It would be great if someone could point me to some tests
>> that I can peruse so that I can get an idea of how I can go about
>> writing some of my own.  Also, are there any procedures or things I
>> should be aware of when trying to write my own tests?
>
> Check out testing/README file in the Org repository.
>
> Unfortunately, we do not yet have any existing tests for font-locking in
> Org tests. You may still refer to the files in testing/lisp/ to see some
> example tests.
>
> Also, Emacs has built-in library to help writing font-lock tests -
> faceup.el. You may consider using it. Its top comment also contains a
> number of references to various tools that could be useful to diagnose
> font-locking code.

I have not looked into testing this feature yet.

Feedback appreciated!

>From ea2345ab218d3bc9c07452b2171afc1361b74b9d Mon Sep 17 00:00:00 2001
From: Nathaniel Nicandro 
Date: Tue, 9 May 2023 19:58:11 -0500
Subject: [PATCH] Highlight ANSI escape sequences

* etc/ORG-NEWS: Describe the new feature.
* lisp/org.el (org-fontify-ansi-sequences): New customization variable
and function which does the work of fontifying the sequences.
(org-ansi-hide-sequences)
(org-ansi-highlightable-elements)
(org-ansi-highlightable-objects): New customization variables.
(org-ansi--before-command, org-ansi--after-command)
(org-ansi--before-control-seq-deletion)
(org-ansi--after-control-seq-deletion)
(org-ansi-zero-width-space, org-ansi-is-zero-width-space)
(org-ansi-new-context, org-ansi-process-region)
(org-ansi-process-block, org-ansi-process-paragraph)
(org-ansi-process-fixed-width)
(org-fontify-ansi-sequences-1)
(org-toggle-ansi-display): New functions.
(org-ansi--control-seq-positions)
(org-ansi--change-pending, 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Hello, attached is another updated patch with the following changes:

Thanks!

> - To tackle the issue discussed previously about highlights spanning
>   multiple lines (or elements) being removed when a line is modified I
>   went ahead and used the font-lock-multiline property (see
>   font-lock-extend-region-multiline and
>   font-lock-extend-region-functions) across those regions so that on
>   any edit of one of the lines, the region including all of the ANSI
>   sequences that affect that line will be re-fontified.  This was the
>   easier solution, but the downside is that it can cause large regions
>   to be re-fontified when really all we want to do is apply the
>   highlighting face to a small line change, for example.

This is fine.

> - To tackle the issue of editing around the invisible ANSI sequences I
>   left it up to the font-lock process to catch the invisible edits.
>   Whenever an edit deletes a character of the sequence that renders
>   the sequence invalid, the font-lock process will reveal the partial
>   sequence.  But I had to limit what was considered a valid ANSI
>   sequence to get it working in a somewhat acceptable way.
>
>   The problem that I found was that if the buffer contains something
>   like
>   
>   ^[[43mfoo
>   
>   (where ^[ is the ESC character and can be inserted with "C-q ESC" and
>   the whole sequence ^[[43m is the ANSI sequence) what was happening was
>   that deleting into the hidden sequence would leave the region in the
>   state
>   
>   ^[[43foo
>   
>   and because the end byte of the ANSI sequence can be any character
>   in the ASCII range [@A-Z[\]^_`a–z{|}~], ^[[43f would still be a
>   valid ANSI sequence and would be hidden during the fontification
>   process after the edit.  Since `ansi-color-apply-on-region' only
>   really handles the sequences that end in an m byte, just rendering
>   all other ones invisible, I limited the ANSI sequences handled by
>   this patch to be only those sequences that end in m.  This way,
>   after deleting into the sequence like in the above example the
>   fontification process would not recognize the region as containing
>   any sequence.  The downside to this solution is that sequences that
>   end in any other end byte won't get conveniently hidden and the
>   problem still persists if you have text that starts with an m and
>   you delete into a hidden sequence.

Makes sense. We may also make hiding ^[[43foo as customization disabled
by default.
   
>   An alternative solution that doesn't constrain the end byte could be
>   to add in some extra invisible character like a zero width space and
>   then use something like the `modification-hooks' text property on
>   the character to signify that a deletion at the boundary between the
>   sequence and the text should really delete part of the sequence
>   instead of the zero width space.  I haven't really worked out the
>   details of this, for example how would it be detected which
>   direction a deletion is coming from, the front or behind, but I'm
>   throwing it out there to see if there are any other solutions other
>   people might be aware of for a similar problem.

If you want to go in this direction, check out
`org-fold-check-before-invisible-edit'. We can unfontify the escape
sequence from there and font-lock will re-apply only during the next
editing cycle, making the sequence visible temporarily.
Not mandatory though.

>> P.S. I am not yet commenting on the details in the code.
>
> Please let me know what you think of this patch and where I should be
> focusing my efforts moving forward to get this submitted to Org.

I tried to test your newest patch with the example file you provided and
I notice two things that would be nice:

1. It is a bit confusing to understand why one or other text is colored
   without seeing the escape characters. Some customization like
   `org-link-descriptive' and a command like `org-toggle-link-display'
   would be nice. I can see some users prefer seeing the escape codes.

2. Using overlays for fontification is problematic. In your example
   file, table alignment becomes broken when escape sequences are hidden
   inside overlays:

   | [31mcell 1 | cell 2 |
   | cell 3   | cell 4 |

   looks like

   |   cell 1 | cell 2 |
   | cell 3   | cell 4 |

   Using text properties would make table alignment work without
   adjustments in the org-table.el code.

> One thing I would like to start doing is writing some tests for this
> feature.  It would be great if someone could point me to some tests
> that I can peruse so that I can get an idea of how I can go about
> writing some of my own.  Also, are there any procedures or things I
> should be aware of when trying to write my own tests?

Check out testing/README file in the Org repository.

Unfortunately, we do not yet have any existing tests for font-locking in
Org tests. You may still refer to the files in testing/lisp/ to see 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

Hello, attached is another updated patch with the following changes:

- Made it possible to add headlines or inline tasks
  to `org-ansi-highlightable-elements', these are added by default now.

- To tackle the issue discussed previously about highlights spanning
  multiple lines (or elements) being removed when a line is modified I
  went ahead and used the font-lock-multiline property (see
  font-lock-extend-region-multiline and
  font-lock-extend-region-functions) across those regions so that on
  any edit of one of the lines, the region including all of the ANSI
  sequences that affect that line will be re-fontified.  This was the
  easier solution, but the downside is that it can cause large regions
  to be re-fontified when really all we want to do is apply the
  highlighting face to a small line change, for example.  An
  alternative solution would, when no ANSI sequences are being edited
  in the region being fontified and assuming a previous fontification
  cycle has applied highlights due to ANSI sequences already, only
  apply the highlighting face to the edited region instead of
  expanding the region before fontification.  The expansion
  unnecessarily wastes the fontification cycle on a region larger than
  what it needs to be since the information needed for highlighting
  the region according to ANSI sequences has already been computed on
  a previous fontification cycle.  In practice I don't think this
  inefficiency will matter much since I would assume most of these
  ANSI sequences will be inserted due to the results of code block
  execution or inserted by users who want to highlight small regions
  of the document so I would consider this problem solved by using
  font-lock-multiline for the time being.  WDYT?

- To tackle the issue of editing around the invisible ANSI sequences I
  left it up to the font-lock process to catch the invisible edits.
  Whenever an edit deletes a character of the sequence that renders
  the sequence invalid, the font-lock process will reveal the partial
  sequence.  But I had to limit what was considered a valid ANSI
  sequence to get it working in a somewhat acceptable way.

  The problem that I found was that if the buffer contains something
  like
  
  ^[[43mfoo
  
  (where ^[ is the ESC character and can be inserted with "C-q ESC" and
  the whole sequence ^[[43m is the ANSI sequence) what was happening was
  that deleting into the hidden sequence would leave the region in the
  state
  
  ^[[43foo
  
  and because the end byte of the ANSI sequence can be any character
  in the ASCII range [@A-Z[\]^_`a–z{|}~], ^[[43f would still be a
  valid ANSI sequence and would be hidden during the fontification
  process after the edit.  Since `ansi-color-apply-on-region' only
  really handles the sequences that end in an m byte, just rendering
  all other ones invisible, I limited the ANSI sequences handled by
  this patch to be only those sequences that end in m.  This way,
  after deleting into the sequence like in the above example the
  fontification process would not recognize the region as containing
  any sequence.  The downside to this solution is that sequences that
  end in any other end byte won't get conveniently hidden and the
  problem still persists if you have text that starts with an m and
  you delete into a hidden sequence.
  
  An alternative solution that doesn't constrain the end byte could be
  to add in some extra invisible character like a zero width space and
  then use something like the `modification-hooks' text property on
  the character to signify that a deletion at the boundary between the
  sequence and the text should really delete part of the sequence
  instead of the zero width space.  I haven't really worked out the
  details of this, for example how would it be detected which
  direction a deletion is coming from, the front or behind, but I'm
  throwing it out there to see if there are any other solutions other
  people might be aware of for a similar problem.
  
- Finally, code has been added to delete the overlays on the hidden
  sequences in `org-unfontify-region' so that multiple overlays are not
  created on re-fontifying regions containing those sequences.

Other than that, the code is the same as the last patch.

> P.S. I am not yet commenting on the details in the code.

Please let me know what you think of this patch and where I should be
focusing my efforts moving forward to get this submitted to Org.

One thing I would like to start doing is writing some tests for this
feature.  It would be great if someone could point me to some tests
that I can peruse so that I can get an idea of how I can go about
writing some of my own.  Also, are there any procedures or things I
should be aware of when trying to write my own tests?

>From 506e8c1e5a177b797a541b1541ea98c95668d5e1 Mon Sep 17 00:00:00 2001
From: Nathaniel Nicandro 
Date: Tue, 9 May 2023 19:58:11 -0500
Subject: [PATCH] Highlight ANSI 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Matt  writes:

> Thank you for bringing this to my attention and thank you Nathaniel for your 
> work on this.

No problem, I'm glad to contribute to Org :)

> Nathaniel, if you and I happen to cross paths in one of Ihor's "office
> hours," I would enjoy learning more about what you're doing.

Sure.

With this patch I'm attempting to fontify the regions bounded by ANSI
escape sequences (just the color codes) in an Org buffer using the
built-in ansi-color package to do the processing of the sequences.  The
challenge, for me, seems to be making ansi-color aware of Org
element/object boundaries.

I am aware of other ANSI escape codes that would be useful to process
such as the carriage return and which appear, as you mentioned, when
dealing with progress bars in a shell session. Those escape codes are
not being handled at the moment. Although, I do have some experience in
processing them in an Org buffer when developing my Emacs-Jupyter
project. I would be glad to attempt handling these kinds of sequences in
Org proper as well.

-- 
Nathaniel

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> It runs fine on my side, although I am not sure if things are working as
> expected for all the cases. For example, headlines never got fontified
> on my side when I tried your patch on top of the latest main branch.

Yes, the headlines are currently not fontified since, with this patch, I
was mainly looking to satisfy the initial set of rules you laid out
which didn't mention headlines as being a fontifiable element for ANSI
sequences, or at least I didn't get that from my reading of them.

It does make sense, however, to be able to add headlines to the
`org-ansi-highlightable-elements` variable so that they are fontified if
the user wishes.  Although doing so with this patch wouldn't work.

> Also, it looks like you simply made the ASCII sequences invisible, which
> causes funky behaviour when trying to edit the text around. What we may
> need instead is something similar to hidden parts of the links that get
> revealed when we try to edit the invisible text. See
> `org-catch-invisible-edits' variable and the functions that examine it.

I agree that we should reveal the invisible sequence when trying to edit
it.

Thanks for the tip about `org-catch-invisible-edits', it led me to
`org-fold-show-set-visibility' which I think is the appropriate place to
reveal a hidden sequence.

> You may use `org-fontify-extend-region' to handle such scenarios if you
> mark the ANSI highlights with a special text property.

Thanks for the tip, I'll look into it.

-- 
Nathaniel

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Matt]

  On Thu, 14 Dec 2023 15:35:13 +0100  Ihor Radchenko  wrote --- 
 
 > Matthew, this thread might be of interest for you as the new feature is
 > largely aiming at the shell block output.
 > Feel free to jump in if you have comments on the design of the
 > ASCII fontification for complex shell block output.

Thank you for bringing this to my attention and thank you Nathaniel for your 
work on this.

I have no comments on the design presently (my knowledge of Emacs fontification 
is currently limited) and my current priorities prevent me from dedicating the 
time this topic deserves.

I think the topic is interesting and important.  I've had issues with ANSI 
escape codes (in particular progress bars) in source block results.  I made a 
note to return to this thread in case the escape codes don't bring me back :)

Nathaniel, if you and I happen to cross paths in one of Ihor's "office hours," 
I would enjoy learning more about what you're doing.

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> From 66baf6e1d435974fb4c51cc47eb5b3ace3feb22c Mon Sep 17 00:00:00 2001
> From: Nathaniel Nicandro 
> Date: Tue, 9 May 2023 19:58:11 -0500
> Subject: [PATCH] Highlight ANSI escape sequences

Matthew, this thread might be of interest for you as the new feature is
largely aiming at the shell block output.
Feel free to jump in if you have comments on the design of the
ASCII fontification for complex shell block output.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

> Attached is the updated version of the patch.  I've also attached an
> updated file that I've been using for testing the feature.

Sorry for the late reply, and thanks for the patch!
It runs fine on my side, although I am not sure if things are working as
expected for all the cases. For example, headlines never got fontified
on my side when I tried your patch on top of the latest main branch.

Also, it looks like you simply made the ASCII sequences invisible, which
causes funky behaviour when trying to edit the text around. What we may
need instead is something similar to hidden parts of the links that get
revealed when we try to edit the invisible text. See
`org-catch-invisible-edits' variable and the functions that examine it.

> What I have is essentially a function, org-fontify-ansi-sequences, that
> scans the buffer for an ANSI sequence and depending on the
> element-context processes the region that should be affected according
> to the rules you stated (see above).  The org-fontify-ansi-sequences-1
> function scans the buffer element-wise and processes the appropriate
> regions of the elements, even if no sequences appear in those regions,
> according to an ansi-context.  This is to support the fourth rule you
> mentioned.
>
> Note that modifications to highlighted regions hasn't really been
> considered so if you have a scenario like
>
> #+RESULTS:
> - Paragraph one
> - Paragraph two
>   Line 3
>
> where the sequence affects everything down to "Line 3" and you make a
> modification to line three, the fontification due to the sequence
> disappears on that line.

You may use `org-fontify-extend-region' to handle such scenarios if you
mark the ANSI highlights with a special text property.

> Also note that lesser elements contained in greater elements that
> don't have a RESULTS keyword are handled at the lesser element level
> so if you have something like
>
> #+begin_center
> Paragraph one.
>
> Paragraph two.
> #+end_center
>
> It would be the same as if you just had the paragraphs without the
> greater element.

Sounds reasonable.

P.S. I am not yet commenting on the details in the code.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> 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 =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:
>Lorem upsum =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:
>Lorem upsum =valor=. Some more text.
>
>Another paragraph inside drawer.
>:end:
>
>(everything down to :end: is affected)
>
>or
>
>#+RESULTS:
>- list
>- one
>- two
>- three
>

Hello Ihor,

Attached is the updated version of the patch.  I've also attached an
updated file that I've been using for testing the feature.

What I have is essentially a function, org-fontify-ansi-sequences, that
scans the buffer for an ANSI sequence and depending on the
element-context processes the region that should be affected according
to the rules you stated (see above).  The org-fontify-ansi-sequences-1
function scans the buffer element-wise and processes the appropriate
regions of the elements, even if no sequences appear in those regions,
according to an ansi-context.  This is to support the fourth rule you
mentioned.

Note that modifications to highlighted regions hasn't really been
considered so if you have a scenario like

#+RESULTS:
- Paragraph one
- Paragraph two
  Line 3

where the sequence affects everything down to "Line 3" and you make a
modification to line three, the fontification due to the sequence
disappears on that line.

Also note that lesser elements contained in greater elements that
don't have a RESULTS keyword are handled at the lesser element level
so if you have something like

#+begin_center
Paragraph one.

Paragraph two.
#+end_center

It would be the same as if you just had the paragraphs without the
greater element.

Please review the code and let me know what you think and how you
think we can move forward on this feature.

Thanks in advance.

#+TITLE: Test

Section 1

* Greater elements
:PROPERTIES:
:CUSTOM_ID: 123
:END:

#+begin_center
Inner paragraph one

Inner paragraph two
#+end_center

:drawer:
Inner paragraph one

Inner paragraph two
:end:

#+BEGIN: dblock1 :scope subtree :maxlevel 2
- Item 1
- Item 2
  - Item 3
- Item 4
#+END:

[fn:1] Footnote definition

*** TODO Inline task 1
Inner contents
*** END

*** TODO Inline task 2

- Paragraph one
- Paragraph two
  - Paragraph three
- Paragraph four

| cell 1 | cell 2 |
| cell 3   | cell 4 |

#+begin_quote
open 
#+end_quote

should not be highlighted

#+begin_quote
close 
#+end_quote

* Lesser elements
:PROPERTIES:
:DESCRIPTION: value
:END:

#+CALL: fn(str="text")

# Line one

#+begin_comment
Line one
Line two
#+end_comment

%%(diary-anniversary 10 31 1948) Arthur's Birthday

#+begin_example
Line one
Line two
#+end_example

#+begin_export latex
Line one
Line two
#+end_export

: Line one
: Line two

#+AUTHOR: First Last

\begin{quote}
Line one
Line two
\end{quote}

Paragraph one
Line two

#+begin_src python
for x in y:
print(x + "test")
#+end_src

* Object contexts

=verbatim= one

Lorem upsum =valor=. Some more text.

This is a paragraph src_python{return "testing"} {{{results(=testing=)}}} with
multiple inline src_python{return 5*4} {{{results(=20=)}}} source blocks.

An inline source block src_python{return 1+ 1 without an
end.  src_python{return "testing"}.

 Paragraph =one=

_underlined  text *bold  text * underlined  text_

_underlined 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

>> A few months have passed since the last activity in this thread.
>> May I know if you are still interested in the idea?
>
> I apologize for being unresponsive all these months. Yes I'm still
> interested in this idea, although I have not had time to work on it
> recently.  Life events caused me to have to stop working on it
> completely a few months back, I'm hoping to be able to put in more time
> now.

No problem.
There is no real rush. Just a gentle, infrequent, ping to keep things
progressing :)

> Where I'm having some trouble is processing the contents of greater
> elements.  My approach for them is basically to define an ansi-context
> (see `ansi-color-context-region`) for each greater element and process
> the inner elements using that context.  This seems to work except for
> plain-list elements which can have other plain-list elements within
> them, e.g.
>
> #+RESULTS:
> - List item 1
>   - Sub-list item 1
> - List item 2
> - List item 3
>
> Should the sub-list's sequence affect the rest of list elements in the
> parent list?  If that's the case, then I think I can keep with my
> approach and define an ansi-context for the outermost plain-list which
> is used by all the other plain-list elements contained within
> it. Otherwise I think I would have to do something like copy the
> ansi-context for each inner plain-list and use the copy to process the
> sequences in the inner-list so that the context of the outer-list is
> unaffected. WDYT?

Just go with whatever is simpler implementation-wise. It is a good idea
to get things working first, and only then go ahead with tweaking small
details as necessary.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Hi,

Hi Ihor,

> A few months have passed since the last activity in this thread.
> May I know if you are still interested in the idea?

I apologize for being unresponsive all these months. Yes I'm still
interested in this idea, although I have not had time to work on it
recently.  Life events caused me to have to stop working on it
completely a few months back, I'm hoping to be able to put in more time
now.

I haven't even been able to put that much time into my more popular
personal projects recently either!

> Should you need any help, feel free to ask.

I have been working on some code to satisfy the set of rules you
provided in a previous email of this thread.  I've made some progress,
but the code is a little messy and buggy.  I would like to clean it up
first before I present it.

Where I'm having some trouble is processing the contents of greater
elements.  My approach for them is basically to define an ansi-context
(see `ansi-color-context-region`) for each greater element and process
the inner elements using that context.  This seems to work except for
plain-list elements which can have other plain-list elements within
them, e.g.

#+RESULTS:
- List item 1
  - Sub-list item 1
- List item 2
- List item 3

Should the sub-list's sequence affect the rest of list elements in the
parent list?  If that's the case, then I think I can keep with my
approach and define an ansi-context for the outermost plain-list which
is used by all the other plain-list elements contained within
it. Otherwise I think I would have to do something like copy the
ansi-context for each inner plain-list and use the copy to process the
sequences in the inner-list so that the context of the outer-list is
unaffected. WDYT?

-- 
Nathaniel

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Ihor Radchenko  writes:

> A few months have passed since the last activity in this thread.

Canceled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Hi,

A few months have passed since the last activity in this thread.
May I know if you are still interested in the idea?
Should you need any help, feel free to ask.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>>> 1. Do not allow ANSI sequences to intersect markup boundaries of the
>>>same AST depth:
>>>*bold * plain text  should not trigger fontification
>>>*bold  /italic/ * should trigger
>>>plain text  *bold* plain text  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:
>>
>> *bold* plain text 
>> plain text *bold * 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  codes are not 
> pairs, but switches; this is completely different from Org syntax.
>
> So, let me re-consider where  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 =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:
>Lorem upsum =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:
>Lorem upsum =valor=. Some more text.
>
>Another paragraph inside drawer.
>:end:
>
>(everything down to :end: is affected)
>
>or
>
>#+RESULTS:
>- 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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

>> 1. Do not allow ANSI sequences to intersect markup boundaries of the
>>same AST depth:
>>*bold * plain text  should not trigger fontification
>>*bold  /italic/ * should trigger
>>plain text  *bold* plain text  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:
>
> *bold* plain text 
> plain text *bold * 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  codes are not 
pairs, but switches; this is completely different from Org syntax.

So, let me re-consider where  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 =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:
   Lorem upsum =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:
   Lorem upsum =valor=. Some more text.

   Another paragraph inside drawer.
   :end:

   (everything down to :end: is affected)

   or

   #+RESULTS:
   - 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 .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  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 ==, and closing term is ==
> 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 * plain text  should not trigger fontification
>*bold  /italic/ * should trigger
>plain text  *bold* plain text  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:

*bold* plain text 
plain text *bold * 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

 plain == text 

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 
>
> Another paragraph 
> :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

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  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 ==, and closing term is ==
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 * plain text  should not trigger fontification
   *bold  /italic/ * should trigger
   plain text  *bold* plain text  also should
2. Disallow fontification is certain contexts - 'inline-src-block

Further, your current code will do something weird when encountering
greater element:

:DRAWER:
Paragraph 

Another paragraph 
:END:

You should not consider greater elements when fontifying.

> +(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?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>>> Ideally, fontifying ANSI sequences should be fully controlled by users:
>>> 1. We may not want to touch src blocks by default, when
>>>`org-src-fontify-natively' is set to t. Only, maybe, provide an
>>>option. Or you may better publish a minor mode that does this for
>>>shell scripts.
>>> 2. We may allow all the ANSI sequences to be fontified in the whole
>>>buffer.
>>
>> I've updated my patch to be a combination of (1) and (2), see the
>> attached patch.  Essentially every sequence is fontified except those in
>> source blocks and a minor mode has been created to allow users to
>> disable or enable fontification whenever they want.
>>
>> I've also attached an example Org file with some ANSI sequences in it
>> for testing purposes that you can try out.
>
> Thanks!
>
>> One issue that remains is how to handle sequences within inline source
>> blocks.  Those don't have a src-block property so any sequences within
>> an inline source block are currently fontified.
>
> You should not use 'src-block property at all. There are scenarios when
> jit-lock defers source block fontification (in particular, when source
> block spans beyond the screen) and 'src-block property is not yet
> applied.
>
> Instead, you should query `org-element-at-point' or
> `org-element-context'.

The attached patch now uses `org-element-at-point' and
`org-element-context' to query for the bounds of elements.

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.

>
>> +*** ANSI escape sequences are now highlighted in the whole buffer
>> +
>> +A new customization ~org-fontify-ansi-sequences~ is available which
>> +tells Org to highlight all ANSI sequences in the buffer if non-nil and
>> +the new minor mode ~org-ansi-mode~ is enabled.
>> +
>> +To disable highlighting of the sequences you can either
>> +disable ~org-ansi-mode~ or set ~org-fontify-ansi-sequences~ to ~nil~
>> +and =M-x revert-buffer RET=.  Doing the latter will disable
>> +highlighting of sequences in all newly opened Org buffers whereas
>> +doing the former disables highlighting locally to the current buffer.
>
> Rather than asking to use revert-buffer, we usually suggest M-x
> org-mode-restart.

Done.

>
>> +(defun org-fontify-ansi-sequences (limit)
>> +  "Fontify ANSI sequences."
>> +  (when (and org-fontify-ansi-sequences org-ansi-mode)
>> +(let (end)
>> +  (while (/= (point) limit)
>
> Instead of this strict condition and later juggle with
> `narrow-to-region', just use the usual (while (< (point) limit) ...).
>

Done.

>> +(cond
>> + ((get-text-property (point) 'src-block)
>
> As I mentioned above, please use `org-element-at-point'. This function
> will also give you information about the block boundaries.
>
>> +(ansi-color-apply-on-region (point) end t)
>
> We should probably limit ANSI colour pairs to a single Org element. It
> does not make much sense to have text in-between the quotes below
> coloured:
>
> #+begin_quote
> ...  ...
> #+end_quote
>
>
> 
>
> #+begin_quote
> ...  ...
> #+end_quote
>

Makes sense. Done.

>> +;; Reset the context before every fontification cycle.  This
>> +;; avoids issues where `ansi-color-apply-on-region' attempts to
>> +;; use an old starting point that may be from a different part
>> +;; of the buffer, leading to "wrong side of point" errors.
>> +(setq ansi-color-context-region nil)
>
> This looks fragile. AFAIU, `ansi-color-context-region' is used to track
> currently active ANSI colour settings. Since your fontification function
> may be called with various LIMITs, depending on what is displayed on the
> user screen, the fontification results might be unpredictable for ANSI
> defs spanning across multiple screens.
>

It seems to be safe to reset `ansi-color-context-region' now given that
org-element is used to find the bounds of the element at
`point'. Although the fontification limits are dependent on screen size,
the org-element functions are not and so the bounds used when applying
the fontification for the ANSI sequences won't depend on screen size
either.

Also, re-setting `ansi-color-context-region' has the effect of not
propagating previously applied color settings to other Org elements.

>> +(defvar org-ansi-colors
>> +  '(black red green yellow blue purple cyan white))
>> +
>> +(defun org-ansi-highlight (beg end seq)
>> +  (save-excursion
>> +(goto-char end)
>> +(insert "\e")
>> +(insert "[0m")
>> +(goto-char beg)
>> +(insert "\e")
>> +(insert (format "[%sm" seq
>> +
>> +(defun org-ansi-highlight-foreground (beg end color)
>> +  "Highlight the foreground between BEG and END with COLOR."
>> +  (interactive
>> +   (let ((bounds (car (region-bounds
>> + (list (car bounds) (cdr 

Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Ihor Radchenko]

Nathaniel Nicandro  writes:

>> Ideally, fontifying ANSI sequences should be fully controlled by users:
>> 1. We may not want to touch src blocks by default, when
>>`org-src-fontify-natively' is set to t. Only, maybe, provide an
>>option. Or you may better publish a minor mode that does this for
>>shell scripts.
>> 2. We may allow all the ANSI sequences to be fontified in the whole
>>buffer.
>
> I've updated my patch to be a combination of (1) and (2), see the
> attached patch.  Essentially every sequence is fontified except those in
> source blocks and a minor mode has been created to allow users to
> disable or enable fontification whenever they want.
>
> I've also attached an example Org file with some ANSI sequences in it
> for testing purposes that you can try out.

Thanks!

> One issue that remains is how to handle sequences within inline source
> blocks.  Those don't have a src-block property so any sequences within
> an inline source block are currently fontified.

You should not use 'src-block property at all. There are scenarios when
jit-lock defers source block fontification (in particular, when source
block spans beyond the screen) and 'src-block property is not yet
applied.

Instead, you should query `org-element-at-point' or
`org-element-context'.

> +*** ANSI escape sequences are now highlighted in the whole buffer
> +
> +A new customization ~org-fontify-ansi-sequences~ is available which
> +tells Org to highlight all ANSI sequences in the buffer if non-nil and
> +the new minor mode ~org-ansi-mode~ is enabled.
> +
> +To disable highlighting of the sequences you can either
> +disable ~org-ansi-mode~ or set ~org-fontify-ansi-sequences~ to ~nil~
> +and =M-x revert-buffer RET=.  Doing the latter will disable
> +highlighting of sequences in all newly opened Org buffers whereas
> +doing the former disables highlighting locally to the current buffer.

Rather than asking to use revert-buffer, we usually suggest M-x
org-mode-restart.

> +(defun org-fontify-ansi-sequences (limit)
> +  "Fontify ANSI sequences."
> +  (when (and org-fontify-ansi-sequences org-ansi-mode)
> +(let (end)
> +  (while (/= (point) limit)

Instead of this strict condition and later juggle with
`narrow-to-region', just use the usual (while (< (point) limit) ...).

> +(cond
> + ((get-text-property (point) 'src-block)

As I mentioned above, please use `org-element-at-point'. This function
will also give you information about the block boundaries.

> +(ansi-color-apply-on-region (point) end t)

We should probably limit ANSI colour pairs to a single Org element. It
does not make much sense to have text in-between the quotes below
coloured:

#+begin_quote
...  ...
#+end_quote



#+begin_quote
...  ...
#+end_quote

> +;; Reset the context before every fontification cycle.  This
> +;; avoids issues where `ansi-color-apply-on-region' attempts to
> +;; use an old starting point that may be from a different part
> +;; of the buffer, leading to "wrong side of point" errors.
> +(setq ansi-color-context-region nil)

This looks fragile. AFAIU, `ansi-color-context-region' is used to track
currently active ANSI colour settings. Since your fontification function
may be called with various LIMITs, depending on what is displayed on the
user screen, the fontification results might be unpredictable for ANSI
defs spanning across multiple screens.

> +(defvar org-ansi-colors
> +  '(black red green yellow blue purple cyan white))
> +
> +(defun org-ansi-highlight (beg end seq)
> +  (save-excursion
> +(goto-char end)
> +(insert "\e")
> +(insert "[0m")
> +(goto-char beg)
> +(insert "\e")
> +(insert (format "[%sm" seq
> +
> +(defun org-ansi-highlight-foreground (beg end color)
> +  "Highlight the foreground between BEG and END with COLOR."
> +  (interactive
> +   (let ((bounds (car (region-bounds
> + (list (car bounds) (cdr bounds) 
> +   (completing-read "Color: " org-ansi-colors nil t
> +  (let ((n (- (length org-ansi-colors)
> +  (length (memq color org-ansi-colors)
> +(org-ansi-highlight beg end (+ 30 n
> +
> +(defun org-ansi-highlight-background (beg end color)
> +  "Highlight the background between BEG and END with COLOR."
> +  (interactive
> +   (let ((bounds (car (region-bounds
> + (list (car bounds) (cdr bounds) 
> +   (completing-read "Color: " org-ansi-colors nil t
> +  (let ((n (- (length org-ansi-colors)
> +  (length (memq color org-ansi-colors)
> +(org-ansi-highlight beg end (+ 40 n

The above has no relation to fontification and does not belong to Org in
general. Org syntax has no notion of ANSI escapes. We may support them
as a useful feature, but no more. Editing ANSI escapes would make more
sense in shell-script-mode or similar.

> +  :lighter " OANSI"
> +  (cond
> +   ((and org-fontify-ansi-sequences 

[PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements)

[Nathaniel Nicandro]

Ihor Radchenko  writes:

> Nathaniel Nicandro  writes:
>
>> Attached is the patch.  Without this patch, ANSI escape sequences
>> generated by the output of a source block will be left in the buffer
>> without any fontification.  With this patch, the escaped text is nicely
>> colored and escape sequences hidden using overlays.
>>
>> It works for Emacs versions which have the `PRESERVE-SEQUENCES` argument
>> to the `ansi-color-apply-on-region` function.  It's a bit slow due to
>> the use of overlays.  My implementation of this feature in Emacs-Jupyter
>> supports older versions of Emacs without that argument, it relies on a
>> custom version of that function though and uses text properties instead
>> of overlays.
>>
>> Let me know what else could be done on my end to get this patch in.
>> Thanks.
>
> Thanks for the patch!
>
> This is an interesting idea, but I am not sure if we want to use this
> colouring by default. At least, it should be a minor mode. Probably
> enabled by default. Because not every possible user may want to have the
> escape sequences hidden away.
>
> Further, your patch only allows fontifying ANSI sequences in fixed-width
> elements, example blocks, export blocks, and src blocks without known
> major mode that does the fontification. I doubt that fontifying ANSI
> sequences in this specific subset of elements always makes sense -
> example blocks are not always used as src block output; bash code blocks
> may purposely contain escape sequences, but your patch will not handle
> them; inline src block output is not covered at all.
>
> Ideally, fontifying ANSI sequences should be fully controlled by users:
> 1. We may not want to touch src blocks by default, when
>`org-src-fontify-natively' is set to t. Only, maybe, provide an
>option. Or you may better publish a minor mode that does this for
>shell scripts.
> 2. We may allow all the ANSI sequences to be fontified in the whole
>buffer.

I've updated my patch to be a combination of (1) and (2), see the
attached patch.  Essentially every sequence is fontified except those in
source blocks and a minor mode has been created to allow users to
disable or enable fontification whenever they want.

I've also attached an example Org file with some ANSI sequences in it
for testing purposes that you can try out.

One issue that remains is how to handle sequences within inline source
blocks.  Those don't have a src-block property so any sequences within
an inline source block are currently fontified.

> 3. We may limit ANSI sequence fontification to results and only results.
>Or just certain types of results.
>
> The easiest will be implementing fontification in the whole buffer,
> early during fontification (and early in org-font-lock-keywords; see
> org-font-lock-set-keywords-hook).

* This is a test

Of ANSI color sequences

#+begin_src python
for x in y:
print(x + "this is a test")
#+end_src

: this is a td

=testing=

In paragraph a ~color sequence~ is here.

This is a sequence that covers a block

#+begin_example
should be colored
#+end_example

there should be an end here there is the end.

begin  
sequence
without end
#+begin_src python
1 + 1
#+end_src

Inline source blocks will have sequences highlighted because we only
look for a src-block text property.

src_python{return "testing"}
>From c9b505d022410a481210928ecc4cce1f199ec53b Mon Sep 17 00:00:00 2001
From: Nathaniel Nicandro 
Date: Thu, 13 Apr 2023 15:06:35 -0500
Subject: [PATCH] Highlight ANSI escape sequences

* etc/ORG-NEWS: Describe the new feature.
* org.el (org-fontify-ansi-sequences): New customization variable and
function which does the work of fontifying the sequences.
(org-set-font-lock-defaults): Add the `org-fontify-ansi-sequences`
function to the font-lock keywords.
(org-ansi-mode): New minor mode to enable/disable highlighting of the
sequences.  Enabled in Org buffers by default.
---
 etc/ORG-NEWS |  12 ++
 lisp/org.el  | 112 +++
 2 files changed, 124 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index b7c88fd..8690540 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -169,6 +169,18 @@ official [[https://clojure.org/guides/deps_and_cli][Clojure CLI tools]].
 The command can be customized with ~ob-clojure-cli-command~.
 
 ** New features
+*** ANSI escape sequences are now highlighted in the whole buffer
+
+A new customization ~org-fontify-ansi-sequences~ is available which
+tells Org to highlight all ANSI sequences in the buffer if non-nil and
+the new minor mode ~org-ansi-mode~ is enabled.
+
+To disable highlighting of the sequences you can either
+disable ~org-ansi-mode~ or set ~org-fontify-ansi-sequences~ to ~nil~
+and =M-x revert-buffer RET=.  Doing the latter will disable
+highlighting of sequences in all newly opened Org buffers whereas
+doing the former disables highlighting locally to the current