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 aCM9Dy0+ZmS7DgEASxT56A (envelope-from ) for ; Thu, 18 May 2023 17:03:09 +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 COY6Di0+ZmTMMQEAG6o9tA (envelope-from ) for ; Thu, 18 May 2023 17:03:09 +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 D21CE2354D for ; Thu, 18 May 2023 17:03:08 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pzf94-0004we-JC; Thu, 18 May 2023 11:02:22 -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 1pzf92-0004nK-98 for emacs-orgmode@gnu.org; Thu, 18 May 2023 11:02:20 -0400 Received: from mail-ot1-x32a.google.com ([2607:f8b0:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pzf90-0007BG-D2 for emacs-orgmode@gnu.org; Thu, 18 May 2023 11:02:19 -0400 Received: by mail-ot1-x32a.google.com with SMTP id 46e09a7af769-6ab0d407a8fso347102a34.0 for ; Thu, 18 May 2023 08:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684422136; x=1687014136; 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=uIak9Kdh7IT9w9gN7jmA4Tm7/3C8LSkyYI14hu4PGvU=; b=RfjCM9UiZcdIaylAc9Kwat6mUv6iF/c9DsXupapQnOQK7CLjGBtDBGrl5gEtN4eW4h JB0H5boK5HIMywLmPGys5SfW6rESuZ+ZDpwo4/4a4N/h7a5GPShhWaVLbDskryB/m9sz 49g+jZ9dahHY5vNrI5ubi8r614gIz5wImvVj+aJ/XyLAe1lT0kZ5gBonXNPrII1Hg16/ rUO8T4PAyNGyFu8dIaIqb4YXr6eUU2F/sbvCV/ZXmtyNTH6qywVRTJA/VHDIFSD2+9i3 loMVIsX5pIqJ94ywaA257MW2io9NnaLk3iTUsGWJzVHo0mqMJ8fB+qY2Xvl7BQ9k/rrO StCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684422136; x=1687014136; 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=uIak9Kdh7IT9w9gN7jmA4Tm7/3C8LSkyYI14hu4PGvU=; b=Jlm7mV0oZxI/eWwzIP4BtU2Eyvfnj480qrvxRgwho/JFcP4Irct8TmL0hcdAl51+5x diSmE6+u8oqZ5atuyG0LD8DSWryEyoiIlBk+NDpK8jFWT2jVQj1YApwF6JdL/hTzoSMv f9IFNLXqwyhOy/SuY9/GAbFLS9Zyi3OqZKoIIYvvOhMCtHSlOPphMWMgEsn4YvZY0qU8 Ff6UbIAiqvqf1Cu7t593AnQyr49mdue/db31vxqAFH2IXdKlHBietAVLhRQxX1g/iu1d IsiHw1QVphW3fjm8F0OOYdgW6cmJ39wiZn+Z11IymkdFQdnpTYu5PbNxTzJO3MvRY9fj qttw== X-Gm-Message-State: AC+VfDzdacPrRyfBU3grCFH5aMCI4dJ8uMSlkwBgf+Fz+0UCiHdkalmH qjyuCF3Snhfr3kg2d6kh2ZJNlaJqM08= X-Google-Smtp-Source: ACHHUZ5C8EQtV/oY4Cj9SjIVQ2xL1DndURJLF0XiZZ8BszyrZe9Kan5LcmFZY/fCib95rB+Ugl3cPQ== X-Received: by 2002:a05:6358:be8f:b0:123:4fc0:f1b4 with SMTP id di15-20020a056358be8f00b001234fc0f1b4mr17098rwb.0.1684422136035; Thu, 18 May 2023 08:02:16 -0700 (PDT) Received: from entropy ([2601:241:8c80:25a0::ad51]) by smtp.gmail.com with ESMTPSA id m10-20020ae9e00a000000b0074e21136a77sm439077qkk.127.2023.05.18.08.02.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 May 2023 08:02:15 -0700 (PDT) References: <874jpuijpc.fsf@gmail.com> <87y1n6igvo.fsf@localhost> <878rev1q0k.fsf@gmail.com> <877cueonkj.fsf@localhost> <87zg6dez93.fsf@gmail.com> <871qjobhwa.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: Sun, 14 May 2023 19:18:03 -0500 In-reply-to: <871qjobhwa.fsf@localhost> Message-ID: <877ct5fzt6.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::32a; envelope-from=nathanielnicandro@gmail.com; helo=mail-ot1-x32a.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=1684422188; a=rsa-sha256; cv=none; b=cHCnkWCac2HIipKwzf9cgO5G7Q7dj/mrXB3jQpsPvP7M8v+VfHbQU6SjY8WZpsT4L82OJX 7BqzLqn91IkgrX0UNNVq3pRMJmp72v18C8yhCyr0z30xO8AScFTB4RnmW2EjlaZsW6Q/GO 1/3ksJN3b6A8aL04O9KLXl//0rkuMgm2B13hc8JOUZUqqqiRRTQdlBg/5RSvAozCvsQN35 nZj3rM8S0gKRZV5X+jEn5SCH8ySv2TcFVt1p90NSCvNjXUUJvGQ0IvXtpMDe0nf5+2cbqH LDSvj9AvwAiPOMNcNhdlsbh6Jce245sEDA+pHrna3DVZjN0/jkrMmyfcie8aKg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=RfjCM9Ui; 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=1684422188; 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=uIak9Kdh7IT9w9gN7jmA4Tm7/3C8LSkyYI14hu4PGvU=; b=OoF+ITXU5ZosUhicQ26ON0YgmHNzTXVWfjR4fTWtiRsSrmmTYf7iuUWa2M/EcCulRHs0GP nfuF/+Ky8r15/L4MMKmWwV9GJPI9li/kxMovs+92cPIjbOd3H9g+U9y+utJsUvxNAWTF3J XXfpyDZg9HuivSmKv51DiDgG0+b3RuZf8Wq9RsiOyLB4ys8br4eKS+xeCDSLcDmbn8KdcD odsIE2lzWgPeUI1sTjdO8CD8I10Bw8g8ZuhGLRt1IaGvpC9mAOAXUDye7A6NlO7a9xjRaU epfZTnh6z849ObsCMzxX6oGfiF+Fr5o86AggkoMjHCO0g3F/XDwCIFMrFeu2rg== X-Migadu-Spam-Score: -8.86 X-Spam-Score: -8.86 X-Migadu-Queue-Id: D21CE2354D X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=RfjCM9Ui; 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: /iNw1MG0jsXX 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