On Sun, Apr 02, 2006 at 01:11:50PM +0200, Georg Baum wrote:
> 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.
Indeed. I figured out another problem, see below.
> > 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.
I meant it as a one-time switch.
> > 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.
Indeed. When a .lyx file contains an absolute path, it has
different styles depending on whether LyX is a win32 or posix
app. This was one of the reasons I wanted to be able to switch the
internal representation. I am always able to read a .lyx file
produced by a win32 LyX using a cygwin LyX, but it may be not
true the other way, as win32 doesn't understand posix.
Perhaps it would be better to force a pseudo-win style when
outputting file names to .lyx files in order to guarantee
interoperability at least on windows. But if the internal format
is fixed, we have added complexity. However, now I am almost
convinced that this is unavoidable.
> - debugging: If something goes wrong on cygwin, we need to know the
> setting of internal_path().
Maybe.
> - 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?
The last one was my idea. It should not be changed at runtime.
Anyway, I had wrapped all critical points with calls to either
internal_path or external_path, so a on the fly conversion occurs
and it would work.
> 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.
No need for this. I had already reached your same conclusion
before reading your reply. The very technical reason that the
internal format should be posix is that boost doesn't handle
mixed formats.
> 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.
I think it is not necessary. It seems that this stubborn fellow
got convinced at last ;-)
However, as I said, this will add complexity because we are now
outside of the two established and working schemes. What I mean
is that in win32 and *nix internal_path == latex_path, whereas,
when fixing the internal format, this is may not be true in
cygwin anymore.
> 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.
Well, I think that I cannot hardcode a format in external_path as
this would be a regression. Indeed, currently the external format
is dictated by the cygwin_path_fix switch. If I do that, suddenly
a user can find that its external application doesn't work
anymore because it was expecting a given path style.
So, for the moment I will not change the current semantics.
> > 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.
Perhaps there was an unfortunate wording on my part. When I was
spoking of an additional checkbox I meant additional with respect
to a non-cygwin build, not that I was adding it.
Anyway, I think that a new boolean connected to the checkbox is
necessary. The idea which led to the introduction of the checkbox
is still valid and I agree with it. The error was to connect the
checkbox to cygwin_path_fix, IMO.
> > 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.
Come on, Georg, there are many choices by the configure script
that cannot be undone by the user! Think about dvipng which once
detected dictates the instant-preview image formats, and if it
doesn't work correctly (how already reported and how also
happened to me) no previews are generated.
Then we must be realistic. It would be interesting to know what
is the percentage of cygwin users not using either miktex or the
cygwin tetex. I suspect that it is 0.0x% with 0 <= x <= 9.
> > > > 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?
Yes, I have. If a user needs writing a wrapper Bourne shell
script, he must be very careful because, if not using proper
quoting, a backslash in a path can be more dangerous than a path
with spaces.
The fact that forward slashes work in external paths is proved by
my daily use of it and the fact that no problems related to it
have been reported so far. As I already said, even notepad and
word do with forward slashes. So, if it was depending on me, I
had avoided using backslashes even in the native win32 version.
But I understand that in that case a wrapper script would be a
.bat file, so it is better to have proper win32 paths for the
fact that some stupid cmd.exe command could exchange them as a
switch introducer ('/' is used in win32 in the same way '-' is
used in *nix).
--
Enrico
