From: Nathaniel Nicandro <nathanielnicandro@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
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: Mon, 22 May 2023 19:55:28 -0500 [thread overview]
Message-ID: <87353ng8nk.fsf@gmail.com> (raw)
In-Reply-To: <87a5y1mnj0.fsf@localhost>
Ihor Radchenko <yantar92@posteo.net> writes:
> 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?
>
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
next prev parent reply other threads:[~2023-05-23 1:05 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
2023-05-23 0:55 ` Nathaniel Nicandro [this message]
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
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87353ng8nk.fsf@gmail.com \
--to=nathanielnicandro@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).