From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id OL3WKXcTOWQzKwEASxT56A (envelope-from ) for ; Fri, 14 Apr 2023 10:48:55 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qDEMKXcTOWQvDQAAG6o9tA (envelope-from ) for ; Fri, 14 Apr 2023 10:48:55 +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 58B6E1A05 for ; Fri, 14 Apr 2023 10:48:54 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnF5r-0007gX-96; Fri, 14 Apr 2023 04:47:43 -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 1pnF5p-0007f8-Fa for emacs-orgmode@gnu.org; Fri, 14 Apr 2023 04:47:41 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pnF5Q-00065h-Qt for emacs-orgmode@gnu.org; Fri, 14 Apr 2023 04:47:37 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4706E2401F4 for ; Fri, 14 Apr 2023 10:47:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1681462031; bh=v9zgibIFzIHyaw15yaqJrfklSspNFFs3ff4PzKj0xL4=; h=From:To:Cc:Subject:Date:From; b=qZMEjYTd/kfU576wxZ5Pq748oWuvZNvtI9z69XkFDZUeOE+6W2M89iO9Jo07q+AtE S29nXkrfsuWAfaIGllDPLR341NdQwquv7ZRy+l/3er5pYdmvexfRzkyY/xBHCK9Pr/ p4ItEs8W84TmOy8c7zOpCtRbGbIyQEO3sZMSPjO2NMQEj2hQe3y2hWskSgtZDAZxBE ewFPdOWrzHs0mpCWAbJ2NXgN8g3JlF1UVrWsx88JuU10fZy/KhExI8QKvQLKPzrLvn +f/kFdWGLN3yAGdbgzSaICMTYvJF5pCWTEpEYWXtj87VBM/X9IzpN2RGFz0p9cr1QP UshuKoFLL7g8Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4PyVSG40YMz9s27; Fri, 14 Apr 2023 10:47:10 +0200 (CEST) From: Ihor Radchenko To: Nathaniel Nicandro Cc: emacs-orgmode Subject: Re: [PATCH] Highlight ANSI sequences in the whole buffer (was [PATCH] ANSI color on example blocks and fixed width elements) In-Reply-To: <878rev1q0k.fsf@gmail.com> References: <874jpuijpc.fsf@gmail.com> <87y1n6igvo.fsf@localhost> <878rev1q0k.fsf@gmail.com> Date: Fri, 14 Apr 2023 08:49:48 +0000 Message-ID: <877cueonkj.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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=1681462134; a=rsa-sha256; cv=none; b=RuODLxYsX6QoJ5zoO0DtBujKh8Ja85z84qIk0GjISxqQm3d5cU47SV11eawR7AKpkN+I3R eK9poSie3IcI1cDG27eDFVgKgsxTzCzt4PJrTdbPhACh75STkLEenCh6qY+bAAlMVrjnSH +8zndqtjZH1fp8EUREWimE42Bpm9sQvfgA5IWtvdF9GyhZnYc+ve2AAg1iJLD7SUPszskb xABqeWFT7qbNXJnV+K4tMDDiZWraPp8yc2i+KFUBJA1HdWOkjziGX6CgNxu8VuASEraQGR 4a5xSQ7I/brBB4kQ1wf+g+r3OKnceN4IXBE08Llwqc0jM0zE1rOqW0cL2CAung== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qZMEjYTd; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1681462134; 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=kKrBD86b8o9hDemy59fUF7lz7rn7b7hUbtEKjeI5gYU=; b=s6t8ma0asvH17c5QFlM16afi/SFIjmFIvkllRpl8JNMudx7IfSCduN/xhOjp207teYPLLC lZ5YbTNVT3/Sc/XybXKYWgyVjusU7m7S3q1IYSQ7AwVouTbL83vz5lXEjKbnn8ZPHnNK6Z EqldDhNWCTDDLnYqrguZpv4CUUPuixlrhUo5dNoNCl2Ph00HDRh+2Epz1+Xy+z5gkNEiY0 5W+i1W+BrMFeB15wfzmspgZ7kxdplbrCFu5Vi5O94pHgNFTADv4FynNAc4jyxMBUZR5hrS e5Ipp6Ag7aPWGvNCzOUm82u6oAaqdrbN3v+8LurpqRQ+bj4bI43aA70pxcJ7fw== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.71 X-Spam-Score: -4.71 X-Migadu-Queue-Id: 58B6E1A05 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qZMEjYTd; 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"; dmarc=pass (policy=none) header.from=posteo.net X-TUID: FSVFFVqJf4nS 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 org-ansi-mode) > + (remove-text-properties (point-min) (point-max) '(fontified t)) > + (font-lock-ensure)) Just use `org-restart-font-lock'. > + (t > + (dolist (ov (overlays-in (point-min) (point-max))) > + ;; Attempt to find ANSI specific overlays. See > + ;; `ansi-color-make-extent'. > + (when (eq (car-safe (overlay-get ov 'insert-behind-hooks)) > + 'ansi-color-freeze-overlay) This is extremely awkward and relies on internal implementation details of ansi-color. Moreover, we must avoid overlays, if possible - they do not scale well. I recommend re-defining `ansi-color-apply-face-function' to something that uses text properties. Using text properties will also make restarting font-lock sufficient to clear the fontification. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at