[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
<URL:http://lists.gnu.org/archive/html/help-make/2005-12/msg00031.html>?
In what way is this a problem. For example it does not make a
difference if I pass
emacs -eval "(message \
\"foo\")"
or
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
<URL:http://thread.gmane.org/address@hidden>.
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:
--
Ralf