Re: [patch] Cygwin polishing
On Mon, Apr 03, 2006 at 11:11:40AM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> Moreover, nuking the checkbox maybe be seen as a regression... > > Nuking a checkbox is not a regression per se. Adding a pref just > because we can't make up our mind is bad. Considering that cygwin > users who want such or such kind of paths are technically apt, I'd go > as far as advocating a UI-less pref, that people can change only by > hand. This would avoid a confusing checkbox. One way or the other, but IMO the external path style should be configurable on cygwin (and independent of the latex style paths). Btw, I think that also the win32 native version should take into account cygwin tetex and output proper path styles to .tex files when it is detected. This is already done by the configure script and it would suffice modifying accordingly os::latex_path. If nobody objects, I could do that. -- Enrico
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Moreover, nuking the checkbox maybe be seen as a regression... Nuking a checkbox is not a regression per se. Adding a pref just because we can't make up our mind is bad. Considering that cygwin users who want such or such kind of paths are technically apt, I'd go as far as advocating a UI-less pref, that people can change only by hand. This would avoid a confusing checkbox. JMarc
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Don't get me wrong. I think that he did a superb job. I was Enrico> talking about the cygwin target. My impression is that it does Enrico> not received sufficient attention and my fear was that it was Enrico> going down the sink, like OS2. It is OS2 that went down the sink, not our OS/2 support. We have not heard of a single user for years. Cygwin is not a dying target, AFAIK. JMarc
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 10:07:54PM +0200, Georg Baum wrote:
> Am Sonntag, 2. April 2006 17:26 schrieb Enrico Forestieri:
> > Well, I think that I cannot hardcode a format in external_path as
> > this would be a regression.
>
> The fixes should go to 1.5svn first, and IMO it is acceptable if 1.5svn is
> temporarily broken in that aspect, so I would not care about that too
> much as long as it is only temporarily. I really think that it is useful
> to proceed step by step.
Too late. But I think that it doesn't increase complexity.
> > 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.
>
> This will be impossible if you introduce a new boolean and connect the
> checkbox to that.
I don't think so. From the user perspective, nothing would change.
> > 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.
>
> This can easily be changed via the preferences. Simply delete the
> lyxpreview->png converter, and the old conversion without dvipng will be
> used. This is not intuitive, but the possibility exists. I am not aware
> of any rc setting that is done by the configure script but can't be
> changed through the preferences.
Well, it is rather not intuitive. When it happened to me, I tried
changing dvipng into dvipng.no in lyxpreview2bitmap.py such that
it was not found and the legacy script would have been called.
But dvipng was detected by the configure script and thus png
format was asked for. So I modified the legacy script for png
generation. What a mess.
> > > 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.
>
> I can imagine that.
>
> > 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).
>
> If you are so sure that forward slashes will work, do that, but I would
> not be surprised at all if users report problems with certain programs.
Well, I don't say that it is impossible, but I say that it is
very unlikely.
--
Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 07:45:39PM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > > On Sun, Apr 02, 2006 at 07:02:08PM +0200, Abdelrazak Younes wrote: > > > >> Enrico Forestieri a écrit : > >>> On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: > >> [...] > >> > >>> It always contains paths with forward slashes, but according to > >>> the logic currently used, an absolute path may appear in the .lyx > >>> file. In the win32 version this is in a C:/xxx path style, > >>> whereas in a posix version it is like /c/xxx. Now, a cygwin > >>> version has no problem with either of them, but a win32 version > >>> doesn't understand the /c/xxx style. > >> Ok, thanks for the clarification. IMHO C:/xxx is the way to go for both > >> versions then, no need to make special case for cygwin in .lyx and .tex > >> files. But I guess you have already reached that conclusion. IMHO, this > >> should be the same for internal format because non-cygwin compilers > >> don't understand /c/xxx either. > > > > No, .lyx and .tex files should be treated differently. I agree > > that paths going to .lyx files should be in the C:/xxx syntax, > > but paths for .tex files have to be in either format depending on > > the TeX engine used. > > I guess this is because cygwin tetex cannot understand c:/xxx style. > Sorry if I made you repeat something, your exchange with Georg was > pretty long and I hadn't the courage to read it all. IMHO if cygwin > tetex is not able to read c:/xxx style, this is a tetex bug. Perhaps. I think that a check for an absolute path is done in order to prepend the current dir to it. So, even if the current dir is "./" the resulting path would turn out "./c:/xxx", hence the error. So, rather than a tetex bug I would say that it is an uncareful port of tetex. After all, cygwin let's you go the normal route configure->make->make install, and you could not care about porting at all. -- Enrico
Re: [patch] Cygwin polishing
Am Sonntag, 2. April 2006 17:26 schrieb Enrico Forestieri:
> Well, I think that I cannot hardcode a format in external_path as
> this would be a regression.
The fixes should go to 1.5svn first, and IMO it is acceptable if 1.5svn is
temporarily broken in that aspect, so I would not care about that too
much as long as it is only temporarily. I really think that it is useful
to proceed step by step.
> 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.
This will be impossible if you introduce a new boolean and connect the
checkbox to that.
> 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.
This can easily be changed via the preferences. Simply delete the
lyxpreview->png converter, and the old conversion without dvipng will be
used. This is not intuitive, but the possibility exists. I am not aware
of any rc setting that is done by the configure script but can't be
changed through the preferences.
> > 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.
I can imagine that.
> 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).
If you are so sure that forward slashes will work, do that, but I would
not be surprised at all if users report problems with certain programs.
Georg
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit : On Sun, Apr 02, 2006 at 07:02:08PM +0200, Abdelrazak Younes wrote: Enrico Forestieri a écrit : On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: [...] It always contains paths with forward slashes, but according to the logic currently used, an absolute path may appear in the .lyx file. In the win32 version this is in a C:/xxx path style, whereas in a posix version it is like /c/xxx. Now, a cygwin version has no problem with either of them, but a win32 version doesn't understand the /c/xxx style. Ok, thanks for the clarification. IMHO C:/xxx is the way to go for both versions then, no need to make special case for cygwin in .lyx and .tex files. But I guess you have already reached that conclusion. IMHO, this should be the same for internal format because non-cygwin compilers don't understand /c/xxx either. No, .lyx and .tex files should be treated differently. I agree that paths going to .lyx files should be in the C:/xxx syntax, but paths for .tex files have to be in either format depending on the TeX engine used. I guess this is because cygwin tetex cannot understand c:/xxx style. Sorry if I made you repeat something, your exchange with Georg was pretty long and I hadn't the courage to read it all. IMHO if cygwin tetex is not able to read c:/xxx style, this is a tetex bug. Thanks, Abdel.
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 07:02:08PM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > > On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: > [...] > > > It always contains paths with forward slashes, but according to > > the logic currently used, an absolute path may appear in the .lyx > > file. In the win32 version this is in a C:/xxx path style, > > whereas in a posix version it is like /c/xxx. Now, a cygwin > > version has no problem with either of them, but a win32 version > > doesn't understand the /c/xxx style. > > Ok, thanks for the clarification. IMHO C:/xxx is the way to go for both > versions then, no need to make special case for cygwin in .lyx and .tex > files. But I guess you have already reached that conclusion. IMHO, this > should be the same for internal format because non-cygwin compilers > don't understand /c/xxx either. No, .lyx and .tex files should be treated differently. I agree that paths going to .lyx files should be in the C:/xxx syntax, but paths for .tex files have to be in either format depending on the TeX engine used. Internal format should be posix in cygwin as it is dictated by boost. -- Enrico
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit : On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: [...] It always contains paths with forward slashes, but according to the logic currently used, an absolute path may appear in the .lyx file. In the win32 version this is in a C:/xxx path style, whereas in a posix version it is like /c/xxx. Now, a cygwin version has no problem with either of them, but a win32 version doesn't understand the /c/xxx style. Ok, thanks for the clarification. IMHO C:/xxx is the way to go for both versions then, no need to make special case for cygwin in .lyx and .tex files. But I guess you have already reached that conclusion. IMHO, this should be the same for internal format because non-cygwin compilers don't understand /c/xxx either. Abdel.
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 06:16:34PM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > > On Sun, Apr 02, 2006 at 01:11:50PM +0200, Georg Baum wrote: > >> - 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. > > I am not sure about what you both are talking about but the .lyx file > should contains path with forward slashes only independently from the > system. This is _very_ important for interoperability between windows > user and unix/posix users exchanging lyx files (paths must be relative > then). For the same reason, LyX produced latex files _must_ _always_ use > path with forward slashes. It always contains paths with forward slashes, but according to the logic currently used, an absolute path may appear in the .lyx file. In the win32 version this is in a C:/xxx path style, whereas in a posix version it is like /c/xxx. Now, a cygwin version has no problem with either of them, but a win32 version doesn't understand the /c/xxx style. -- Enrico
Re: [patch] Cygwin polishing
On Sun, Apr 02, 2006 at 05:26:37PM +0200, Enrico Forestieri wrote: > 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 ^^^ ^^^ as as ;-) > happened to me) no previews are generated. -- Enrico
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit :
On Sun, Apr 02, 2006 at 01:11:50PM +0200, Georg Baum wrote:
- 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.
I am not sure about what you both are talking about but the .lyx file
should contains path with forward slashes only independently from the
system. This is _very_ important for interoperability between windows
user and unix/posix users exchanging lyx files (paths must be relative
then). For the same reason, LyX produced latex files _must_ _always_ use
path with forward slashes.
Please make sure that this is the case.
[...]
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.
I second that. Every little program I made under windows used forward
slashes. This is a _very_ common approach. Even Microsoft compilers and
libraries use forward slashes.
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).
Just encapsulates the patch between quotes and it should be fine even in
.bat file.
Abdel.
Re: [patch] Cygwin polishing
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 su
Re: [patch] Cygwin polishing
Enrico Forestieri wrote: Michael, the point is that I think a cygwin version of LyX is potentially better than a native version. This is my opinion and I do not want to convince anybody of it. You should understand that there may be someone who doesn't like what you like and viceversa ;-) I have no problem with that :-) This said, I am happy with any patches that fix cygwin problems. However, we should make sure that MinGW and MikTeX continue to work without special hacks. Agreed. Fine! Michael
Re: [patch] Cygwin polishing
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 > > talki
Re: [patch] Cygwin polishing
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. > > No
Re: [patch] Cygwin polishing
Am Samstag, 1. April 2006 16:37 schrieb Enrico Forestieri: > On Sat, Apr 01, 2006 at 01:24:00PM +0200, Georg Baum wrote: > > > Am Freitag, 31. März 2006 15:21 schrieb Enrico Forestieri: > > > > I do not understand why os::internal_path can return paths like C:/xxx > > > in the win32 version and cannot for the cygwin version. Note that the > > > test for an absolute path already takes that into account. > > > > It could as well return paths like C:/xxx under cygwin. I am actually not > > sure what is better. My point is that it should always do the same for a > > given OS environment. If we make this configurable we only create > > confusion and gain nothing. > > 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. > 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. > 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. > > > 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? > > 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. > > > As it is now, os::external_path > > > already returns C:/xxx style paths depending on the checkbox status. > > > I want simply make that independent of \cygwin_path_fix_needed. > > > > I think we all agree that this is right. > > I take you mean the independence point, because actually the behavior > of external_path is fundamentally wrong. Exactly. > > In this > > case I would like the following simple solution for cygwin: > > > > - Use native windows paths with backslashes in external_path() > > 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 dial
Re: [patch] Cygwin polishing
On Sat, Apr 01, 2006 at 01:24:00PM +0200, Georg Baum wrote: > Am Freitag, 31. März 2006 15:21 schrieb Enrico Forestieri: > > I do not understand why os::internal_path can return paths like C:/xxx > > in the win32 version and cannot for the cygwin version. Note that the > > test for an absolute path already takes that into account. > > It could as well return paths like C:/xxx under cygwin. I am actually not > sure what is better. My point is that it should always do the same for a > given OS environment. If we make this configurable we only create > confusion and gain nothing. This is exactly what my patch does. I do not agree about the confusion. 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. 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. > > 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). > 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... > > As it is now, os::external_path > > already returns C:/xxx style paths depending on the checkbox status. > > I want simply make that independent of \cygwin_path_fix_needed. > > I think we all agree that this is right. I take you mean the independence point, because actually the behavior of external_path is fundamentally wrong. > > Notice that it works. I use it daily without problems with a mix > > of cygwin and native apps. I use MikTeX and the native ImageMagick, > > all other programs are cygwin's. Never noticed a problem. > > So you are saying that there is no need to output cygwin style paths to > external programs? That would be great. I understand that cygwin programs > can also use native windows paths with backslashes. Is that true? Not only it is true, but they can even cope with weird things as 'C:/this\is/a\strange/path'. Indeed, when properly quoted with single quotes, this is taken as C:/this/is/a/strange/path. The only problem which can arise with a cygwin app (if it is a badly ported unix app which doesn't expect win-style paths) is when it tries to establish if the path is absolute or not in order to prepend the current dir path to it. But this is not the case with the helper apps used by LyX. > In this > case I would like the following simple solution for cygwin: > > - Use native windows paths with backslashes in external_path() 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. > - 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. Also note that my patch will go unnoticed by users as no visible changes will occur. Simply, all bugs will be corrected in their eyes. > > Only recently the [EMAIL PROTECTED] bug has arised, and there is another one > > that still has gone unnoticed and that I spotted browsing the sources. > > Small things, easily fixed. > > And at least the [EMAIL PROTECTED] thing has nothing to do with > external_path, > but with l
Re: [patch] Cygwin polishing
Am Freitag, 31. März 2006 15:21 schrieb Enrico Forestieri: > On Fri, Mar 31, 2006 at 01:59:09PM +0200, Georg Baum wrote: > > Enrico Forestieri wrote: > > > > 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. > > I do not understand why os::internal_path can return paths like C:/xxx > in the win32 version and cannot for the cygwin version. Note that the > test for an absolute path already takes that into account. It could as well return paths like C:/xxx under cygwin. I am actually not sure what is better. My point is that it should always do the same for a given OS environment. If we make this configurable we only create confusion and gain nothing. > 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? > > > 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. > > This way you simply add complexity. 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. > As it is now, os::external_path > already returns C:/xxx style paths depending on the checkbox status. > I want simply make that independent of \cygwin_path_fix_needed. I think we all agree that this is right. > Notice that it works. I use it daily without problems with a mix > of cygwin and native apps. I use MikTeX and the native ImageMagick, > all other programs are cygwin's. Never noticed a problem. So you are saying that there is no need to output cygwin style paths to external programs? That would be great. I understand that cygwin programs can also use native windows paths with backslashes. Is that true? In this case I would like the following simple solution for cygwin: - Use native windows paths with backslashes in external_path() - Depending on \cygwin_path_fix_needed, use either native windows paths with forward slashes or posix paths in latex_path() This does not need an additional checkbox, and is simple enough for anybody to understand. > Only recently the [EMAIL PROTECTED] bug has arised, and there is another one > that still has gone unnoticed and that I spotted browsing the sources. > Small things, easily fixed. And at least the [EMAIL PROTECTED] thing has nothing to do with external_path, but with latex_path and mixed up internal paths. Georg
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 08:05:10PM +0200, Michael Gerz wrote: > Just my two cents: > > I agree with Jean-Marc that we should keep things simple. We don't have > to support each and every conceivable configuration. If we manage to > provide the Windows world with a working LyX - no matter how - our job > is done! Michael, the point is that I think a cygwin version of LyX is potentially better than a native version. This is my opinion and I do not want to convince anybody of it. You should understand that there may be someone who doesn't like what you like and viceversa ;-) I compile it for myself and I think I am not leaking any resource from the native version. I also hope to not be a stumbling stone. > I also don't understand why a user may want to change path > conventions at run-time (is there anybody out there who actually > understands the implications?) It is not like that. You simply decide that you like the win-style for paths and check a button in preferences, so it is as if you have the native version. Or you could prefer a posix appearance. But you do this once, not every minute. There is no implication, as the LyX sources already deal with both pseudo-win style and posix style. It is like having a chameleon. The way I designed things, the conversions are always consistent and till now I neither noticed problems, nor can I foresee them. If I have a problem using win-style paths, the same problem will show up in the native version. If I have a problem with posix style, the same problem will show up in the *nix version. However, as cygwin runs on Windows, the win-style is more advantageous, because you can use both native and cygwin apps. Using the native version you are somewhat more limited. I use cygwin and have many cygwin applications, so I do not want to have duplicates for using LyX. Heck, I was even using cygwin for compiling a native version! I was able to use cygwin and native LyX together, but it seems that many people have trouble. So, I think that a cygwin version is good for them. > This said, I am happy with any patches that fix cygwin problems. > However, we should make sure that MinGW and MikTeX continue to work > without special hacks. Agreed. -- Enrico
Re: [patch] Cygwin polishing
Jean-Marc Lasgouttes wrote: Enrico> cygwin-without-cygwin? what's that? ;-) Isn't the point of this thread to support compiling with cygwin -mnocygwin and (perhaps separately, I am not sure anymore) to have a binary that can either be cygwin-based or not depending on the phase of the moon? It may be that I missed the point, but I think we should keep things simple. The interesting part, of course, is proper support for real cygwin, which you address in your other message. Just my two cents: I agree with Jean-Marc that we should keep things simple. We don't have to support each and every conceivable configuration. If we manage to provide the Windows world with a working LyX - no matter how - our job is done! I also don't understand why a user may want to change path conventions at run-time (is there anybody out there who actually understands the implications?) This said, I am happy with any patches that fix cygwin problems. However, we should make sure that MinGW and MikTeX continue to work without special hacks. Michael
Re: 'Re: [patch] Cygwin polishing' - MARC
On Fri, Mar 31, 2006 at 09:53:45AM -0800, Stephen Harris wrote: > http://marc.theaimsgroup.com/?l=lyx-devel&m=114381524012218&w=2 > > Enrico wrote: > Why miktex is outputting non-text characters is beyond me, though. > > --- > > http://groups.google.com/group/comp.editors/browse_thread/thread/1b8a2d71bce3eb33 > /99fc8b9a55bf799f?lnk=st&q=%22%5EM%22++EOL&rnum=1&hl=en#99fc8b9a55bf799f > > I have seen ^M at the end of some words (or lines) which > has to do with Dos/CRLF getting confused with *nix/LF EOL's. > > The DOS EOL (end of line) is seen as Crtl-M by the Unix editor. Yes, this is common. Even a non-ascii character with code > 127 would not be a surprise. But a null (zero value) in the middle of a string is quite unusual. > I wondered if the type of editor used to generate the LyX files > used could cause a conflict? This is a tentative suggestion. No, LyX has no problems in dealing with both line termination styles. -- Enrico
'Re: [patch] Cygwin polishing' - MARC
http://marc.theaimsgroup.com/?l=lyx-devel&m=114381524012218&w=2 Enrico wrote: Why miktex is outputting non-text characters is beyond me, though. --- http://groups.google.com/group/comp.editors/browse_thread/thread/1b8a2d71bce3eb33 /99fc8b9a55bf799f?lnk=st&q=%22%5EM%22++EOL&rnum=1&hl=en#99fc8b9a55bf799f I have seen ^M at the end of some words (or lines) which has to do with Dos/CRLF getting confused with *nix/LF EOL's. The DOS EOL (end of line) is seen as Crtl-M by the Unix editor. I wondered if the type of editor used to generate the LyX files used could cause a conflict? This is a tentative suggestion. Rgards, Stephen
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 10:23:38PM +0200, Enrico Forestieri wrote:
> For example, while testing I just got this assertion from boost:
>
> assertion "src.size() == std::strlen( src.c_str() )" failed: file
> "../../../../../boost/libs/filesystem/src/path_posix_windows.cpp", line 235
>
> I don't get it without my patch, so, something is going wrong.
> Back to thinking...
Actually it turns out that my patch uncovered an already present problem.
I added some debug statements and got this output:
===> '25.34679pt too wide'
===> 'C:/OML/ztmcm/m/it/12 t[]/OT1/ztmcm/m/n/12'
assertion "src.size() == std::strlen( src.c_str() )" failed: file
"../../../../../boost/libs/filesystem/src/path_posix_windows.cpp", line 238
That strange file name comes from LaTeX::deplog and is extracted from the
latex logfile. The pertinent excerpt is the following:
...
Overfull \hbox (25.34679pt too wide) in paragraph at lines 1414--1417
\T1/ptm/m/n/12 where $\OML/ztmcm/m/it/12 [] \OT1/ztmcm/m/n/12 = \OML/ztmcm/m/i
t/12 s[]\OT1/ztmcm/m/n/12 (\OML/ztmcm/m/it/12 t[]\OT1/ztmcm/m/n/12 )$\T1/ptm/m/
n/12 , and $\OML/ztmcm/m/it/12 \OT1/ztmcm/m/n/12 = \OML/ztmcm/m/it/12 R\OT1/z
tmcm/m/n/12 (\OML/ztmcm/m/it/12 t[] \OMS/ztmcm/m/n/12 \OML/ztmcm/m/it/12 t[]\
OT1/ztmcm/m/n/12 )\OML/ztmcm/m/it/12 =R\OT1/ztmcm/m/n/12 (0)$ \T1/ptm/m/n/12 is
their cor-re-la-tion co-ef-fi-cient, be-ing $\OML/ztmcm/m/it/12 R\OT1/ztmcm/m/
n/12 (\OML/ztmcm/m/it/12 \OT1/ztmcm/m/n/12 ) = \OMS/ztmcm/m/n/12 F[] []$\T1/pt
m/m/n/12 .
...
Here, "(\OML/ztmcm/m/it/12 t[] \OMS/ztmcm/m/n/12 \OML..." is taken
as a filename because it is after a "(". Notice that a null is in there.
I don't know if it will survive the email transfer, but I see it as ^@ in
vim, and as in nedit, just before " \OML...".
The fact that the path above has a C: prepended and '\' turned into '/'
is due to the cygwin api functions converting filepaths.
So, I think that my patch is innocent here, or at least it is not the
direct cause of the assert.
Why miktex is outputting non-text characters is beyond me, though.
--
Enrico
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> Ok, let's take a more pragmatic approach. I am going to post a Enrico> patch #1 which simply solves the two problems above. I would Enrico> like them fixed in 1.4.1 such that the binary I'll made Enrico> available will not be different from that which can be built Enrico> from the official sources. Notice that I have already Enrico> incorporated the fix to bug 2344 in 1.4.0, which otherwise Enrico> would be unusable. Enrico> Then I am going to separate the checkbox from the cygwin_fix Enrico> setting. This is going to be patch #2. Looks good. JMarc
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 02:33:08PM +0200, Georg Baum wrote: > Enrico Forestieri wrote: > > > I think that it is better to proceed step by step. Is it okay with you > > if I start from scratch and do the minimum necessary to fix real bugs? > > You don't need to start from scratch, since you solved a lot of probelsm > already. I like the step by step approach, and would really appreciate if > you could start with the latex_path fixes and fix the current cygwin_fix > setting. Then you could look at input_path(), and then at the problems > below: > > > Currently these are: > > > > 1) Bug 2344. > > 2) If in a graphics inset an absolute path is inserted by the file dialog, > >it will be exported in the .tex file in posix format, such that miktex > >fails to find the file. This has not been reported by anyone, I > >discovered it browsing the sources. > > If you think that the order should be different: that would also be fine > with me. Ok, let's take a more pragmatic approach. I am going to post a patch #1 which simply solves the two problems above. I would like them fixed in 1.4.1 such that the binary I'll made available will not be different from that which can be built from the official sources. Notice that I have already incorporated the fix to bug 2344 in 1.4.0, which otherwise would be unusable. Then I am going to separate the checkbox from the cygwin_fix setting. This is going to be patch #2. Then we will see. Is this acceptable for you? -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 02:11:25PM +0200, Jean-Marc Lasgouttes wrote: > > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: > > >> 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. > > Georg> Not agreed. os::internal_path should always create posix-style > Georg> paths. Why would we want other paths internally? > > Definitely. Note that for the win32 target os::internal_path returns pseudo-win style paths. Why it cannot be so also for cygwin? > Georg> If you think about presentation of paths to the user, then I > Georg> would rather invent a new function display_path(), otherwise we > Georg> mixup things. One could argue what os::external_path should do. > > external_path could have a second, optional, argument that would be an > enum describing what we want to do with the name (LATEX, DEFAULT, > whatever). No, sorry. external_path should not be related to latex. > Hmmm, I am not sure it is a good idea actually. > > Georg> The checkbox does not really solve the fundamental problem: On > Georg> cygwin, we don't know which of the external programs needs a > Georg> cygwin style path, and which one needs a native windows path. > Georg> rather than the checkbox I would like to have a more general > Georg> mechanism, for example a wrapper script that is invoked instead > Georg> of an external program and that can translate the paths. The > Georg> configure script could then write the corresponding entries in > Georg> lyxrc.default. > > For converters, we could use a flag to tell what kind of paths are > needed. Of course, if we use "convert" we do not know whether it is a > native or a cygwin version (do both exist?). Both exist, and the cygwin version has no problems with C:/xxx style paths, even if it is presented with eps:C:/xxx. > We could also have special forms of $i $o and friends asking for an > internal path. This is a cool idea, but I think that it is orthogonal to the question of what kind of paths internal_path and external_path should return. -- Enrico
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 01:59:09PM +0200, Georg Baum wrote: > Enrico Forestieri wrote: > > 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. I do not understand why os::internal_path can return paths like C:/xxx in the win32 version and cannot for the cygwin version. Note that the test for an absolute path already takes that into account. As regards os::external_path, it should be equivalent to os::internal_path, as it is on *nix. > > 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. This way you simply add complexity. As it is now, os::external_path already returns C:/xxx style paths depending on the checkbox status. I want simply make that independent of \cygwin_path_fix_needed. Notice that it works. I use it daily without problems with a mix of cygwin and native apps. I use MikTeX and the native ImageMagick, all other programs are cygwin's. Never noticed a problem. Only recently the [EMAIL PROTECTED] bug has arised, and there is another one that still has gone unnoticed and that I spotted browsing the sources. Small things, easily fixed. > > 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. Ok. -- Enrico
Re: [patch] Cygwin polishing
Enrico Forestieri wrote: > I think that it is better to proceed step by step. Is it okay with you > if I start from scratch and do the minimum necessary to fix real bugs? You don't need to start from scratch, since you solved a lot of probelsm already. I like the step by step approach, and would really appreciate if you could start with the latex_path fixes and fix the current cygwin_fix setting. Then you could look at input_path(), and then at the problems below: > Currently these are: > > 1) Bug 2344. > 2) If in a graphics inset an absolute path is inserted by the file dialog, >it will be exported in the .tex file in posix format, such that miktex >fails to find the file. This has not been reported by anyone, I >discovered it browsing the sources. If you think that the order should be different: that would also be fine with me. Georg
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 12:34:36PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> I beg your pardon, next time I'll check more closely > Enrico> quotations. > > No problem, I would be more useful if I actually manage to understand > how cygwin stuff should work. I already tried to tell how I think it should work. I am going to summarize here my thoughts from a cygwin pov only. In Windows either a native or cygwin-based TeX engine can be used. This means that paths written in .tex files should have either a win- or posix-style depending on the TeX engine used (note that this is also true for the native version of LyX, which is otherwise unusable with the cygwin-tetex). The configure script already has the ability to detect the TeX engine and it sets the boolean \cygwin_path_fix_needed accordingly. When it is true, we are using a native TeX engine. So, a os::latex_path function is needed (other than os::internal_path and os::external_path) to convert paths going to .tex files in the right format. As cygwin is posix conformant, os:internal_path and os::external_path could be noop functions as it is for *nix. BUT: if one uses miktex, most probably also has other native apps which would be unusable because they don't understand posix. Now, given that cygwin apps have no problems with either win- or posix-style formats, it is reasonable that both os::internal_path and os::external_path return pseudo win-style paths (I mean paths with forward slashes, but with a prefixing drive letter and a colon). However, if one uses tetex, most probably has all cygwin-apps and it is better that both os::insternal_path and os::external_path return posix-style formats. My patch does exactly this. The user cannot customize os::latex_path because that is the configure script job. However, he can decide if is version of LyX/Cygwin behaves as if it was a native win32 app or not as regards the paths used elsewhere. How things currently work: - The configure script makes its guess about \cygwin_path_fix_needed. - Every path used externally to LyX has the format dictated by the configure guess, irrespectively of whether it goes written into a .tex file or not. - The user can subvert the configure guess by a checkbox. So, currently LyX behaves as a native or posix app based on the checkbox. My patch tries to polish things, separating the case of "path for latex" by that of "path for external use". -- Enrico
Re: [patch] Cygwin polishing
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes: >> 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. Georg> Not agreed. os::internal_path should always create posix-style Georg> paths. Why would we want other paths internally? Definitely. Georg> If you think about presentation of paths to the user, then I Georg> would rather invent a new function display_path(), otherwise we Georg> mixup things. One could argue what os::external_path should do. external_path could have a second, optional, argument that would be an enum describing what we want to do with the name (LATEX, DEFAULT, whatever). Hmmm, I am not sure it is a good idea actually. Georg> The checkbox does not really solve the fundamental problem: On Georg> cygwin, we don't know which of the external programs needs a Georg> cygwin style path, and which one needs a native windows path. Georg> rather than the checkbox I would like to have a more general Georg> mechanism, for example a wrapper script that is invoked instead Georg> of an external program and that can translate the paths. The Georg> configure script could then write the corresponding entries in Georg> lyxrc.default. For converters, we could use a flag to tell what kind of paths are needed. Of course, if we use "convert" we do not know whether it is a native or a cygwin version (do both exist?). We could also have special forms of $i $o and friends asking for an internal path. JMarc
Re: [patch] Cygwin polishing
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_pathfor 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
Re: [patch] Cygwin polishing
Jean-Marc Lasgouttes a écrit : "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> cygwin-without-cygwin? what's that? ;-) Isn't the point of this thread to support compiling with cygwin -mnocygwin and (perhaps separately, I am not sure anymore) to have a binary that can either be cygwin-based or not depending on the phase of the moon? It may be that I missed the point, but I think we should keep things simple. Enrico> No, you got it wrong. This for the real cygwin target. Well, I was answering to abdel originally, and he did say he wanted an universal binary that would decide at runtime whether it is cygwin-based or not. This looks complicated for now, forget about it. But I still think some of the fixes for cygwin-really-cygwin from Enrico applies also to cygwin-mnocygwin which should be the same (in theory) as msys-mingw. As a side note, with my minimal cygwin install (base cygwin + autotools, no gcc) + mingw, I can compile and link an unpatched qt3 and/or qt4 lyx-win32 without problem. This means that I don't need MSYS anymore and I am very happy about that :-) Abdel.
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> I beg your pardon, next time I'll check more closely Enrico> quotations. No problem, I would be more useful if I actually manage to understand how cygwin stuff should work. JMarc
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 12:10:14PM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> cygwin-without-cygwin? what's that? ;-) > >> Isn't the point of this thread to support compiling with cygwin > >> -mnocygwin and (perhaps separately, I am not sure anymore) to have > >> a binary that can either be cygwin-based or not depending on the > >> phase of the moon? It may be that I missed the point, but I think > >> we should keep things simple. > > Enrico> No, you got it wrong. This for the real cygwin target. > > Well, I was answering to abdel originally, and he did say he wanted an > universal binary that would decide at runtime whether it is > cygwin-based or not. You're right. I got it wrong ;-) > >> The interesting part, of course, is proper support for real cygwin, > >> which you address in your other message. > > Enrico> I always had addressed real cygwin. I have never spoken of > Enrico> problems related to build a native LyX with cygwin > Enrico> (cygwin-without-cygwin). > > Did I say you did? I beg your pardon, next time I'll check more closely quotations. -- Enrico
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> cygwin-without-cygwin? what's that? ;-) >> Isn't the point of this thread to support compiling with cygwin >> -mnocygwin and (perhaps separately, I am not sure anymore) to have >> a binary that can either be cygwin-based or not depending on the >> phase of the moon? It may be that I missed the point, but I think >> we should keep things simple. Enrico> No, you got it wrong. This for the real cygwin target. Well, I was answering to abdel originally, and he did say he wanted an universal binary that would decide at runtime whether it is cygwin-based or not. >> The interesting part, of course, is proper support for real cygwin, >> which you address in your other message. Enrico> I always had addressed real cygwin. I have never spoken of Enrico> problems related to build a native LyX with cygwin Enrico> (cygwin-without-cygwin). Did I say you did? JMarc
Re: [patch] Cygwin polishing
On Fri, Mar 31, 2006 at 10:59:18AM +0200, Jean-Marc Lasgouttes wrote: > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: > > Enrico> On Thu, Mar 30, 2006 at 06:39:39PM +0200, Jean-Marc Lasgouttes > Enrico> wrote: > >> I think this cygwin-without-cygwin stuff is becoming stranger and > >> stranger. > > Enrico> cygwin-without-cygwin? what's that? ;-) > > Isn't the point of this thread to support compiling with cygwin > -mnocygwin and (perhaps separately, I am not sure anymore) to have a > binary that can either be cygwin-based or not depending on the phase > of the moon? It may be that I missed the point, but I think we should > keep things simple. No, you got it wrong. This for the real cygwin target. > The interesting part, of course, is proper support for real cygwin, > which you address in your other message. I always had addressed real cygwin. I have never spoken of problems related to build a native LyX with cygwin (cygwin-without-cygwin). In some other thread I mentioned it only to say that building it that way I see no problems related with gettext/libiconv as opposed to what seems to happen using mingw. -- Enrico
Re: [patch] Cygwin polishing
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes: Enrico> On Thu, Mar 30, 2006 at 06:39:39PM +0200, Jean-Marc Lasgouttes Enrico> wrote: >> I think this cygwin-without-cygwin stuff is becoming stranger and >> stranger. Enrico> cygwin-without-cygwin? what's that? ;-) Isn't the point of this thread to support compiling with cygwin -mnocygwin and (perhaps separately, I am not sure anymore) to have a binary that can either be cygwin-based or not depending on the phase of the moon? It may be that I missed the point, but I think we should keep things simple. The interesting part, of course, is proper support for real cygwin, which you address in your other message. JMarc
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 10:21:53PM +0200, Georg Baum wrote:
> Am Mittwoch, 29. März 2006 20:49 schrieb Enrico Forestieri:
>
> > I have reorganized things in this way:
> > 1) The kind of path style to be written into .tex files is only
> > decided by the configure script which checks what the correct
> > style is (miktex vs cygwin tetex).
> > 2) The "Use Cygwin-style paths" checkbox is now unrelated to the
> > check performed by the configure script.
>
> I am not sure that this good. This checkbox was introduced because the
> user should be able to override the result of the configure script (if
> you want to know more, read the thread "Latest LyX on Latest Cygwin" from
> jan 2005).
I read it.
> IMHO the checkbox should go completely if it is never necessary to correct
> the decision of the configure script, or it should stay and override that
> decision as it has been originally.
Currently, the checkbox also decides that all external paths should be
in windows style. That may be fine, but there is a problem. When checked
you get win-style paths instead of posix, i.e., the contrary of what the
checkbox is labeled ("Use Cygwin-style paths").
> > When unchecked, all
> > paths written to .lyx files, returned by the dialogs, and shown
> > in preferences are in pseudo win-style, including the PATH prefix.
>
> What has the path prefix to do with that?
Currently, you have win-style paths in all preferences except PATH prefix
which should always be entered in posix style.
> > When using win-style paths, the .lyx files written by the cygwin
> > version can also be read by the native LyX version (when they
> > contain absolute paths).
>
> In 1.3 it was possible to use the same files with relative filenames on
> linux and native win, does this still work?
Yes, it does.
> IMHO the paths in LyX files should always be with forward slashes. This
> should not be configurable. That gives maximum compatibility between
> platforms.
It is already so.
> Note that the "Use Cygwin-style paths" was originally implemented only for
> LaTeX paths. IMO it should retain that meaning. The problem that other
> programs (converters) may need different paths was not dealt with at all,
> but the thread mentioned above has solutions.
Yes, I read it and I agree with you. But currently it is not so.
> > Index: insets/insetgraphics.C
> > ===
> > --- insets/insetgraphics.C (revision 13529)
> > +++ insets/insetgraphics.C (working copy)
> > @@ -597,7 +597,7 @@ string const InsetGraphics::prepareFile(
> > copyToDirIfNeeded(orig_file, temp_path, zipped);
> >
> > if (status == FAILURE)
> > - return orig_file;
> > + return os::latex_path(orig_file);
> >
> > // a relative filename should be relative to the master
> > // buffer.
> > @@ -629,7 +629,7 @@ string const InsetGraphics::prepareFile(
> > boost::tie(status, bb_file) =
> > copyFileIfNeeded(bb_orig_file,
> bb_file);
> > if (status == FAILURE)
> > - return orig_file;
> > + return
> os::latex_path(orig_file);
> > runparams.exportdata->addExternalFile("latex",
> > bb_file);
> > }
>
> These changes are not necessary, but don't hurt either. These return
> statements are only executed if something failed already, so the .tex
> file cannot be compiled anyway.
Understood. I was being thorough.
> > Index: bufferlist.C
> > ===
> > --- bufferlist.C(revision 13529)
> > +++ bufferlist.C(working copy)
> > @@ -28,6 +28,7 @@
> >
> > #include "support/filetools.h"
> > #include "support/package.h"
> > +#include "support/os.h"
> >
> > #include
> >
> > @@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile;
> > using lyx::support::package;
> > using lyx::support::prefixIs;
> >
> > +using lyx::support::os::external_path;
> > +
> > using boost::bind;
> >
> > using std::auto_ptr;
> > @@ -379,7 +382,7 @@ Buffer * BufferList::getBufferFromTmp(st
> > BufferStorage::iterator it = bstore.begin();
> > BufferStorage::iterator end = bstore.end();
> > for (; it < end; ++it)
> > - if (prefixIs(s, (*it)->temppath()))
> > + if (prefixIs(external_path(s),
> external_path((*it)->temppath(
> > return *it;
> > return 0;
> > }
>
> This looks strange. Why is it needed? Please add an explaining comment.
Oh, this must be a left over. I think this is not necessary after the
patch to package.C.in. Here (*it)->temppath() is in posix format while
s can be in win
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:44:17PM +0200, Abdelrazak Younes wrote: > I am using TortoiseSVN which has a very good GUI that can show visual > comparison between revisions or even 3-way comparisons. With this GUI > you can reject a change, revert to an older version, etc. I definitely > prefer this method of reviewing instead of having to apply the patch > first (which does not always work fine). For me reading a diff is not > practical for new functionality, only for bug fixing. I find that another good tool is meld. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:01:52PM +0200, Jean-Marc Lasgouttes wrote: > > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Abdelrazak> Message to the main lyx developers: > > Abdelrazak> IMHO, if you want to encourage new contributions, you > Abdelrazak> should relax a bit the implicit process of reviewing for > Abdelrazak> trunk. I think that external developers are feeling very > Abdelrazak> scared (I am for non-qt4) and this fact can stop them from > Abdelrazak> further contribution. So instead of discussing during a > Abdelrazak> month or two some patches, why not commit the patches (if > Abdelrazak> they don't make lyx crash) and work from that point? > > I think reviewing publicly a patch is easier when it is complete. The > main problem is that we do not have enough time to work on LyX. I know > this is a problem for me; already focusing on 1.4 is difficult, so > reviewing patches lags. I hope I will be more available after 1.4 > settles. No problem with me. I am not going to push you. > OTOH, we have tried adding patches 'that work' without asking much. > And now we have a lot of code that nobody really understands or > special hacks. It is not that new contributors are not good. It is > just that often you need several people to find the right solution. > > I do want to have new blood in the team. We definitely need that. But > at the same time we need to keep the code in a consistent shape. FWIW, I agree with you. -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 06:39:39PM +0200, Jean-Marc Lasgouttes wrote: > I think this cygwin-without-cygwin stuff is becoming stranger and > stranger. cygwin-without-cygwin? what's that? ;-) -- Enrico
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 05:33:31PM +0200, Georg Baum wrote: > I did not yet have time to comment on Enricos patch, I just had a quick look > and the cygwin ifdefs he introduced in frontends/qt2/FileDialog.C don't > seem right. If they are really needed (which I doubt currently, but that > may change after reading the whole patch) we should introduce just another > patch function. That way, we get nice clean code and the ugly stuff is > banned to few files in src/support. I try to explain again why I did that. 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". 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_pathfor 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). 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). 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. 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. 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. 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. 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). -- Enrico
Re: [patch] Cygwin polishing
Am Donnerstag, 30. März 2006 18:39 schrieb Jean-Marc Lasgouttes: > I think this cygwin-without-cygwin stuff is becoming stranger and > stranger. Indeed. We should keep this as simple as possible. IMO a cygwin ignorant person (such as me) should be able to understand the code without even touching a cygwin box. Otherwise the risk is high that the cygwin code will rust and eventually die because nobody is able to maintain it. Georg
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 03:56:02PM +0200, Abdelrazak Younes wrote: > Just for confirmation, is /cygdrive is present on any cygwin installation? > But in the special case where a user has a c:\cygdrive and lyx is > installed on the same drive, this test doesn't work (I just made the > test). Is there any other way? I really don't know... > Message to the main lyx developers: > > IMHO, if you want to encourage new contributions, you should relax a bit > the implicit process of reviewing for trunk. I think that external > developers are feeling very scared (I am for non-qt4) and this fact can > stop them from further contribution. So instead of discussing during a > month or two some patches, why not commit the patches (if they don't > make lyx crash) and work from that point? It's easy enough to revert a > change with SVN if a patch is obviously wrong. IMHO, from the new > developer point of view, it is much easier to work this way. And _I_ > think that the SVN history is much better than the mailing archive in > order to know why this or that patch has evolved. Abdel, I think that a review is necessary. You cannot be sure that you did no mistakes. As regards myself, I understand that cygwin related problems are not a priority. I simply hope to pinpoint the problems, suggest a solution and wait that someone more knowleadgeable than me tells if it is ok or suggests something better. For example, while testing I just got this assertion from boost: assertion "src.size() == std::strlen( src.c_str() )" failed: file "../../../../../boost/libs/filesystem/src/path_posix_windows.cpp", line 235 I don't get it without my patch, so, something is going wrong. Back to thinking... -- Enrico
Re: [patch] Cygwin polishing
Am Mittwoch, 29. März 2006 20:49 schrieb Enrico Forestieri:
> I have reorganized things in this way:
> 1) The kind of path style to be written into .tex files is only
> decided by the configure script which checks what the correct
> style is (miktex vs cygwin tetex).
> 2) The "Use Cygwin-style paths" checkbox is now unrelated to the
> check performed by the configure script.
I am not sure that this good. This checkbox was introduced because the
user should be able to override the result of the configure script (if
you want to know more, read the thread "Latest LyX on Latest Cygwin" from
jan 2005).
IMHO the checkbox should go completely if it is never necessary to correct
the decision of the configure script, or it should stay and override that
decision as it has been originally.
> When unchecked, all
> paths written to .lyx files, returned by the dialogs, and shown
> in preferences are in pseudo win-style, including the PATH prefix.
What has the path prefix to do with that?
> When using win-style paths, the .lyx files written by the cygwin
> version can also be read by the native LyX version (when they
> contain absolute paths).
In 1.3 it was possible to use the same files with relative filenames on
linux and native win, does this still work?
IMHO the paths in LyX files should always be with forward slashes. This
should not be configurable. That gives maximum compatibility between
platforms.
Note that the "Use Cygwin-style paths" was originally implemented only for
LaTeX paths. IMO it should retain that meaning. The problem that other
programs (converters) may need different paths was not dealt with at all,
but the thread mentioned above has solutions.
> Index: insets/insetgraphics.C
> ===
> --- insets/insetgraphics.C (revision 13529)
> +++ insets/insetgraphics.C (working copy)
> @@ -597,7 +597,7 @@ string const InsetGraphics::prepareFile(
> copyToDirIfNeeded(orig_file, temp_path, zipped);
>
> if (status == FAILURE)
> - return orig_file;
> + return os::latex_path(orig_file);
>
> // a relative filename should be relative to the master
> // buffer.
> @@ -629,7 +629,7 @@ string const InsetGraphics::prepareFile(
> boost::tie(status, bb_file) =
> copyFileIfNeeded(bb_orig_file,
bb_file);
> if (status == FAILURE)
> - return orig_file;
> + return
os::latex_path(orig_file);
> runparams.exportdata->addExternalFile("latex",
> bb_file);
> }
These changes are not necessary, but don't hurt either. These return
statements are only executed if something failed already, so the .tex
file cannot be compiled anyway.
> Index: bufferlist.C
> ===
> --- bufferlist.C(revision 13529)
> +++ bufferlist.C(working copy)
> @@ -28,6 +28,7 @@
>
> #include "support/filetools.h"
> #include "support/package.h"
> +#include "support/os.h"
>
> #include
>
> @@ -43,6 +44,8 @@ using lyx::support::removeAutosaveFile;
> using lyx::support::package;
> using lyx::support::prefixIs;
>
> +using lyx::support::os::external_path;
> +
> using boost::bind;
>
> using std::auto_ptr;
> @@ -379,7 +382,7 @@ Buffer * BufferList::getBufferFromTmp(st
> BufferStorage::iterator it = bstore.begin();
> BufferStorage::iterator end = bstore.end();
> for (; it < end; ++it)
> - if (prefixIs(s, (*it)->temppath()))
> + if (prefixIs(external_path(s),
external_path((*it)->temppath(
> return *it;
> return 0;
> }
This looks strange. Why is it needed? Please add an explaining comment.
> Index: exporter.C
> ===
> --- exporter.C (revision 13529)
> +++ exporter.C (working copy)
> @@ -33,6 +33,7 @@
> #include "support/filetools.h"
> #include "support/lyxlib.h"
> #include "support/package.h"
> +#include "support/os.h"
>
> #include
>
> @@ -46,6 +47,7 @@ using lyx::support::OnlyFilename;
> using lyx::support::OnlyPath;
> using lyx::support::package;
> using lyx::support::prefixIs;
> +using lyx::support::os::external_path;
>
> using std::find;
> using std::string;
> @@ -107,7 +109,8 @@ CopyStatus copyFile(string const & forma
> // overwrite themselves. This check could be changed to
> // boost::filesystem::equivalent(sourceFile, destFile) if export
to
> // other directories than the document directory is desired.
> - if (!prefixIs(OnlyPath(sourceFile), package().temp_dir()))
> + if (!prefixIs(external_p
Re: [patch] Cygwin polishing
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: I don't understand what is wrong with an #ifdef? I personally prefer always compiletime checks rather than runtime checks if it is possible. Why do a hackish runtime test if the same thing can be achieved at compile time? Abdelrazak> In this case, the goal would be have a universal windows Abdelrazak> binary. And how would that work? If cygwin is installed on the computer, use that, and otherwise don't? No, no checking of that sort... I was thinking of a user setting that indicates that some cygwin environment should be used and a runtime check that will verify that. It looks a bit strange to me, especially since we do use stuff from the cygwin api. Actually I would prefer a solution that do not use the cygwin api at all but would use cygwin tools and environment if detected. I am not sure this is possible and I seem to remember some apps that can do that (xemacs maybe?). I think this cygwin-without-cygwin stuff is becoming stranger and stranger. I am not sure I understand it all either... Abdel.
Re: [patch] Cygwin polishing
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> I don't understand what is wrong with an #ifdef? I personally >> prefer always compiletime checks rather than runtime checks if it >> is possible. Why do a hackish runtime test if the same thing can be >> achieved at compile time? Abdelrazak> In this case, the goal would be have a universal windows Abdelrazak> binary. And how would that work? If cygwin is installed on the computer, use that, and otherwise don't? It looks a bit strange to me, especially since we do use stuff from the cygwin api. I think this cygwin-without-cygwin stuff is becoming stranger and stranger. JMarc
Re: [patch] Cygwin polishing
Georg Baum a écrit :
Abdelrazak Younes wrote:
Abdelrazak Younes a écrit :
#include
bool isCygwin()
{
return access("/cygdrive", F_OK) == 0;
}
Just for confirmation, is /cygdrive is present on any cygwin
installation? But in the special case where a user has a c:\cygdrive and
lyx is installed on the same drive, this test doesn't work (I just made
the test). Is there any other way?
"/usr/bin/cygstart.exe" seems to be a good candidates... Any objection
if I replace the #ifdef with this test in the Qt4 frontend?
Please not.
Ah... At least someone is listening to me :-)
This is a hack. It is not impossible to have
a /usr/bin/cygstart.exe on any unix box. Then your test will fail.
OK, then:
inline bool isCygwin()
{
#ifdef WIN32
return access("/usr/bin/cygstart.exe", F_OK) == 0;
#endif
return false;
}
This call will cost virtually no CPU and should be eliminated by a good
compiler.
I don't understand what is wrong with an #ifdef? I personally prefer always
compiletime checks rather than runtime checks if it is possible. Why do a
hackish runtime test if the same thing can be achieved at compile time?
In this case, the goal would be have a universal windows binary.
Of course the #ifdefs should not be scattered around, but isolated in few
utility functions. For this reason we have introduced the various ...path()
functions, and this works quite well.
Agreed. I just want to minimize the #ifdef to a unique support file.
I did not yet have time to comment on Enricos patch, I just had a quick look
and the cygwin ifdefs he introduced in frontends/qt2/FileDialog.C don't
seem right. If they are really needed (which I doubt currently, but that
may change after reading the whole patch) we should introduce just another
patch function. That way, we get nice clean code and the ugly stuff is
banned to few files in src/support.
OK.
Abdel.
Re: [patch] Cygwin polishing
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Message to the main lyx developers: Abdelrazak> IMHO, if you want to encourage new contributions, you Abdelrazak> should relax a bit the implicit process of reviewing for Abdelrazak> trunk. I think that external developers are feeling very Abdelrazak> scared (I am for non-qt4) and this fact can stop them from Abdelrazak> further contribution. So instead of discussing during a Abdelrazak> month or two some patches, why not commit the patches (if Abdelrazak> they don't make lyx crash) and work from that point? I think reviewing publicly a patch is easier when it is complete. I am using TortoiseSVN which has a very good GUI that can show visual comparison between revisions or even 3-way comparisons. With this GUI you can reject a change, revert to an older version, etc. I definitely prefer this method of reviewing instead of having to apply the patch first (which does not always work fine). For me reading a diff is not practical for new functionality, only for bug fixing. The main problem is that we do not have enough time to work on LyX. I know this is a problem for me; This is a problem for most of us and its maybe even more frustrating if you are trying to help but your contribution cannot be reviewed. If there's nobody currently with enough time, we could make use of TAGS indicating that this revision needs to be reviewed before any further change. already focusing on 1.4 is difficult, so reviewing patches lags. I hope I will be more available after 1.4 settles. OTOH, we have tried adding patches 'that work' without asking much. I am not advocating that, quite the contrary actually. Committing a patch "that work" can be reviewed by more people. If someone object, we can discuss that and revert the commit if there's a consensus or fix what's wrong directly in the repository. And now we have a lot of code that nobody really understands or special hacks. It is not that new contributors are not good. It is just that often you need several people to find the right solution. Agreed, see above. I do want to have new blood in the team. We definitely need that. But at the same time we need to keep the code in a consistent shape. Please consider my proposal. Abdel.
Re: [patch] Cygwin polishing
Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
>> #include
>>
>> bool isCygwin()
>> {
>> return access("/cygdrive", F_OK) == 0;
>> }
>>
>> Just for confirmation, is /cygdrive is present on any cygwin
>> installation? But in the special case where a user has a c:\cygdrive and
>> lyx is installed on the same drive, this test doesn't work (I just made
>> the test). Is there any other way?
>
> "/usr/bin/cygstart.exe" seems to be a good candidates... Any objection
> if I replace the #ifdef with this test in the Qt4 frontend?
Please not. This is a hack. It is not impossible to have
a /usr/bin/cygstart.exe on any unix box. Then your test will fail.
I don't understand what is wrong with an #ifdef? I personally prefer always
compiletime checks rather than runtime checks if it is possible. Why do a
hackish runtime test if the same thing can be achieved at compile time?
Of course the #ifdefs should not be scattered around, but isolated in few
utility functions. For this reason we have introduced the various ...path()
functions, and this works quite well.
I did not yet have time to comment on Enricos patch, I just had a quick look
and the cygwin ifdefs he introduced in frontends/qt2/FileDialog.C don't
seem right. If they are really needed (which I doubt currently, but that
may change after reading the whole patch) we should introduce just another
patch function. That way, we get nice clean code and the ugly stuff is
banned to few files in src/support.
Georg
Re: [patch] Cygwin polishing
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Message to the main lyx developers: Abdelrazak> IMHO, if you want to encourage new contributions, you Abdelrazak> should relax a bit the implicit process of reviewing for Abdelrazak> trunk. I think that external developers are feeling very Abdelrazak> scared (I am for non-qt4) and this fact can stop them from Abdelrazak> further contribution. So instead of discussing during a Abdelrazak> month or two some patches, why not commit the patches (if Abdelrazak> they don't make lyx crash) and work from that point? I think reviewing publicly a patch is easier when it is complete. The main problem is that we do not have enough time to work on LyX. I know this is a problem for me; already focusing on 1.4 is difficult, so reviewing patches lags. I hope I will be more available after 1.4 settles. OTOH, we have tried adding patches 'that work' without asking much. And now we have a lot of code that nobody really understands or special hacks. It is not that new contributors are not good. It is just that often you need several people to find the right solution. I do want to have new blood in the team. We definitely need that. But at the same time we need to keep the code in a consistent shape. JMarc
Re: [patch] Cygwin polishing
Abdelrazak Younes a écrit :
#include
bool isCygwin()
{
return access("/cygdrive", F_OK) == 0;
}
Just for confirmation, is /cygdrive is present on any cygwin installation?
But in the special case where a user has a c:\cygdrive and lyx is
installed on the same drive, this test doesn't work (I just made the
test). Is there any other way?
"/usr/bin/cygstart.exe" seems to be a good candidates... Any objection
if I replace the #ifdef with this test in the Qt4 frontend?
Abdel.
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit :
[...]
So, I agree with you that a part of the fix can also be applied
to the plain win32 target, but I do not think that we can avoid
all the "#ifdef __CYGWIN__" switches.
Maybe not all but any which can be deleted is good. Is there a simple
way to check at runtime if we are running in a cygwin environment?
If yes, this check could be used as a replacement for the #ifdef,
couldn't it? (I hate #ifdef ;-))
The following C program prints "I am a cygwin app" when compiled with
the cygwin gcc, and "I am a native win32 app" when compiled with mingw
(-mno-cygwin, in my case).
#include
#include
int main(void)
{
if (access("/cygdrive", F_OK) == 0)
puts("I am a cygwin app");
else
puts("I am a native win32 app");
return 0;
}
Ok, so the function would something like:
#include
bool isCygwin()
{
return access("/cygdrive", F_OK) == 0;
}
Just for confirmation, is /cygdrive is present on any cygwin installation?
But in the special case where a user has a c:\cygdrive and lyx is
installed on the same drive, this test doesn't work (I just made the
test). Is there any other way?
I think I can also tweak os_win32.C, but I do not dare to do that
without permission. I dared to modify the cygwin target because it
was my impression that it was being left behind and I didn't want
it going down the sink like the OS2 target...
Message to the main lyx developers:
IMHO, if you want to encourage new contributions, you should relax a bit
the implicit process of reviewing for trunk. I think that external
developers are feeling very scared (I am for non-qt4) and this fact can
stop them from further contribution. So instead of discussing during a
month or two some patches, why not commit the patches (if they don't
make lyx crash) and work from that point? It's easy enough to revert a
change with SVN if a patch is obviously wrong. IMHO, from the new
developer point of view, it is much easier to work this way. And _I_
think that the SVN history is much better than the mailing archive in
order to know why this or that patch has evolved.
Well, Angus is "retired", at least that's what he says ;-)... I am sure
that Michael Gerz would be happy and _I_ would happy that you take the
leadership for the windows platform :-). That makes the count for
potential windows developers, or did I forget somebody? Also I am very
short of time these days and you seem to have a lot knowledge in all
that stuff. Once your cygwin patch is accepted for 1.4.x, I would
suggest that you base your work against trunk.
What do you think?
I think I should be considered in the same position as Angus ;-)
I cannot assure neither a continuous commitment nor a prompt reply
to the list, due to my workload. Anyway, it is fun for me and I find
that I am spending some night hours on the LyX sources. It seems
that LyX has some addictive effect ;-)
I know the feeling ;-)
Then you should consider that, even if I am very proficient in C, I
should be regarded as a real C++ newbie.
Your C++ seems good enough and of course you can learn.
I also think that Michael
or you are good candidates to that leadership ;-)
As you, I don't have enough time... That said, I don't think it is
mandatory to justify for having enough free time for committing directly
to trunk. Disregard what I said about leadership, if you think you can
contribute something to os_win32.C, please do it.
Abdel.
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 01:16:56PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> >That indeed would be great, but I think that the cygwin target has
> >some peculiarities not easily mimicked by a native build.
>
> IMHO, no need to mimic anything, he who want a cygwin functionality
> should use the cygwin mode... I am not sure I am not saying something
> stupid her :-0
I don't think it's stupid. That would mean detecting at runtime if
we are a cygwin app or not. See below.
> >So, I agree with you that a part of the fix can also be applied
> >to the plain win32 target, but I do not think that we can avoid
> >all the "#ifdef __CYGWIN__" switches.
>
> Maybe not all but any which can be deleted is good. Is there a simple
> way to check at runtime if we are running in a cygwin environment?
> If yes, this check could be used as a replacement for the #ifdef,
> couldn't it? (I hate #ifdef ;-))
The following C program prints "I am a cygwin app" when compiled with
the cygwin gcc, and "I am a native win32 app" when compiled with mingw
(-mno-cygwin, in my case).
#include
#include
int main(void)
{
if (access("/cygdrive", F_OK) == 0)
puts("I am a cygwin app");
else
puts("I am a native win32 app");
return 0;
}
> >I think I can also tweak os_win32.C, but I do not dare to do that
> >without permission. I dared to modify the cygwin target because it
> >was my impression that it was being left behind and I didn't want
> >it going down the sink like the OS2 target...
>
> Well, Angus is "retired", at least that's what he says ;-)... I am sure
> that Michael Gerz would be happy and _I_ would happy that you take the
> leadership for the windows platform :-). That makes the count for
> potential windows developers, or did I forget somebody? Also I am very
> short of time these days and you seem to have a lot knowledge in all
> that stuff. Once your cygwin patch is accepted for 1.4.x, I would
> suggest that you base your work against trunk.
>
> What do you think?
I think I should be considered in the same position as Angus ;-)
I cannot assure neither a continuous commitment nor a prompt reply
to the list, due to my workload. Anyway, it is fun for me and I find
that I am spending some night hours on the LyX sources. It seems
that LyX has some addictive effect ;-)
Then you should consider that, even if I am very proficient in C, I
should be regarded as a real C++ newbie. I also think that Michael
or you are good candidates to that leadership ;-)
> Thanks for all the good explanations,
You're welcome
--
Enrico
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit : On Thu, Mar 30, 2006 at 11:01:29AM +0200, Abdelrazak Younes wrote: Enrico Forestieri a écrit : I have reviewed all (I think) possible problems related to paths in cygwin. The attached is the patch I come up with. I hope that it can be applied for 1.4.1 as it doesn't harm the other targets and is really needed for cygwin. Hello Enrico, Having had a (quick) look at your patch, it seems that some (most?) of your patch would be of benefit to non-cygwin windows user. At least they wouldn't hurt. I am in favor of getting rid of the "#ifdef __CYGWIN__" in code and creates a universal Windows binary that will work equally good (via a setting) within a Cygwin environment or not. What do you think? That indeed would be great, but I think that the cygwin target has some peculiarities not easily mimicked by a native build. IMHO, no need to mimic anything, he who want a cygwin functionality should use the cygwin mode... I am not sure I am not saying something stupid her :-0 [...] However, IMO, the cygwin_path_fix switch should also be used in os_win32.C to decide what kind of paths are to be output to .tex files, as a user should not be forced to use miktex. Agreed. [...] So, I agree with you that a part of the fix can also be applied to the plain win32 target, but I do not think that we can avoid all the "#ifdef __CYGWIN__" switches. Maybe not all but any which can be deleted is good. Is there a simple way to check at runtime if we are running in a cygwin environment? If yes, this check could be used as a replacement for the #ifdef, couldn't it? (I hate #ifdef ;-)) I think I can also tweak os_win32.C, but I do not dare to do that without permission. I dared to modify the cygwin target because it was my impression that it was being left behind and I didn't want it going down the sink like the OS2 target... Well, Angus is "retired", at least that's what he says ;-)... I am sure that Michael Gerz would be happy and _I_ would happy that you take the leadership for the windows platform :-). That makes the count for potential windows developers, or did I forget somebody? Also I am very short of time these days and you seem to have a lot knowledge in all that stuff. Once your cygwin patch is accepted for 1.4.x, I would suggest that you base your work against trunk. What do you think? Thanks for all the good explanations, Abdel.
Re: [patch] Cygwin polishing
On Thu, Mar 30, 2006 at 11:01:29AM +0200, Abdelrazak Younes wrote: > Enrico Forestieri a écrit : > >I have reviewed all (I think) possible problems related to paths in > >cygwin. The attached is the patch I come up with. I hope that it can > >be applied for 1.4.1 as it doesn't harm the other targets and is > >really needed for cygwin. > > Hello Enrico, > > Having had a (quick) look at your patch, it seems that some (most?) of > your patch would be of benefit to non-cygwin windows user. At least they > wouldn't hurt. I am in favor of getting rid of the "#ifdef __CYGWIN__" > in code and creates a universal Windows binary that will work equally > good (via a setting) within a Cygwin environment or not. > > What do you think? That indeed would be great, but I think that the cygwin target has some peculiarities not easily mimicked by a native build. For example, the "Use Cygwin-style paths" checkbox could also be provided for the plain win32 build, but, apart from the fact that the routines converting between path styles should be someway designed (they are provided by cygwin), there's a problem here. Indeed, if in a native build you use cygwin style paths, you are obliged to use only cygwin apps, as the native ones will not understand posix syntax. On the contary, with a cygwin build you can use both path styles, as cygwin apps also understand plain win32 style (it is more likely that if you use cygwin, you also have all cygwin apps). However, IMO, the cygwin_path_fix switch should also be used in os_win32.C to decide what kind of paths are to be output to .tex files, as a user should not be forced to use miktex. This is easy to do, as it simply involves changing "C:/xxx" to "/cygdrive/c/xxx" in os:latex_path and in os:internal_path when it is passed os::LATEX_FILE. The problem here would be that the "/cygdrive" prefix could be changed to anything else by the user in cygwin (unlikely but not impossible). Another problem is converting from posix to win32 style the absolute paths found in a .lyx file (perhaps produced by a cygwin LyX using cygwin-style paths), if such paths are relative to the cygwin root. For example, "/home/user/xxx" should be converted to "/home/user/xxx" and you should know what is (this info is stored in the registry, however). So, I agree with you that a part of the fix can also be applied to the plain win32 target, but I do not think that we can avoid all the "#ifdef __CYGWIN__" switches. I think I can also tweak os_win32.C, but I do not dare to do that without permission. I dared to modify the cygwin target because it was my impression that it was being left behind and I didn't want it going down the sink like the OS2 target... -- Enrico
Re: [patch] Cygwin polishing
Enrico Forestieri a écrit : I have reviewed all (I think) possible problems related to paths in cygwin. The attached is the patch I come up with. I hope that it can be applied for 1.4.1 as it doesn't harm the other targets and is really needed for cygwin. Hello Enrico, Having had a (quick) look at your patch, it seems that some (most?) of your patch would be of benefit to non-cygwin windows user. At least they wouldn't hurt. I am in favor of getting rid of the "#ifdef __CYGWIN__" in code and creates a universal Windows binary that will work equally good (via a setting) within a Cygwin environment or not. What do you think? Abdel.
