[Top][All Lists]

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

[AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever

From: Jan-Åke Larsson
Subject: [AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever
Date: Thu, 31 Mar 2005 17:16:26 +0200
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; sv-SE; rv:1.7.5) Gecko/20041222

David Kastrup wrote:
Yes. Verily. You do know you are preventing just about anyone else
but you from contributing to the configure stuff?

I fail to see that.  EMACS_LISP has straightforward semantics.
Certainly _much_ easier than all of the shell scripting stuff that is
constantly causing incompatibilities with various Unix versions,
quoting problems, and so on.

This is not what I am talking about. I am referring to the addition
of several layers of complication needed to transfer things back and
forth from elisp to shell. I am not enthusiastic about maintaining

Where does it get unreadable?  [[woozle urg]],[["arg1" "arg2"]]
transfers the two command line strings arg1 and arg2 into Elisp
variables woozle and urg.  It does not get any more straightforward
than that.

It is not unreadable, but would be more readable if the code would
say (let* ((foo (getenv bar))....
instead of just referring to foo and then you find several lines
below what foo contains, hidden in a list of variable names
and another list of values.

Hmmmm. How about a "configure.el", to be used for the auto.el
(tex-site.el) generation?
It is also kind of pointless.  If we are doing all the stuff in Emacs
Lisp, anyway, we might as well do it at runtime and throw away all of
the configure stuff, leaving only a fixed Makefile.

You were asking for a simpler solution, and I suggested one.

Sure, finding executables should be done at runtime.

But configure sets the install directories. And configure.el would have
our configure options and default locations at hand, something which
would not be available runtime.

Granted, emacs can do all of the installation. But then this would
be a step in that direction. Besides, you are using EMACS_LISP all
the time anyway.

Yes, that's what has to happen in the long run, anyway, but the
current goal is just dealing with the current shortcomings.  0.9
already stopped installing into fancyful places mostly.  0.9.1 should
find the correct places more often, and also make a better decision
where multiple possibilities exist.

IMHO 0.9 was a step backward from 0.8.x. If you had asked me at the
time (or given some warning) I would have recommended we keep the
behaviour of 0.8.x until we had an elisp solution. It was not that bad.


reply via email to

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