bug#50806: 27.2; [PATCH] Optimize ansi-color.el

[miha--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]

Jim Porter <jporterbugs@gmail.com> writes:

> I took a brief look at these and they seem reasonable to my eyes. It'll 
> be nice to have (mostly) complete support for reading ANSI colors in Emacs.
>
> Thinking about it a bit more, one thing that might be nice to add for
> the first patch would be some additional tests to be sure that
> `ansi-color-context-region' and `ansi-color-context' work as expected
> (i.e. testing that multiple calls to `ansi-color-apply-on-region' and
> similar produce the correct results). That's one of the trickier bits
> in ansi-color.el (to me, anyway), and it'd be good to be sure all the
> various cases still work there.
> [...]
>
Good idea. For testing my patches, I already made some private tests of
this nature (but only for ansi-color and not for term-mode). It should
be easy to polish them up for ansi-color-tests.el. Will probably send a
patch later.

>>> I see you posted an updated patch that doesn't merge these vectors. I
>>> don't have an opinion here, although if we do merge them, it would
>>> probably be nice to get that into Emacs 28; other packages might
>>> conceivably want to let-bind those[1].
>> 
>> Indeed, if we wanted to merge them we'd have to do it in Emacs 28.
>> That's why I think its best to simply leave them un-merged.
>
> If there's a performance benefit to merging them, I think it would be 
> nice to do so while we have the chance. Perhaps a patch that just merges 
> the two vectors, and nothing else, would make sense for Emacs 28. Best 
> to ask the maintainers in this case too, though.

The performance benefit I measured was negligible so I think it's fine
to just focus on Emacs 29.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]