all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ihor Radchenko <yantar92@posteo.net>
To: Nathaniel Nicandro <nathanielnicandro@gmail.com>
Cc: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: Re: [PATCH] Highlight ANSI sequences in the whole buffer  (was [PATCH] ANSI color on example blocks and fixed width elements)
Date: Thu, 18 May 2023 19:45:39 +0000	[thread overview]
Message-ID: <87a5y1mnj0.fsf@localhost> (raw)
In-Reply-To: <877ct5fzt6.fsf@gmail.com>

Nathaniel Nicandro <nathanielnicandro@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>


  reply	other threads:[~2023-05-18 19:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 12:03 [PATCH] ANSI color on example blocks and fixed width elements Nathaniel Nicandro
2023-04-05 13:43 ` Ihor Radchenko
2023-04-13 20:18   ` [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements) Nathaniel Nicandro
2023-04-14  8:49     ` Ihor Radchenko
2023-04-25 20:33       ` Nathaniel Nicandro
2023-05-10 10:27         ` Ihor Radchenko
2023-05-15  0:18           ` Nathaniel Nicandro
2023-05-18 19:45             ` Ihor Radchenko [this message]
2023-05-23  0:55               ` Nathaniel Nicandro
2023-08-08 11:02                 ` Ihor Radchenko
2023-11-08  9:56                   ` Ihor Radchenko
2023-11-08 15:35                   ` Nathaniel Nicandro
2023-11-10 10:25                     ` Ihor Radchenko
2023-11-17 21:18               ` Nathaniel Nicandro
2023-12-14 14:34                 ` Ihor Radchenko
2023-12-24 12:49                   ` Nathaniel Nicandro
2024-01-17  0:02                   ` Nathaniel Nicandro
2024-01-17 12:36                     ` Ihor Radchenko
2024-03-26 14:02                       ` Nathaniel Nicandro
2024-03-28  8:52                         ` Ihor Radchenko
2024-06-29 10:42                           ` Ihor Radchenko
2024-07-01 18:39                             ` Nathaniel Nicandro
2024-07-06 13:28                               ` Ihor Radchenko
2024-07-16 20:53                                 ` Nathaniel Nicandro
2024-07-17 22:50                                 ` Nathaniel Nicandro
2024-07-20 17:57                                   ` Ihor Radchenko
2023-12-14 14:37                 ` Ihor Radchenko
2023-12-15 12:50                   ` Matt
2023-12-25  2:20                     ` Nathaniel Nicandro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5y1mnj0.fsf@localhost \
    --to=yantar92@posteo.net \
    --cc=emacs-orgmode@gnu.org \
    --cc=nathanielnicandro@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.