[Top][All Lists]

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

Re: [AUCTeX-devel] RE: [AUCTeX] Install report: XEmacs and Windows XP

From: David Kastrup
Subject: Re: [AUCTeX-devel] RE: [AUCTeX] Install report: XEmacs and Windows XP
Date: Tue, 24 May 2005 13:21:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

"Michael Forster" <address@hidden> writes:

> David wrote:
>> I think that your Perl does not recognize Windows line endings in 
>> ASCII mode correctly (those should be read _only_ as \n).
>> >> Well, looks like \n is not a single character on Windows.  Does the
>> >> following patch help?
>> >
>> > No improvement. 
>> Yeah, I was confused from the manual pages.  Seems like \n is a single
>> character after all even on Windows
> How about checking against $  ?

Problem is that we read _and_ write line endings.  If we don't want to
get any mixed line endings, we have to figure out and remember the
complete line ending before we start writing anything out, or the
result will also be a mixture of line endings.

Since makeinfo also seems to be confused about... Wait: this can be
because preview-ltxdoc.texi would probably have _mixed_ line endings.

So maybe our entire line ending problem can be traced to Perl.

Could you try this with a DOS line-ended checkout and use a
preview-ltxdoc.texi that you have manually converted to DOS line
endings from the pure Unix line ending form?  Does this work with your
makeinfo without formatting problems?

If it does: Do you have the means to figure out what would need
changing in the Perl script?

>> [...] Replacing the whole AC_OUTPUT_SUBDIRS by a fixed copy in
>> aclocal.m4 would require that it does not use any non-dependable
>> internals.
>> I really have no good idea what to do about all of this.
> Actually, this is not really a problem. This directory change is
> pretty much the last thing configure does and it not even gives a
> fatal error message. It's more like a warning and installation works
> anyways.

Ok, if it is not fatal.  It is not the last thing configure does as
afterwards the substitutions into the output files occur, and it would
definitely be painful if those occured in a different directory.

But you would have noticed _that_ I guess.  Still, seems like
something worth reporting to the autoconf maintainers.

>> > The error goes away if I comment out the 
>> >
>> >
>> > in preview/ TEX is quotified two times, once in each
>> >
>> Oh good grief, it is actually passed as a variable into the
>> subordinate configure?  In that case, _much_ more can be expected
>> to go haywire.
>> Seems like I should take a thorough look at what AC_OUTPUT_SUBDIRS
>> does.  Maybe we really need to replace it with our own code
>> completely.
> I really think the problem is AC_SHELL_QUOTIFY. Using this, too much
> quotification is inserted into variables. At the next unquoted
> (=incorrect) use this goes away again, but quoted (=correct) use
> does not work any more.

Well, I still wonder why and how this gets exported, but I have now
moved the recursion in before the AC_SHELL_QUOTIFY block,
and this should pretty much solve the problem, I think.

Could you check this?

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

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