Am Samstag, 1. April 2006 18:48 schrieb Enrico Forestieri: > On Sat, Apr 01, 2006 at 05:44:55PM +0200, Georg Baum wrote: > > Let us please postpone the user visible paths for now, and first get the > > internal representation right.
Pretty please!!! > In the actual implementation external_path is already used for > display purposes, too. Georg, my idea is really simple and > working. I doubt the latter, see below. The fact that you did not see problems does not necessarily mean that there are none. > 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. That is no problem indeed. The problem is the runtime change of internal_path() format. > 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. I understood this now, but I don't agree. IMO the format of internal_path should be a compile time decision, not a runtime decision. If it was a runtime decision, it would have the following problems: - Implicit format change of .lyx files. I know that there are currently problems in this area due to the mixup, but for the future I would like to have only one representation of file names in .lyx files for a given platform. - debugging: If something goes wrong on cygwin, we need to know the setting of internal_path(). - what happens for example if a user starts with one setting, and then switches to the other and continues to work? Are all file names in memory magically changed? Or do you want to force him to close LyX and start over? There are probably more implications that I don't think of yet. I am not going to do a final decision on this problem, and I don't want to discuss this further. You need to convince others if you want to do this. If there is agreement that it should go in I am willing to commit it for you (if by then you still have no acoount), but I don't think that my opinion about this problem will change. As I wrote already: Please lets start with the cleanup of the internal mixup. That means: Add external_path()/internal_path() calls where necessary, and hardcode one format both in internal_path() and external_path(). When this is done you can easily implement whatever fancy runtime switches you like on top of that. > > > 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. I thought it was an additional one. What I meant was the new boolean you introduced. I still think that normal users will not really understand what it does. > That would be really dangerous and surprising for users: check > the box and it works, uncheck the box and it doesn't work > anymore. That is how preferences work: Change your latex compiler to "foobar", and you will not be able to create any DVI file anymore. Nevertheless it is possible to do that, because it may be needed in special cases. The same holds for the path checkbox: You may have a strange latex compiler that is not correctly detected by the configure script, and then it is good if you can correct the wrong decision. Almost any program I know of has some advanced settings that can really screw up things, so I don't see a problem here. Users who don't understand what a setting does should simply not change it. > > > 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. I disagree. We would only exchange some occurences of external_path() with display_path(). The only additional complication is that you have to remember when to use external_path and when display_path, but it is small since the rules are simple: external_path() for communication with external programs, display_path() for user input. Besides that, display_path() would only be necessary if we wanted a different representation for the user. Do you have other reasons why using backslashes in external_path() would hurt? Georg
