GNU bug report logs - #19776
25.0.50; HTML rendering is very slow

Previous Next

Full log

View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: stefan <at> marxist.se, rms <at> gnu.org, 19776 <at> debbugs.gnu.org
Subject: bug#19776: 25.0.50; HTML rendering is very slow
Date: Sun, 24 Oct 2021 18:22:27 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> I'll have a crack at implementing this and see how it goes...

I've now implemented the special form, and it works fine interpreted.
But I'm having problems with the byte compilation.

So I've done a

(byte-defop-compiler-1 with-delayed-message)

and I think I understand that it wants to

  (byte-compile-form (nth 1 form))
  (byte-compile-form (nth 2 form))
  (byte-compile-body-do-effect (cdr (cdr (cdr form))))

But this would be the first special form that doesn't have a byte op
code, probably?  Is that allowed?  I couldn't find any other examples of
that being a thing.

I may well be missing something.

But if that's the case, and we don't want to use a byte op for this,
then we'd have to make the special form into a normal macro, and then
create two helper functions (to start and stop the atimer in
question)...  which is perhaps others have done kinda similar things
this way before.

But that's kinda meh.  Am I missing something, and it's easy to write
the byte-compile-with-delayed-message function without a byte op?  Or
should we use a byte op?

-- 
(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.