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
