[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: David Kastrup
Subject: [AUCTeX-devel] Re: preview-latex 0.9.1 and AUCTeX 11.whatever
Date: Thu, 31 Mar 2005 16:46:54 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Jan-Åke Larsson <address@hidden> writes:

> David Kastrup wrote:
>> Ah, that's the advantage of being project leader.  Unless
>> developers threaten to abandon ship because of it, I have nothing
>> to fear. Honestly, if you have a better idea of how to achieve
>> this, feel free to do so.  It is apparent that I am getting fond of
>> achieving stuff with EMACS_LISP.
> 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.

>> Uh, transferring information from configure to EMACS_LISP works
>> just fine.  That's what the $4 and $5 arguments are for, and they
>> do the trick, including terrifying quoting characters and spaces.
> Well, yes. What I am mainly concerned about is the readability of
> the code.

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.

>> The LISPIFY stuff is for transferring directory specifications _out_
>> again, and in a form appropriate for substituting into *.el files.
> Hmmmm. How about a "configure.el", to be used for the auto.el
> (tex-site.el) generation? We would gain a configure.el file but it would
> simplify aclocal.m4 considerably. Loading, exchanging @foo@
> for some string and writing auto.el is simple in elisp. Calling it would
> be simply '${EMACS} -batch -l configure.el' and input can be handled via
> (getenv "foo").
> We could actually be able to do all the emacs-related test in one emacs
> run, print configure-style messages on stdout, and write output to auto.el
> as well as into a file on the form
> ---------------
> foo="bar baz"
> export foo
> ---------------
> to be sourced by the configure script which would set the related variables
> in configure, later to be written into Makefile.
> Problem is, this change would take somewhat <cough> longer than
> you'd like right now, no?

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.

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.

That's all.

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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