all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Ralf Angeli <angeli@iwi.uni-sb.de>
Cc: emacs-devel@gnu.org
Subject: Re: `make' written in elisp
Date: Tue, 04 Jan 2005 12:17:18 +0100	[thread overview]
Message-ID: <E1Clmgg-000389-Km@neutrino.iwi.uni-sb.de> (raw)
In-Reply-To: <E1ClfWa-0007tC-Ff@fencepost.gnu.org> (Richard Stallman's message of "Mon, 03 Jan 2005 22:38:24 -0500")

* 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
procedure.

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

-- 
Ralf

  reply	other threads:[~2005-01-04 11:17 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-30 19:31 `make' written in elisp Michael Schierl
2003-12-31 22:57 ` Richard Stallman
2003-12-31 23:14   ` Michael Schierl
2004-01-01 21:10     ` Richard Stallman
2004-01-01 21:37       ` Michael Schierl
2004-01-04 23:25 ` Stefan Monnier
2005-01-02 16:06   ` Richard Stallman
2005-01-02 23:22     ` David Kastrup
2005-01-02 23:55       ` Ralf Angeli
2005-01-03  0:07         ` David Kastrup
2005-01-03  0:25           ` Ralf Angeli
2005-01-03  4:32             ` Richard Stallman
2005-01-03  8:02               ` David Kastrup
2005-01-03  9:36                 ` Eli Zaretskii
2005-01-03 16:45                   ` Stefan Monnier
2005-01-03  9:10               ` Ralf Angeli
2005-01-03 18:29                 ` Richard Stallman
2005-01-03 19:28                   ` Ralf Angeli
2005-01-03 23:10                     ` David Kastrup
2005-01-04  3:38                     ` Richard Stallman
2005-01-04 11:17                       ` Ralf Angeli [this message]
2005-01-03  0:26       ` Stefan
2005-01-03 11:05         ` Stephen J. Turnbull
2005-01-03 17:16           ` Stefan Monnier
2005-01-04 12:00             ` Stephen J. Turnbull
2005-01-04 13:59               ` Stefan
2005-01-04 14:07                 ` Miles Bader
2004-03-31 22:31 ` patch for locate-file-completion? Nic Ferrier
2004-04-01 17:34   ` Richard Stallman
     [not found] <E1CloEh-0004Sl-Hg@monty-python.gnu.org>
2005-01-04 16:10 ` `make' written in elisp Eric M. Ludlam

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=E1Clmgg-000389-Km@neutrino.iwi.uni-sb.de \
    --to=angeli@iwi.uni-sb.de \
    --cc=emacs-devel@gnu.org \
    /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.