X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.1 required=5.0	tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS
X-Spam-Check-By: sourceware.org
To: cygwin AT cygwin DOT com
From: Enrico Forestieri <forenr AT lyx DOT org>
Subject: Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Date: Thu, 8 Dec 2011 12:37:32 +0000 (UTC)
Lines: 32
Message-ID: <loom.20111208T123943-226@post.gmane.org>
References: <announce DOT 20111206093746 DOT GA6222 AT calimero DOT vinschen DOT de> <566vd7hfmi3j980ic4m64d7bv91b5qm6uh AT 4ax DOT com> <20111207173808 DOT GA25743 AT calimero DOT vinschen DOT de> <lq9vd7hue8mef2rkdjpnljn12bm0r6ftum AT 4ax DOT com> <20111207180653 DOT GB25743 AT calimero DOT vinschen DOT de> <loom DOT 20111208T012903-910 AT post DOT gmane DOT org> <20111208083935 DOT GC6602 AT calimero DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Corinna Vinschen writes:
> 
> Which raises the question why the Cygwin version of lyx uses
> cygwin_conv_path at all.  Does it call Windows functions with the paths?
> If so, why?  If not, why are the paths converted to Windows?

Because the user *could* enter Windows paths (e.g., for including images)
or a document created with a native Windows version could be opened with
the Cygwin version. The Cygwin version of lyx works internally with
posix paths, which are to be converted from the native Windows form.

Then, there is a case where the posix->windows conversion is needed.
Indeed, lyx allows to use either a Cygwin or native-Windows TeX engine.
There is a configuration check for this case. If a native-Windows TeX
engine is detected, all paths going to latex files should be converted
to Windows, otherwise the TeX engine would not understand them.

This is symmetric, i.e., if you compile a native Windows version of lyx
and use a Cygwin TeX engine, all paths going to latex files gets converted
to posix form. But this case is not of interest here, of course.

However, I experimented a bit with the last snapshot, and even using Greek
or Japanese characters in file names, lyx seems to be working fine. In part,
this may be due to the fact that, for compiling a latex file, all needed
ancillary files are copied to a temporary directory with their names
mangled such that only pure ascii characters are used. Anyway, when
converting from/to Windows, lyx assumes that cygwin_conv_path does not
play tricks with the encoding. It was so until now. If this changes, I
think it is bound to fail in some way.

-- 
Enrico


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple