[Top][All Lists]

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

Re: loaddefs.el on Windows incomplete

From: Ralf Angeli
Subject: Re: loaddefs.el on Windows incomplete
Date: Tue, 20 Dec 2005 00:36:46 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

* Eli Zaretskii (2005-12-19) writes:

>> From: Ralf Angeli <address@hidden>
>> Oh great, then I'll probably have to do another upload to
>> alpha.gnu.org.
> Sorry, I'm confused: what upload to alpha.gnu?  What did you upload
> there, and how is this discussion relevant to whatever you uploaded?

Sorry for the confusion.  I am talking about a precompiled CVS Emacs
for Windows bundled with AUCTeX.

>> In what way is this a problem.  For example it does not make a
>> difference if I pass
>> to the Bash 3.1.0 on my Debian system directly from a terminal.
> Inside double quotes, it indeed will not make any difference, because
> the shell removes the backslashes inside double quotes.  But in single
> quotes, the shell will not remove the backslashes, so they will wind
> up inside the Emacs Lisp reader, and will utterly confuse it.  Note
> that, when the shell is sh.exe, lisp/makefile.w32-in uses single
> quotes to quote the --eval argument in the command you wanted to
> patch.
>> Is this relevant for Windows systems only?
> No, it is relevant to GNU Make on any platform which uses a Posix
> shell (and thus on Windows when the shell is sh.exe).

Oh, then I guess we'll have to change AUCTeX's Makefile files when
Make 3.81 will be released.  It's a pity that this change in Make will
have a negative effect on readability of affected Makefile files.

> However, in this specific case it is relevant only to Windows, since
> makefile.w32-in is used only by the MS-Windows build.

Obviously. (c:  I can provide an updated patch without the problematic
backslashes if there is interest in this.

>> Does it mean that portable Makefile files all have to put their
>> `emacs -eval ...' stuff into a single line?
> Not just `emacs --eval ...' stuff, but _any_ command parts that are
> quoted with single quotes cannot be split across multiple lines with
> backslash-newline sequences.

Okay.  Thanks for the clarification.

>> I am not sure about the conditions because the comment
>> in lisp/makefile.w32-in mentions $(ARGQUOTE)
> $(ARGQUOTE) expands to different kinds of quotes depending on the
> shell in use (see nt/nmake.defs and nt/gmake.defs); the problem
> happens when it expands to ', a single quote.  I didn't want to
> mention a single quote literally because it does not appear in the
> commands in question, so the reader might be left wandering what quote
> I was talking about.

You mean like me being confused about $(ARGQUOTE)? (c:  Maybe both
should be mentioned; $(ARGQUOTE) as reference to the code in concern
and a hint about single quotes being relevant in particular.


reply via email to

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