On Fri, Mar 31, 2006 at 02:11:25PM +0200, Jean-Marc Lasgouttes wrote: > >>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > >> However, you could also use other native apps apart from miktex, so > >> it is useful that both 1) and 2) return either posix- or win-style > >> paths. This is to be independent from the cygwin_path_fix switch > >> and in my patch it is done through the "Use Cygwin-style paths" > >> checkbox. > > Georg> Not agreed. os::internal_path should always create posix-style > Georg> paths. Why would we want other paths internally? > > Definitely.
Note that for the win32 target os::internal_path returns pseudo-win style paths. Why it cannot be so also for cygwin? > Georg> If you think about presentation of paths to the user, then I > Georg> would rather invent a new function display_path(), otherwise we > Georg> mixup things. One could argue what os::external_path should do. > > external_path could have a second, optional, argument that would be an > enum describing what we want to do with the name (LATEX, DEFAULT, > whatever). No, sorry. external_path should not be related to latex. > Hmmm, I am not sure it is a good idea actually. > > Georg> The checkbox does not really solve the fundamental problem: On > Georg> cygwin, we don't know which of the external programs needs a > Georg> cygwin style path, and which one needs a native windows path. > Georg> rather than the checkbox I would like to have a more general > Georg> mechanism, for example a wrapper script that is invoked instead > Georg> of an external program and that can translate the paths. The > Georg> configure script could then write the corresponding entries in > Georg> lyxrc.default. > > For converters, we could use a flag to tell what kind of paths are > needed. Of course, if we use "convert" we do not know whether it is a > native or a cygwin version (do both exist?). Both exist, and the cygwin version has no problems with C:/xxx style paths, even if it is presented with eps:C:/xxx. > We could also have special forms of $i $o and friends asking for an > internal path. This is a cool idea, but I think that it is orthogonal to the question of what kind of paths internal_path and external_path should return. -- Enrico