From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id +J0YH3VGiWY0AgAAqHPOHw:P1 (envelope-from ) for ; Sat, 06 Jul 2024 13:28:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id +J0YH3VGiWY0AgAAqHPOHw (envelope-from ) for ; Sat, 06 Jul 2024 15:28:21 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=KV1J6KMY; 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=1720272501; 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=Rr2vbGE2b4XbIQsOGjpCltdQS4vroppqv09nPlBzfOs=; b=pVwBAu8oVRTxtKWG00/LFKoreZM9TUnqCJHK1MzQj8wJaOOo4p2BqO8zuy6O6yVwMpbmUH zEZHrCs01pAZJwXraWfFtsBG1EYsxVnFquC1m0TEa7pR2uR0sfTvkk9U50ohxnfsKo7LGy 0LkW3xzFBgXulZE0cbaWFkvZX9vaIx7Rn+K6yW0MUhvZE6ohdBg9nuerqmtbgNwZumWW9H 6G/Be/f/e+iSn7pwnxPVX0+P14hEZ4uABdMX4raz0Rg3g2riuFuF7t2epdFnjdN6YYEnlP gWWmx55COzSRrqOOZsUGSLVCVQvsdWeP+9JMyltNQMQZJ2YqSy8erEImaRYyBA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=KV1J6KMY; 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-Seal: i=1; s=key1; d=yhetil.org; t=1720272501; a=rsa-sha256; cv=none; b=Zi3g84omnNUBUjYfllU0huaciN/gMWQ3luUHkhwUiN6VjbuhcSSChllkPxEX6Wda88xLaK NIzeLqShfJMTZMPLDWevm0/G3Do2fHUrwvVUumbWLMMw6r4T/9S1nPtVTSvqL6hUHucdMm SqIKJNrPe9iS6EcqZY8pcKm1thDxYQQKLiF96h1lX7JIvts9BweA9EY08dQOFXe9+K6n54 LRNHNvqJVPLrXaC6ao7s29zjNItCPYR+Zvm1B0LpcusHT2yo5c+mNkkl2HfAkRojL9XSMY bHzwafppLQzfOzMkysnc4V9kO12bZAaRtst+XeZW8Pjbg617NsMroulhpR4fTQ== 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 361783CFB0 for ; Sat, 6 Jul 2024 15:28:21 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQ5Rf-0000WY-9w; Sat, 06 Jul 2024 09:27:19 -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 1sQ5Rc-0000W5-8F for emacs-orgmode@gnu.org; Sat, 06 Jul 2024 09:27:16 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQ5RV-0003HE-DA for emacs-orgmode@gnu.org; Sat, 06 Jul 2024 09:27:15 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C58B6240103 for ; Sat, 6 Jul 2024 15:27:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720272426; bh=3pQJIVZpQ2SyZ2+h2msmN0z3MJNyxDqz9FLB2LrdT1k=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=KV1J6KMYp2b+RvOZmPQLSnn4pNBMhZe8PTSOmDAbFf9vidYIUCrxa99QbLY8WTa2P N9X6Sa0VRkyC1wZytQw6Fm5nLZ+mL7BqTMmdgUAPc1pY/uO6dU8YRTqT5pOsyRMEj7 oAIJ+3Ohz7xIKVDFdhCxLvNkXtnpG5ZT18WJyDGPIaUXZAMduujEcRHEpG+7fKZGe0 tUVyHrlYf71PJSbHtYYf/2+ydNY3z/QwoldCFVtmKa6AnXTqEEjQZh2ylhLsSBxxfv iIhu+uP/NbL8CWL/GkKPpWlLaaLTwWVqqpQbWrlBGA+ECOk25FwSX8ITEeE+8guF+h eYPMYFi3VhwmA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WGWQ15xKBz9rxG; Sat, 6 Jul 2024 15:27:05 +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: <87wmm5yn1m.fsf@gmail.com> 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> <87msvcgjgv.fsf@gmail.com> <87le9wq2dg.fsf@localhost> <8734uwhlhj.fsf@gmail.com> <875xzsjfvo.fsf@localhost> <87plvhf5gf.fsf@gmail.com> <87msqid9gi.fsf@localhost> <87bk3kuj20.fsf@localhost> <87wmm5yn1m.fsf@gmail.com> Date: Sat, 06 Jul 2024 13:28:41 +0000 Message-ID: <87jzhy8x9y.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.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_H3=0.001, RCVD_IN_MSPIKE_WL=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 X-Migadu-Queue-Id: 361783CFB0 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Spam-Score: -9.61 X-Spam-Score: -9.61 X-TUID: FVb09NAaFiLA Nathaniel Nicandro writes: >> Nathaniel, may I know if you are still working on this? > > Hello Ihor, > > Yes I'm still working on this. Attached is an updated patch with some > tests this time. It's still a work in progress. Below are responses to > your previous comments about my last update and some comments about this > current patch. Thanks for the update! And for the resilience working on this difficult patch :) >> This is very fragile. >> I believe that hooking into `org-fold-check-before-invisible-edit' >> would lead to simpler implementation. > > Thank you for the feedback. I indeed was able to come up with a > more simpler solution by hooking into that function. > > To integrate with `org-fold-check-before-invisible-edit' I had to > introduce two variables, `org-fold-visibility-detail' which is set to > the argument of `org-fold-show-set-visibility' when that function is > called and `org-ansi-fontify-begin' to determine the start of the > fontification region to see if it's close to the beginning of an > invisible sequence that should be turned visible. > > Let me know if this is an OK approach. I do not like the idea of introducing extra global state variables. What about let-binding `org-ansi-hide-sequences' in (let (org-hide-emphasis-markers ... (region (or (org-find-text-property-region (point) 'org-emphasis) ...))) ... (when region (org-with-point-at (car region) (forward-line 0) (let (font-lock-extend-region-functions) (font-lock-fontify-region (max (point-min) (1- (car region))) (cdr region)))))) > I ran into an issue when trying to hook into > `org-fold-check-before-invisible-edit' in that when it revealed a > sequence at the end of a line, there would be an extra fontification > cycle that would occur after the reveal which would cause the sequence > to be re-hidden again. To counteract this I had to use > `buffer-chars-modified-tick' in the way I do. I couldn't figure out > why redisplay was causing that extra fontification cycle when there > were no modifications to the buffer. Redisplay is a bit tricky in `org-fold-show-set-visibility' (see "FIXME" comment). Let's leave it be for now, until the patch gets closer to its final state. Just add a "FIXME:" comment somewhere near the relevant code, so that we do not forget about this issue. > With this patch, editing around sequences should be more stable and > non-surprising. Basically if a sequence is invisible around point and > you edit it, the sequence remains visible. It is only after the first > edit outside of a sequence that should make the sequence invisible. > Whenever a sequence is being edited, it should always be visible and > not turn invisible while in the middle of editing it, e.g. due to an > invalid sequence turning valid. We actually discussed a similar problem with links recently: https://list.orgmode.org/orgmode/20240428093320.120843ae@enoush2o/ The general conclusion we came to was that whatever smart behavior we may came up with will confuse users. Probably, the most predictable approach would be either doing the same thing as what https://github.com/awth13/org-appear or some variant of it that also does not rely on fiddling with redisplay and/or fontification. Even what we do in `org-fold-show-set-visibility' is sometimes confusing to the users. TL;DR: Do not worry about this problem - it should be solved in more general context, for the whole Org. > Some comments about the patch, as it currently stands, follow. > > - I've introduced two text properties `org-ansi' and > `org-ansi-context'. > > The first is placed on the regions that actually contain ANSI > sequences and holds information about the sequence that is useful to > keep around to detect when a sequence has been modified or deleted > between fontification cycles, as well as information about whether > or not a sequence should be revealed due to modifications or because > of visibility changes. Let's drop the part with modifications/visibility changes. It should not be a job for fontification function, so let's not complicate things (as I mentioned above). I believe that 'org-ansi may no longer be needed once we drop this. > ... > - The logic to use in `org-fontify-ansi-sequences' and how to maintain > the highlighting across edits in the buffer are my main focus at > this point. I think I've basically figured out the gist of the > logic, just need to clean it up. What I have not really considered > that much is how to maintain/remove the highlighting across edits, > e.g. when there is something like > > line1 > line2 > line3 > line4 > > all lines being highlighted by the sequence, and the paragraph is > split at line3 so it becomes > > line1 > line2 > > line3 > line4 > > the highlighting is removed from line3 but not line4. And there are > other situations where editing the buffer does not result in the > maintenance of the highlighting across the affected elements. I > think I had it working in more situations when I had also placed the > `font-lock-multiline' property on the highlighted regions, but I tried > to simplify things by just using the `org-ansi-context' property > which may be able to handle these kinds of situations also somehow, > by detecting these kinds of edits and extending the region to > account for them. I believe that `font-lock-extend-region-functions' should be able to tackle this situation. Is there any problem with it? (The rest of logic sounds reasonable, although I did not yet dive into the code) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at