Subject: Re: bug#45380: 28.0.50; Error in coloured output in Emacs 28.05(AUR package: emacs-git)

From: Morgan Smith <[email-masked]>
Date: Sun, 24 Oct 2021 20:44:24 -0400

Hey all,

I spent a good chunk of time debugging this but I'm pretty new to emacs devel so please let me know if I say anything funny.

How to reproduce: Just keep trying some long running colored commands in eshell like "git log --color". Eventually the logic will get messed up and it'll look like the previously posted screenshot. I've seen this bugs hundred of times from all sorts of different external commands. As long as the command has enough output it's not a question of "if" but "when" will the bug show.

I think the issue is in eshell-output-filter.  Specifically I think the issue is with how it sets the eshell-last-output-start and eshell-last-input-end markers.

If we add some advice around our coloring function we can see that the coloring regions "overlap".  I assume this overlap is because coloring the region is removing the control characters and making the region smaller.  I don't think this is actually an issue, it's just something that smells like it could create bugs.

;; How to see the marker values
(defun where-are-markers (marker1 marker2)
(message "%s and %s" marker1 marker2))
(advice-add 'ansi-color-apply-on-region :before 'where-are-markers)

Thankfully, we can test out what would happen if we colored each bit of output as it comes in without worrying about regions. All we have to do is run this first:

(delete 'eshell-handle-ansi-color eshell-output-filter-functions)
(add-to-list 'eshell-preoutput-filter-functions 'ansi-color-apply)

And voila! Problem gone! Also I feel like this might run faster then the current method of filtering but I might be wrong about that.

So in conclusion: I found a workaround that might be more performant then the current coloring method but also doesn't actually fix the bug so we should probably dig deeper.

Morgan