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