[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: Mon, 19 Dec 2005 12:23:37 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

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

> However, I cannot accept your patch as it stands.  First, you missed
> the important WARNING in the comment just preceding the commands you
> wanted to patch,

Oh great, then I'll probably have to do another upload to
alpha.gnu.org.  At least because of the usage of $(lisp).  But I'll
have to check how bad the consequences of missing autoloads are when
relocating the Emacs installation directory.  Thanks for the hint.

> and thus your modified command lines will break with
> make 3.81 (which is about to be released) and later, due to the
> incompatible change in its behavior regarding backslash-newline
> sequences.

You mean the changes you described in the patch to make.texi in

In what way is this a problem.  For example it does not make a
difference if I pass

emacs -eval "(message \


emacs -eval "(message \"foo\")"

to the Bash 3.1.0 on my Debian system directly from a terminal.

Is this relevant for Windows systems only?  Does it mean that portable
Makefile files all have to put their `emacs -eval ...' stuff into a
single line?  I am not sure about the conditions because the comment
in lisp/makefile.w32-in mentions $(ARGQUOTE) and the patch in the
email references above is mangled and reads

[...]However, note that
+backslash-newline sequences inside command-line arguments quoted with
address@hidden'...'} are not removed by the shell.[...]

> Is there any reasonable chance that MSYS maintainers will fix this?
> Could you check with them, or maybe try their latest snapshot of
> ported Bash and see if the problem went away?

I reported the issue back in July, see
So they are aware of it but I don't know if this is fixed yet.  I've
been waiting for ages for a new release of MSYS.  IIRC I checked a
beta version of Bash 2.05 for MSYS back in July which did not solve
the problem.  Unfortunately I cannot find that beta on their download
page anymore for testing.  And the last beta of MSYS itself is from
April 2004.

> If they don't intend to fix that any time soon, we will need to find a
> much simpler solution, one for which we could know with high
> probability that it will not break anything else.  I'll give it a
> thought while you talk to the MSYS people.

Well, I am. (c:


reply via email to

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