GNU bug report logs - #29854
25.3; Eshell buffer editing gets slower as colored output grows

Previous Next

Full log

Message #14 received at 29854 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: Pierre Neidhardt <ambrevar <at> gmail.com>
Cc: 29854 <at> debbugs.gnu.org
Subject: Re: bug#29854: 25.3;
 Eshell buffer editing gets slower as colored output grows
Date: Tue, 02 Jan 2018 08:50:51 -0500

Pierre Neidhardt <ambrevar <at> gmail.com> writes:

> The patch does not seem to do it.  Unless load order matters?

Load order should not matter.

> The redifinition of `ansi-color-apply-face-function` works however,
> plus it comes at the bonus of making Eshell an order of magnitude
> faster!
> I haven't tested estensively yet, but it seems to be a much better
> default.

Aha, maybe it's not a question of markers, but rather another case of
Bug#26051 "overlays may make emacs very slow".

(anyway, ansi-color-apply-to-region doesn't set markers per colour
boundary; it's just 1 or 2 markers per call (eshell calls it once per
~4096 bytes))

The question is then whether there is some case where using overlays is
necessary, or is it just a pessimization?  For reference, I took the
text property using definition from man.el (so it at least works for
that case):

    (defun Man-fontify-manpage ()
      [...]
      (let ((ansi-color-apply-face-function
             (lambda (beg end face)
               (when face
                 (put-text-property beg end 'face face))))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.