all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Noam Postavsky <npostavs@users.sourceforge.net>
To: Pierre Neidhardt <ambrevar@gmail.com>
Cc: 29854@debbugs.gnu.org
Subject: bug#29854: 25.3; Eshell buffer editing gets slower as colored output grows
Date: Tue, 02 Jan 2018 08:50:51 -0500	[thread overview]
Message-ID: <87r2r8s72c.fsf@users.sourceforge.net> (raw)
In-Reply-To: <CAASvgtq+Gan6JGcGdBab=gHgJashamJ5i+iiDrk9v2sXxLUWqA@mail.gmail.com> (Pierre Neidhardt's message of "Tue, 2 Jan 2018 13:40:00 +0100")

Pierre Neidhardt <ambrevar@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))))






  reply	other threads:[~2018-01-02 13:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-26 10:43 bug#29854: 25.3; Eshell buffer editing gets slower as colored output grows Pierre Neidhardt
2018-01-01  2:07 ` Noam Postavsky
2018-01-02 12:40   ` Pierre Neidhardt
2018-01-02 13:50     ` Noam Postavsky [this message]
2018-01-03 11:46       ` Pierre Neidhardt
2018-01-03 13:33         ` Noam Postavsky
2019-05-04 19:49           ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r2r8s72c.fsf@users.sourceforge.net \
    --to=npostavs@users.sourceforge.net \
    --cc=29854@debbugs.gnu.org \
    --cc=ambrevar@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.