[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: `make' written in elisp

From: Ralf Angeli
Subject: Re: `make' written in elisp
Date: Tue, 04 Jan 2005 12:17:18 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

* Richard Stallman (2005-01-04) writes:

> I am surprised to hear that.  Many Emacs Lisp packages search for
> files they need to use, and they generally do so either when first
> loaded into a session, or each time they are executed.  We have never
> tried to make any of them save the results between sessions, but it
> seems to be fast enough.
> Is AUCTeX doing something that is particularly slow?

That depends on how you define slow.  I just extracted the relevant
code for testing purposes and using `time' with the resulting shell
script I got the following execution times on a Pentium M 1,7
(currently running at 600MHz):

  real    0m0.114s
  user    0m0.084s
  sys     0m0.018s

In the meantime I reimplemented the functionality in Elisp.  Using

  (abs (- (prog1 (float-time (current-time)) (TeX-input-dirs))
          (float-time (current-time))))

for measuring the execution time I got an average of about 0.06
seconds for executing the function `TeX-input-dirs'.  While I am not
really fond of having the function executed every time the package is
loaded, it is probably an acceptable delay.  And, as David already
mentioned, we could find ways to save its output and subsequently
inhibit its execution until a user calls some reconfiguration

>     Besides writing values to init files the configuration process is used
>     to check if external tools required for building or running the
>     package are present and provide necessary features.  A special case
>     might be preview-latex which has a TeX part besides the Elisp part.
> Why is it necessary to do this?
> It seems to me that it would be just fine
> to look for these things when the user tries to use them.
> to try to use the command when the user asks to do

I don't think it is feasible to check for program versions every time
a program is called.  And instead of letting the user alone with error
messages which don't give him a hint that the program is too old, I
consider it better practice to tell him when he tries to install the
software which relies on the external program.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]