Nathaniel Nicandro <nathanielnican...@gmail.com> writes: > Feedback appreciated!
Thanks for the update! > I've finally implemented a solution to what I've discussed previously, > inserting zero width spaces as boundary characters after an ANSI > sequence to act as a separator from the text after the sequence. This > would handle the scenario where deleting into the end byte of a > sequence causes ansi-color to recognize the partially deleted sequence > plus the character directly after the end byte to be a new sequence. > This looked like the invisible region containing a sequence eating up > other characters not intended to be part of the region. > ... > So the implementation of that rule of maintaining a zero width space > after valid sequences and the rules around deleting into the space or > insertion in front of a space are the main changes in this patch > compared to previous versions. This is very fragile. I believe that hooking into `org-fold-check-before-invisible-edit' would lead to simpler implementation. I also do not like the idea that fontification code modifies the buffer. I tried your latest patch with test-ansi.org file you shared earlier: 1. Open the file and move to the end of the headline "Greater elements" 2. <backspace> <space> 3. Observe fontification extending past the title. I also edited it around in various places and I managed to trigger parser errors when the parser lost track of the modifications. This was presumably because your patch edited the buffer. I also observed strange glitches and hangs when I tried to surround an ANSI-colored region like =[42mtask 1[0m= and then edited near the boundaries. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
