Stephen Harris <[EMAIL PROTECTED]> writes: > The native versions of Lyx for 137 and 140 appear to conflict up in > C:\Documents and Settings\UserName\Application Data\LyX where > preferences are stored. There is no conflict with native WinLyX and > CygLyX because CygLyx has its preferences stored down in C:\Cygwin.
Stephen, coexistence of both 1.3.7 and 1.4.0 on Windows is easier than on Linux because the only conflict is the userdir. You can solve this only problem simply renaming the 1.4.0 userdir as C:\Documents and Settings\UserName\Application Data\LyX140 and then adding the following switch to your shortcuts or .bat files invoking LyX 1.4.0: -userdir "C:\Documents and Settings\UserName\Application Data\LyX140" doing so, LyX will look there for its files. Try issuing the following command from a terminal: "C:\Program files\LyX-1.4.0\bin\lyx.exe" -userdir C:/MyLyX140dir and you will see that LyX will even create C:/MyLyX140dir if it does not exists, autoreconfiguring itself. > But I am using all Windows native programs. Maybe there would be > an insurmountable conflict if both the Win and Cygwin versions of > ImageMagick were used for instance. But I think maybe Enrico has > this working (unless he is using all Cygwin helper apps ) The native LyX version can be used with all Cygwin apps. Whatever you can do with a native app you can do the same and more with a Cygwin one. For example, Cygwin apps understand both native and posix syntax for paths. With a Cygwin app you can indifferently use C:\aspell\lib or C:/aspell/lib or /cygdrive/c/aspell/lib or even C:\aspell/lib (note the mixup of \ and /). The only problem I face is when a Cygwin app is a symlink to a real binary program, as in this case native (and even MSYS) apps do not understand symlinks. The solution in this case is really simple: create a .bat script with the same name which simply calls the real binary program. -- Enrico
