Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> >>>>> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> You are right. I found
> Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say
> Enrico> that this patch fixes precisely that bug
>
> Probably, yes.
>
> Enrico> Jean-Marc, what about the patch attached at bug 2344?
>
> Enrico> http://bugzilla.lyx.org/show_bug.cgi?id=2344
>
> Enrico> It is really simple and fixes a real bug in cygwin builds.
>
> Yes, it should work with cygwin. We could apply it now, but see below.
>
> Enrico> I think that the PATH prefix handling needs to be polished
> Enrico> with cygwin. As it is now the "Use Cygwin-style paths" button
> Enrico> has no effect and one should always enter the PATH prefix in
> Enrico> posix style format.
>
> Enrico> Then, the "Use Cygwin-style paths" is a bit misleading,
> Enrico> because when it is checked LyX presents you Windows mixed
> Enrico> style paths (\ replaced by /) and when not, posix paths (seems
> Enrico> to be a reversed logic).
>
> It would be nice to understand better this "Use Cygwin-style paths"
> thing. I did not understand it very well when Kayvan introduced it,
> and I'd appreciate other views on it.
>
> If we can get rid of this, it may be that the bug above needs a
> different solution.
No, it is needed anyway. I'll try to explain why in the following.
The idea of the "Use Cygwin-style paths" button is indeed nice, because
as a cygwin application LyX should be considered as posix-compliant and
should really be viewed as if it was a unix/linux program.
But Windows users are not familiar with posix paths and would be confused,
perhaps. So, you show them a Windows-like path and they are happy.
As they stand now, things work, but some polishment is needed. For example,
here is the external_path() function in src/support/os_cygwin.C
string external_path(string const & p)
{
string dos_path;
// Translate from cygwin path syntax to dos path syntax
if (cygwin_path_fix_ && is_absolute_path(p)) {
char dp[PATH_MAX];
cygwin_conv_to_full_win32_path(p.c_str(), dp);
dos_path = !dp ? "" : dp;
}
else return p;
//No backslashes in LaTeX files
dos_path = subst(dos_path,'\\','/');
lyxerr[Debug::LATEX]
<< "<Cygwin path correction> ["
<< p << "]->>["
<< dos_path << ']' << endl;
return dos_path;
}
You can see that the returned path is a Windows-like path only if
cygwin_path_fix_ is true and the original is an absolute path. This is
fine and poses no problems. Depending on cygwin_path_fix_, external_path()
may be equivalent to internal_path(), as it is in os_unix.C.
However, being able to generate Windows-style paths using external_path()
is useful if you use native Windows apps, which are posix-unaware.
Also, this poses little problems if you use cygwin apps, as they
(trough cygwin1.dll) indifferently understand both Windows and posix
notations. The only problem which could arise is if the application
tries to be smart and wants to establish if a path is absolute or not.
But to what is set cygwin_path_fix_? In os_cygwin.C you'll find:
void cygwin_path_fix(bool use_cygwin_paths)
{
cygwin_path_fix_ = use_cygwin_paths;
}
where use_cygwin_paths corresponds to the state of the "Use Cygwin-style
paths" button! Now, for me cygwin-style == posix-style and I see an
inverted logic problem here.
As regards PATH prefix, as the PATH is set using setenv(), a cygwin
function, it always should be in posix format. So, the patch to bug 2344
should be applied in any case.
The polishment to be done in this case would be to let the user enter
a Windows-style PATH list in PATH prefix when "Use Cygwin-style paths"
is checked (sic!) and convert it to a posix-style PATH list behind the
scenes.
So, I think that what should be done is:
1) Rename the "Use Cygwin-style paths" button to "Use Windows-style paths"
2) Add the PATH list conversion above to the PATH prefix handling code,
such that a Windows or posix style PATH list is showed and accepted
depending on the "Use Windows-style paths" button state.
So, in conclusion, whatever is done, the patch attached to bug 2344 is
needed.
--
Enrico
