Enrico Forestieri wrote: > In Windows one could use miktex or tetex (by cygwin). But, as things > stand now, tetex cannot be used because, for reasons not known to me, > it gives an error when a path like "C:/xxx" is output to a .tex file. > I think that it is related to the fact that a check for a posix-style > absolute path is being made, but I have not read the tetex sources and > cannot be sure. > > I think that in Windows all files output to a .tex file should be > obtained by os::latex_file() which, according to the cygwin_path_fix > switch, should return either "C:/xxx" or "/cygdrive/c/xxx".
Agreed. > So, three functions are needed: > > 1) os::internal_path for paths used internally by LyX > 2) os::external_path for paths intended to be used by external > programs > 3) os::latex_path for paths going to .tex files > > In *nix all of them are noops. In native win32 1) and 2) simply differ > in the path separator, whereas 3) should give either pseudo-win paths > or posix paths according to wheter miktex or tetex is used (this is > what cygwin_path_fix tells you). Agreed. > In cygwin, things could be exactly as in *nix, but if you want to allow > for miktex, than 3) above should be exactly as for native win32 (as it > should be, I mean, not as it is now). Agreed. > 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. Not agreed. os::internal_path should always create posix-style paths. Why would we want other paths internally? If you think about presentation of paths to the user, then I would rather invent a new function display_path(), otherwise we mixup things. One could argue what os::external_path should do. In fact I am not really sure how to handle this on cygwin. > As a cygwin app can deal with both posix or win-style paths, we could > simply ditch the "Use Cygwin-style paths" checkbox and make 1) and 2) > always return pseudo win-style paths (I mean with forward slashes > because it seems that most windows programs understand that, even > notepad and word have no problems with forward slahes). But chances are > high that if you have cygwin, you also use all-cygwin apps, and if one > of them tries to be smart about deciding that a path is absolute or not, > you are in trouble, because you suddenly find that the current dir path > is prepended to your already absolute path. > > For this reason I think that the checkbox should stay. The checkbox does not really solve the fundamental problem: On cygwin, we don't know which of the external programs needs a cygwin style path, and which one needs a native windows path. rather than the checkbox I would like to have a more general mechanism, for example a wrapper script that is invoked instead of an external program and that can translate the paths. The configure script could then write the corresponding entries in lyxrc.default. > One input source from which a path is entered is the file dialog, > so I simply pass its output to os::internal_path which returns a path > in the style dictated by the "Use Cygwin-style paths" checkbox. > > This is the logic driving my patch and I am sure that it can be > implemented in a better way than I did, but I don't want to be > one which simply asks for something and I think it is helpful to start > from an almost working implementation rather than from scratch. > > If you do not agree with this vision, I am fine anyway. I do not want > to make a pressure on you as I have the sources and can build my own > version of LyX. As you can see I agree with a lot of it, but not all. See next mail. > However, the cygwin version that I made available is the one I am using, > so if my copy is different from the official sources and this is not > acceptable for you, I will not provide other versions if you ask so, as > I don't want that you get blamed for it. I personally am fine as long as it is clearly labelld as a modified version. > Anyway, I would like to thank you for LyX which I am using from version > 0.10 (I think I still have the COLD program lying on the hard disk). That was far earlier than me. I once did a math homework with klyx, but did not really understand how it worked, then used LaTeX for some years and was reintroduced to LyX (then at version 1.1.6fix_something) by a former colleague. Georg
