preloading newcomment.el

preloading newcomment.el

[Stefan Monnier]

Is there any objection to dumping Emacs with newcomment.el (rather
than autoload it) ?

The reason for dumping it is that most of the functions in it
are autoloaded and there's regularly the need to autoload another.
Also because it has to get loaded as soon as someone uses M-; or
auto-filling (in non-text-modes) and because the corresponding
functionality used to be in simple.el.


	Stefan

Re: preloading newcomment.el

[Richard Stallman]

    Is there any objection to dumping Emacs with newcomment.el (rather
    than autoload it) ?

How much size does it add?

    Also because it has to get loaded as soon as someone uses M-; or
    auto-filling (in non-text-modes)

A large fraction of users will never use those modes.

Re: preloading newcomment.el

[Stefan Monnier]

>     Is there any objection to dumping Emacs with newcomment.el (rather
>     than autoload it) ?
> How much size does it add?

It adds 16388 bytes of pure storage if byte-compiled normally
and 3632 if byte-compile-dynamic is used.


	Stefan

Re: preloading newcomment.el

[Richard Stallman]

    It adds 16388 bytes of pure storage if byte-compiled normally
    and 3632 if byte-compile-dynamic is used.

What do you think then of preloading it but using byte-compile-dynamic?

Re: preloading newcomment.el

[Stefan Monnier]

>     It adds 16388 bytes of pure storage if byte-compiled normally
>     and 3632 if byte-compile-dynamic is used.
> 
> What do you think then of preloading it but using byte-compile-dynamic?

It turns out that it doesn't work: byte-compile-dynamic doesn't work
for preloaded files (because the external reference to the code
is read in as 0 (assuming that it is a docstring reference and
will be filled in by Snarf-documentation).
The problem is "fixed" by the patch below, but it's not
a satisfactory fix (it increases the amount of pure storage used)
and I have no idea how to really fix things.


	Stefan


Index: src/lread.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/lread.c,v
retrieving revision 1.301
diff -u -r1.301 lread.c
--- src/lread.c	30 Oct 2002 19:15:17 -0000	1.301
+++ src/lread.c	4 Nov 2002 14:44:09 -0000
@@ -2844,7 +2844,7 @@
 	       this file is described in the DOC-MM.NN file
 	       and Snarf-documentation will fill in the right value later.
 	       For now, replace the whole list with 0.  */
-	    doc_reference = 1;
+	    doc_reference = 0;
 	  else
 	    /* We have already called Snarf-documentation, so make a relative
 	       file name for this file, so it can be found properly

Re: preloading newcomment.el

[Richard Stallman]

    The problem is "fixed" by the patch below, but it's not
    a satisfactory fix (it increases the amount of pure storage used)
    and I have no idea how to really fix things.

To fix it properly requires distinguishing between #$ when it's used
to refer to a doc string and #$ when it's used to refer to the byte
code.  One way to distinguish would be based on position in the
surrounding list.

But I think there's no need to do this now.  The right thing to do now
is just not preload the file.

Preloading newcomment.el

[Stefan Monnier]

Any objection to preloading newcomment.el (see bug#10868 for the
current motivation)?


        Stefan

Re: Preloading newcomment.el

[Glenn Morris]

Stefan Monnier wrote:

> Any objection to preloading newcomment.el (see bug#10868 for the
> current motivation)?

Sounds good for 24.2.

Re: Preloading newcomment.el

[Stefan Monnier]

>> Any objection to preloading newcomment.el (see bug#10868 for the
>> current motivation)?
> Sounds good for 24.2.

Yes, thanks for clarifying, of course I didn't mean to do that for 24.1.


        Stefan