GNU bug report logs - #45898
27.1; wedged in redisplay again

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Phil Sainty <psainty <at> orcon.net.nz>, Emacs-hacker2018 <at> jovi.net,
 45898 <at> debbugs.gnu.org
Subject: Re: bug#45898: 27.1; wedged in redisplay again
Date: Tue, 14 Jun 2022 14:00:53 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Yes.  That idea came up while discussing this with Gerd Möllmann, btw.
> It's much simpler than measuring time (which would require
> high-resolution timing, which is much less portable and more tricky to
> get right, what with modern systems constantly adjusting their time).

I don't think we need high resolution time here?  We just need to
(coarsely) have an opinion about whether we've been spending a lot of
time...

> That's why update_redisplay_ticks accepts its first argument, instead
> of always adding 1: I thought about some potentially expensive
> operations that could be either more or less expensive than just
> processing a single character.  E.g., font-lock calls regexp matching,
> so we should try to come up with some measure of its "expensiveness"
> based on...something.  This will need some tuning, but all we need is
> some coarse correlation.

Yes.  I do wonder, though, whether there's going to be possible to come
up with useful tuning here -- predicting whether a regexp is "heavy" is
non trivial, to say the least.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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