From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id wH/KDmoRbGRhbgAASxT56A (envelope-from ) for ; Tue, 23 May 2023 03:05:46 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id wHf7DWoRbGS64QAAG6o9tA (envelope-from ) for ; Tue, 23 May 2023 03:05:46 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 8B41822BC6 for ; Tue, 23 May 2023 03:05:45 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q1GSN-00039G-Gq; Mon, 22 May 2023 21:04:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q1GSL-000398-OT for emacs-orgmode@gnu.org; Mon, 22 May 2023 21:04:53 -0400 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q1GSJ-0000D6-UQ for emacs-orgmode@gnu.org; Mon, 22 May 2023 21:04:53 -0400 Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-75b1793d2bcso25045085a.0 for ; Mon, 22 May 2023 18:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684803889; x=1687395889; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:from:to:cc:subject:date:message-id:reply-to; bh=qY+4DOi0GpVaOjlBqrhDKSuKPSJYfs4b29rCHLVXh1o=; b=N7k1nUwmtjgR/zYtRkOJnEDQc/JYNQpPK/Xw4HzSDJl9HSXdHdtTxKqdjy+PZjk4WN SxXaq9yRLu6d+YdXCdO/oLkL+cWh698Xv3iIHQyDtrVlQjuL8QZmLVqOrCvO0/0s/Kv/ jI1mjEQHfFL6+CZsCq16/GklhSN9gHlyqh1Br6tffwcmhtcaEXR4Co2MjN3ytNtDYWZO 5HwQ4Eq7wNnNzaJqRMX/DxHMIo5ip3J6AWrdzwrKHpxUzwwozl4a1xGji+EkCFh4zNPj MDrV1mCk8mbQzWzxwjOU96lF6VfKrd3GEDKeeSooHo14xTaqIv1IFoQD8kJQSemPz/Ak o/Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684803889; x=1687395889; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qY+4DOi0GpVaOjlBqrhDKSuKPSJYfs4b29rCHLVXh1o=; b=PgoJ069doEVaIB6SS+1K4XO40zqftLZ+8yFoNlkW3lABuw/Pxw8fvliAGxUPfV13bq xJXLuv4q7krYBDknQuTQy5vdHIDgyFTcCulAARIJydxWE+5OY4v6ESPf+RRmz8FneDUT fpTTaoLNDsZEtccuGmaPQqxM6COSVaerNf5LJKZ59zymDzJ2Pmg9j7ERqS6JvZr6s8pv NWUr7E8ZbGBA0OXpejuktP0qJXzAQOLm5icQoQkudrXuiKfO/SNh/GFMIPH+ush1ig8y aZw9qSAoROADjmt9R7Dz4SvDuMsmGgnAGBcqZJM0EZlwWJammYuAOzfgsnSB71FaSzHl LsWA== X-Gm-Message-State: AC+VfDweHFqg19w9LaBhKZrStPu8/CyXOqjliIHC0mp5EDO/2wp/pbyk BDfK5eHyQR5oWdGKqLGRDxtxB/nar3A= X-Google-Smtp-Source: ACHHUZ7Yz3qE99BZ0i1APJH+Okky1A1+8OG1aAWDQTEdR/lulR1JrB/+YxFED+c+zcWtjV5Wn80HVg== X-Received: by 2002:a05:6214:3016:b0:624:dcc5:819f with SMTP id ke22-20020a056214301600b00624dcc5819fmr12379567qvb.1.1684803889265; Mon, 22 May 2023 18:04:49 -0700 (PDT) Received: from entropy ([2601:241:8c80:25a0::2ec4]) by smtp.gmail.com with ESMTPSA id dd18-20020ad45812000000b0061b2a2f949bsm2340413qvb.61.2023.05.22.18.04.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 May 2023 18:04:48 -0700 (PDT) References: <874jpuijpc.fsf@gmail.com> <87y1n6igvo.fsf@localhost> <878rev1q0k.fsf@gmail.com> <877cueonkj.fsf@localhost> <87zg6dez93.fsf@gmail.com> <871qjobhwa.fsf@localhost> <877ct5fzt6.fsf@gmail.com> <87a5y1mnj0.fsf@localhost> User-agent: mu4e 1.8.13; emacs 30.0.50 From: Nathaniel Nicandro To: Ihor Radchenko Cc: emacs-orgmode 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 In-reply-to: <87a5y1mnj0.fsf@localhost> Message-ID: <87353ng8nk.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::72c; envelope-from=nathanielnicandro@gmail.com; helo=mail-qk1-x72c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1684803946; a=rsa-sha256; cv=none; b=fzNJ8qBCHG5YRlDdAEB1lNL45s2hRP3ziz9wxDRazHP+jJIy2bS5h/LUjBubM6PvMaCMUl mL+I3rXXdsLgjF4KJSTQzTRBXB2RUHxvqBy6ySG7CUj8R4B3RtQlpjC4ZWZK3kX2R35ylA wvJsJ1rS5ANZftNkE2z0mXSDwANm4wTjHQ75Gz57YhyvbX/OZoTr68y5pwvQvVv60YtC3o JePqgh9C9kX2p5AFuApNfc0NuIcFx5rLb39ZQXTZl9wUJI0W6VIIhYx9Jw5ZsgtAR+eztf LrMQxqu/wjOpGs6ERuuytQWYgiMIcw5SWAWJd+wL4gxppn5imBl5BM6lcsT4Hw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=N7k1nUwm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1684803946; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=qY+4DOi0GpVaOjlBqrhDKSuKPSJYfs4b29rCHLVXh1o=; b=Diu9v6loCoXb6oisN0bdkERh4H0Lr51ZzliIy1zQa6nRiI10yfe0HkTSfW7HGGK+nd8JrM iTi8f9IMB5yRchYI36HVCLcklhDd+SP80QFLzt1+dihBmjhJi5i7SpItqfbsYiAofW93K2 9FXcd8NUf2GcHVCImOqOY0t604XEd0lcEC+af2xvwsJTSuTE7POouGVV8QX2mCPq+NVOrO 0RqpeniSjIDYmIMnXNpfLgfZxFbP9DR6HhVJ8Z8BwTkJ0Xk5QlRhJv5ot57n2OEZ84iajp cn7FELfDXLUQpNklFRezY+H0uG2oYjn0qvOExb8BZfwX4CSLBaTZxS+DxLCLzg== X-Migadu-Spam-Score: -8.28 X-Spam-Score: -8.28 X-Migadu-Queue-Id: 8B41822BC6 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=N7k1nUwm; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-TUID: qYsvjxR/70NQ 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