On Sat, Apr 01, 2006 at 05:44:55PM +0200, Georg Baum wrote: > Am Samstag, 1. April 2006 16:37 schrieb Enrico Forestieri:
> > This is exactly what my patch does. I do not agree about the > > confusion. > > Here I meant confusion for programmers, not users. It simply does not make > sense to make the path format that is used internally by LyX > configurable. With "internally used by LyX" I mean the data in memory > during execution of the program. I don't mean the paths that are passed > to external programs or entered by the user in a file dialog. LyX has no problems with either C:/xxx or /c/xxx. It deals with C:/xxx when compiled for windows and it deals with /c/xxx when compiled for posix. So there is no need to add complexity, it already works in both cases. There are problems only when the two forms are mixed, like it is now. > > The checkbox in preferences is to be considered as a > > one-time switch. Check it and LyX always uses posix paths, uncheck it > > and LyX always uses C:/xxx like paths. > > > > The rationale is that who has cygwin and has all cygwin-apps, gain > > nothing from the win-style paths and actually he maybe *wants* to see > > posix paths. Then he can check the box and is done. > > I understand this argument, but I don't like the conclusions you draw. > In one of my other mails I wrote that cygwin might need a display_path() > function that converts internal paths to a representation that can be > used in file dialogs, for example. external_path() should only be used > for communicating with external programs, not for user interaction. > Therefore external_path() should simply work, no need to make it pretty. > Let us please postpone the user visible paths for now, and first get the > internal representation right. In the actual implementation external_path is already used for display purposes, too. Georg, my idea is really simple and working. When LyX deals internally with pseudo-win style paths, it behaves exactly as the win32 version, when it deals internally with posix paths it behaves exactly as the unix version. Very simple and effective, no problems for the programmer as he already has to account for the C:/xxx style. > > Note that who uses cygwin for its posix features, may like to use > > miktex instead of tetex, or the native Imagemagick instead of the > > cygwin port. I took into account these cases also and in the cygwin > > installation I provide two scripts (convert and epstopdf) which > > deal with them. In this way, who accidentally checks or unchecks > > the checkbox is not going to have any surprise. > > > > IMO, the checkbox is added functionality and no confusion at all. > > That is true if the checkbox controls user visible paths, and is IMO not > true if it controls paths passed to external programs. My idea is that the checkbox makes LyX behave as a native or posix app as regards paths. > > > > As regards os::external_path, it should be equivalent to > > > > os::internal_path, > > > > as it is on *nix. > > > > > > Do you mean with "equivalent" that it should perform the opposite > > > conversion? > > > > No, I mean external_path == internal_path when output is not going > > to .tex files (and always using forward slashes). > > I don't understand. external_path == internal_path would mean that we > neither need external_path nor internal_path. Do you really mean that? external-path and internal_path are already needed for the win32 version (if it was depending on me, I had avoided that), and in os_unix.C they are simply stubs returning their argument. So, for unix, external_path == internal_path already. My idea is that in cygwin it is should be the same but they should return either posix or pseudo win-style paths on demand. > > > The problem with the checkbox is that normal users will probably not > > > understand what it is for. The advantage fo the more general mechanism > > > would be that all the complexity can be in the configure script, and > > > users are only faced with it when defining a new converter. > > > > Not agreed. When they check or uncheck it, they immediately understand > > what it does as the paths they see in preferences (even the PATH > > prefix) and those they get from the file dialogs are of the requested > > type. They don't need to know that the configure script has already > > instructed LyX to output the correct path styles in .tex files. > > > > Moreover, nuking the checkbox maybe be seen as a regression... > > I was talking of the additional checkbox you introduced, not about the > existing one. Uh? What additional checkbox? I simply connected the exiting one to a boolean different from cygwin_path_fix, as I think that the user should not be able to subvert the configure script test. That would be really dangerous and surprising for users: check the box and it works, uncheck the box and it doesn't work anymore. > > No, IMO it should always use windows paths but with forward slashes. > > Note that even notepad and word (microsoft applications) understand > > this, not counting all other non-microsoft programs. > > Initially I had your same idea, but after thinking of it I convinced > > myself that using backslashes can only hurt and does not help. > > How can it hurt? Backslashes are the standard windows notation. Even if > forward slashes work for most aplications, I would still prefer > backslashes, simply because that is the standard. Note that I am still > talking about paths given to external programs, nut user input in file > dialogs. It hurts because you need to introduce a display_path() function which adds unnecessary complication. In earlier times the cygwin version had always output posix paths and you needed wrapper scripts when using native apps. Now you would simply check a box. Notice that it is exactly what the current cygwin version is now doing, only that all this is controlled by the wrong boolean (cygwin_path_fix). > > > - Depending on \cygwin_path_fix_needed, use either native windows > paths > > > with forward slashes or posix paths in latex_path() > > > > Yes. > > > > > This does not need an additional checkbox, and is simple enough for > > > anybody to understand. > > > > Not agreed. IMO the additional checkbox is an added value and I think > > it will be appreciated by the many hating the C:/xxx style and wanting > > the look and feel of a posix app. > > This is again the external_path() <-> display_path() mixup. Nope. The idea is that you internally turn LyX from win32 to posix. > > > And at least the [EMAIL PROTECTED] thing has nothing to do with > external_path, > > > but with latex_path and mixed up internal paths. > > > > Yes, but it was due to the current state of affairs. Scuse me if I may > > seem crude, but studying the sources (I spent quite some time on it, > > even using ddd to debug things) I had the impression that the > > implications of the changes introduced in internal_path and > > external_path were not thought enough. > > I don't think so. Angus spent a lot of time cleaning up Ruurds original > windows port and added the external_path()/internal_path() functions. I > think he was very well aware of the implications, but there seem indeed > to be some places that were not yet considered (e. g. the latex log file > parsing), and the most important point is that these functions were > introduced for non-cygwin windows, and that case is easier than cygwin > because we have fewer options. Don't get me wrong. I think that he did a superb job. I was talking about the cygwin target. My impression is that it does not received sufficient attention and my fear was that it was going down the sink, like OS2. -- Enrico
