Alex Fernandez wrote:
> > They will appear if you define a viewer for them. But since they are both
> > intermediate formats (contrary to XHTML), no viewer is defined by
> > default.
>
> So removing the viewer for xhtml the menu entry will disappear?
It is supposed to, yes.
> >> Why not let us k
On Mon, Oct 26, 2009 at 8:44 AM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> DocBook does not appear in the menu, and neither does LaTeX. That it
>> was easy to add to the menu does not mean that it was necessary,
>> IMHO. Especially if we are concerned about clutter.
>
> They will appear
On 2009-10-25, Abdelrazak Younes wrote:
> As Jürgen, I would personally offer one unique default entry for
> DVI, PDF, PS and HTML
as well as the different LyX format versions (currently taking up 1/3
of the menu space) and "Plain text".
> *But* I would also make all the other available convert
Richard Heck wrote:
>>> It seems to me that a lot of the "heat" in this discussion has to do with
>>>
>> dont talk about this :) of course my default is latex2html...
>>
> No, a topic best avoided. We can expect it to re-appear in 1.7, where LyX's
it was only a joke ..
and i'm not going to
On 10/26/2009 08:47 AM, Pavel Sanda wrote:
Alex Fernandez wrote:
I will miss our little riff-raffs then. It will probably improve the
the good thing is that anytime you unleash new flame here it makes Richard
to produce new code. if his commit activity goes down, lets have some new
di
Alex Fernandez wrote:
> I will miss our little riff-raffs then. It will probably improve the
the good thing is that anytime you unleash new flame here it makes Richard
to produce new code. if his commit activity goes down, lets have some new
discussion :)
pavel
Jürgen Spitzmüller writes:
> How does this contradict with my proposal? On the contrary: all installed
> converters will (in contrast to the status quo) be preconfigured with what we
> think the best options are. They just won't be enabled by default.
I think that a combination of this and of a
Pavel Sanda wrote:
> i had two things in mind
> - how is the user going to discover the other ones. if he needs to go to
> the configuration in the pref's convertor pane then god bless him. its
> such a unintuive beast that we have even bug number for it.
> - i know one software, you wouldn't gue
Pavel Sanda wrote:
> i have never claimed my opinion to be objective. its more matter how many
> people will vote on which side.
Sure. But however the vote is going to end, we need a framework where we can
(de)select converters.
Jürgen
Abdelrazak Younes wrote:
> But I would also make all the other availble
> converters through an "export dialog" (File -> Export->Others...). In
> this dialog all converters would be listed, possibly sorted by export
> types.
Yes, why not. We could draw a distinction between view and export (and
Guenter Milde wrote:
> Still, we do provide these ways for a good reason: they have different
> strenghts and weaknesses and depending on your workflow and the actual
> document the one or another is best.
But who knows that? As long as you don't, it's just 3 different ways to get a
PDF, and peop
Alex Fernandez wrote:
> DocBook does not appear in the menu, and neither does LaTeX. That it
> was easy to add to the menu does not mean that it was necessary,
> IMHO. Especially if we are concerned about clutter.
They will appear if you define a viewer for them. But since they are both
intermedi
On Mon, Oct 26, 2009 at 1:13 AM, Pavel Sanda wrote:
> Richard Heck wrote:
>> It seems to me that a lot of the "heat" in this discussion has to do with
>
> dont talk about this :) of course my default is latex2html...
That is fine, as long as there is the possibility of running all
converters and
On Mon, Oct 26, 2009 at 12:36 AM, rgheck wrote:
> I allowed my emotions to get the better of me some weeks ago, and for that I
> have apologized already. I would urge you, as Abdel has, to let it drop.
I apologized last year for something I did, so I don't think I have to
apologize again this yea
On 10/25/2009 08:13 PM, Pavel Sanda wrote:
Richard Heck wrote:
It seems to me that a lot of the "heat" in this discussion has to do with
dont talk about this :) of course my default is latex2html...
No, a topic best avoided. We can expect it to re-appear in 1.7, where
LyX's inte
Richard Heck wrote:
> It seems to me that a lot of the "heat" in this discussion has to do with
dont talk about this :) of course my default is latex2html...
pavel
On 10/25/2009 06:28 PM, Pavel Sanda wrote:
Richard Heck wrote:
Pavel will tell us
i had two things in mind
- how is the user going to discover the other ones. if he needs to go to the
configuration
in the pref's convertor pane then god bless him. its such a unintuive beast
that w
On 25/10/2009 23:02, rgheck wrote:
On 10/25/2009 01:30 PM, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
still i think its much more embarrassing situation to persuade your
editor
to really use what you have installed on purpose than to disable if
something was installed not intentionally.
Quer
On 10/25/2009 11:15 AM, Uwe Stöhr wrote:
I didn't meant that.
Thanks, then. Sorry I got so frustrated with you. That was misdirected
frustration, I'm afraid.
I only wanted to say that native HTML export was announced a year ago
and also discussed at the last LyX developer meeting. Until now
On 10/25/2009 08:48 AM, Alex Fernandez wrote:
I was going to honor Abdel's request and let it stand, but since there
have been several further messages I think I have the right to answer,
skipping some personal comments which add nothing to the debate.
I allowed my emotions to get the better
Richard Heck wrote:
>Pavel will tell us
i had two things in mind
- how is the user going to discover the other ones. if he needs to go to the
configuration
in the pref's convertor pane then god bless him. its such a unintuive beast
that we have
even bug number for it.
- i know one software,
On 2009-10-25, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
>>still i think its much more embarrassing situation to persuade your editor
>> to really use what you have installed on purpose than to disable if
>> something was installed not intentionally.
> Query the archieves. Many LyX users are
On 10/25/2009 01:30 PM, Jürgen Spitzmüller wrote:
Pavel Sanda wrote:
still i think its much more embarrassing situation to persuade your editor
to really use what you have installed on purpose than to disable if
something was installed not intentionally.
Query the archieves. Many LyX
On 10/25/2009 01:02 PM, Jürgen Spitzmüller wrote:
Alex Fernandez wrote:
Alex Fernandez wrote:
In the meantime there has been one addition to the menu: "LyX HTML",
codename xhtml, for Richard's native HTML output. And it would seem
that it "solves a simple case". Can we interpret tha
Jürgen Spitzmüller wrote:
> I don't see why HTML converters are to be treated differently. For me,
> bibliography converters are _much_ more important than HTML converters. OTOH
> I
> have a whole lot of HTML converters installed simply because I have a TeXLive
> full install. I do not use a si
On Sun, Oct 25, 2009 at 7:02 PM, Jürgen Spitzmüller wrote:
>> No to which of the two clauses?
>
> To both. Richard needed to add his output format to the menu, since it's an
> additional backend, no converter. However, I think one should be able to hide
> that as well, if one prefers another HTML
Pavel Sanda wrote:
>still i think its much more embarrassing situation to persuade your editor
> to really use what you have installed on purpose than to disable if
> something was installed not intentionally.
Query the archieves. Many LyX users are confused by the fact that we provide
three diff
Jürgen Spitzmüller wrote:
> > even if you want to provide way how to disable them, they all should be
> > enabled by default. fundamentally - the fact that convertor is installed
> > on users system already shows the users choice.
>
> I think this is not true. The converters might have been inst
Pavel Sanda wrote:
> even if you want to provide way how to disable them, they all should be
> enabled by default. fundamentally - the fact that convertor is installed
> on users system already shows the users choice.
I think this is not true. The converters might have been installed by the
(La
Jürgen Spitzmüller wrote:
> > We haven't got to discussing that part.
>
> In my opinion, a program that lists 5 different HTML converters and that
> provides no way of reducing that list (besides uninstalling the converters)
> is
> far from being usable. A usable program should provide a sensib
Alex Fernandez wrote:
> > Alex Fernandez wrote:
> >> In the meantime there has been one addition to the menu: "LyX HTML",
> >> codename xhtml, for Richard's native HTML output. And it would seem
> >> that it "solves a simple case". Can we interpret that you have relaxed
> >> the criterion somehow,
On Sun, Oct 25, 2009 at 6:45 PM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> In the meantime there has been one addition to the menu: "LyX HTML",
>> codename xhtml, for Richard's native HTML output. And it would seem
>> that it "solves a simple case". Can we interpret that you have relaxe
Alex Fernandez wrote:
> In the meantime there has been one addition to the menu: "LyX HTML",
> codename xhtml, for Richard's native HTML output. And it would seem
> that it "solves a simple case". Can we interpret that you have relaxed
> the criterion somehow, or are there further considerations in
On Sun, Oct 25, 2009 at 6:16 PM, Pavel Sanda wrote:
> as far as view menu is concerned my taste differs from Juergen's though and
> i think there will be some more flames about final version of menu output.
> dont miss that flame once it happens again :)
I wouldn't miss it :D
Alex.
Alex Fernandez wrote:
> In other words, if elyxer.py was magically included in the SVN
> repository by elves, would it be OK _then_ to place "HTML (eLyXer)" in
> the menu?
personally i'm for listing any html converter found. svn inclusion is not
question here anyway, the entry was added because it
On Sun, Oct 25, 2009 at 5:44 PM, Pavel Sanda wrote:
> Alex Fernandez wrote:
>> In the meantime there has been one addition to the menu: "LyX HTML",
>> codename xhtml, for Richard's native HTML output. And it would seem
>> that it "solves a simple case". Can we interpret that you have relaxed
>> th
Alex Fernandez wrote:
> In the meantime there has been one addition to the menu: "LyX HTML",
> codename xhtml, for Richard's native HTML output. And it would seem
> that it "solves a simple case". Can we interpret that you have relaxed
> the criterion somehow, or are there further considerations in
On Sun, Oct 25, 2009 at 3:43 PM, Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> I was (and still am) opposed to any proposal that either just solves a simple
> case (such as HTML converters or even only one particular HTML converter) or
> attempts to flood the menu with all possible converters.
Alex Fernandez schrieb:
Moreover, since LyX will have HTML output at some point soon, we do not see
the point of adding elyxer to svn only then to remove it as redundant or
unmaintained.
Do you have a date? I think Uwe's calification of vaporware is not at
all unwarranted:
http://en.wikipedi
Jürgen Spitzmüller wrote:
> I was (and still am) opposed to any proposal that either just solves a simple
> case (such as HTML converters or even only one particular HTML converter) or
> attempts to flood the menu with all possible converters.
>
> My proposal was to let the user configure which
Pavel Sanda wrote:
> i can't remember this rejection, but at least from my pov this is not bad
> idea. searching for a few seconds in the archive i only found Richard
> already stating we need this. or Juergen was against?
I was (and still am) opposed to any proposal that either just solves a si
Alex Fernandez wrote:
> On Sun, Oct 25, 2009 at 2:43 PM, Pavel Sanda wrote:
> > Alex Fernandez wrote:
> >> while with
> >> PDF LyX states clearly that it is using pdflatex or ps2pdf, with HTML
> >> it doesn't say if it's eLyXer, htlatex or what. Also, once it finds
> >> one HTML tool it doesn't re
On Sun, Oct 25, 2009 at 2:43 PM, Pavel Sanda wrote:
> Alex Fernandez wrote:
>> while with
>> PDF LyX states clearly that it is using pdflatex or ps2pdf, with HTML
>> it doesn't say if it's eLyXer, htlatex or what. Also, once it finds
>> one HTML tool it doesn't recognize other tools, so users can'
I was going to honor Abdel's request and let it stand, but since there
have been several further messages I think I have the right to answer,
skipping some personal comments which add nothing to the debate.
On Sat, Oct 24, 2009 at 7:03 PM, rgheck wrote:
> And I am not getting any help with HTML o
Alex Fernandez wrote:
> From my point of view there is the related issue that I don't like the
> way conversion is done from within LyX in 1.6.x or in 2.x: while with
> PDF LyX states clearly that it is using pdflatex or ps2pdf, with HTML
> it doesn't say if it's eLyXer, htlatex or what. Also, once
Uwe Stöhr wrote:
> I fully understand you here but don't understand why this is a reason for
> not allowing Alex to do his work in our SVN. Alex and you have different
> opinions about the HTML handling, so why not giving everybody the right to
> develop his idea?
because we should develop one
On 10/24/2009 01:41 PM, Uwe Stöhr wrote:
rgheck schrieb:
The fact is that we currently don't have a feature that generates
HTML. Our native HTML export is, strictly spoken, currently vapor
ware. We currently don't have something better than eLyXer so why
are you opposed to it?
First of all,
On 10/24/2009 01:12 PM, Abdelrazak Younes wrote:
On 24/10/2009 19:03, rgheck wrote:
Packaging is of course a different issue. But is LyX a dependency of
elyxer or not? Alex insists it shouldn't be. That, indeed, is
supposed to be a large part of the point: elxyer can do its thing
even if LyX i
rgheck schrieb:
The fact is that we currently don't have a feature that generates
HTML. Our native HTML export is, strictly spoken, currently vapor
ware. We currently don't have something better than eLyXer so why are
you opposed to it?
First of all, I am sick and effing tired of these sorts
On 24/10/2009 19:03, rgheck wrote:
Packaging is of course a different issue. But is LyX a dependency of
elyxer or not? Alex insists it shouldn't be. That, indeed, is supposed
to be a large part of the point: elxyer can do its thing even if LyX
isn't installed. (See his last umpteen massages, pa
On 10/24/2009 11:11 AM, Uwe Stöhr wrote:
I don't understand your concerns: Whether eLyXer's approach is the
right one to generate HTML out of a LyX file or not doesn't currently
matter.
The fact is that we currently don't have a feature that generates
HTML. Our native HTML export is, strictly s
On 10/24/2009 11:50 AM, Alex Fernandez wrote:
On Sat, Oct 24, 2009 at 2:25 PM, rgheck wrote:
We are sorry if you find us "unwelcoming". But we (indeed, and specifically,
I) have tried to encourage your participation in many different ways, only
to be told, each time, that you are going to d
On 10/24/2009 10:30 AM, Alex Fernandez wrote:
On Fri, Oct 23, 2009 at 4:01 PM, Guenter Milde wrote:
PS: I am very glad the tone of the discussion improved considerably
in this round. Thanks!
Probably because we were missing Richard's input, now things are as they should
be. Thanks!
On Sat, Oct 24, 2009 at 2:25 PM, rgheck wrote:
> We are sorry if you find us "unwelcoming". But we (indeed, and specifically,
> I) have tried to encourage your participation in many different ways, only
> to be told, each time, that you are going to do things on your terms or not
> at all.
That h
Dear colleagues,
I don't understand your concerns: Whether eLyXer's approach is the right one to generate HTML out of
a LyX file or not doesn't currently matter.
The fact is that we currently don't have a feature that generates HTML. Our native HTML export is,
strictly spoken, currently vapor w
On Fri, Oct 23, 2009 at 4:01 PM, Guenter Milde wrote:
> PS: I am very glad the tone of the discussion improved considerably
> in this round. Thanks!
Probably because we were missing Richard's input, now things are as
they should be. Thanks!
Alex.
On 10/24/2009 06:48 AM, Alex Fernandez wrote:
On Sat, Oct 24, 2009 at 1:19 AM, Pavel Sanda wrote:
if its just a question of misunderstanding i can rephrase it clearly:
the code which converts HTML directly from .lyx files is not easy
maintainable in a sense that it needs manual checks/fixes
On 10/23/2009 03:38 PM, Alex Fernandez wrote:
On Fri, Oct 23, 2009 at 12:36 AM, rgheck wrote:
Producing HTML output by parsing LyX documents is what eLyXer does. It
has so far proved to be an interesting challenge, and in my biased
opinion the results are better than any TeX->HTML converter
On Sat, Oct 24, 2009 at 1:19 AM, Pavel Sanda wrote:
> if its just a question of misunderstanding i can rephrase it clearly:
> the code which converts HTML directly from .lyx files is not easy
> maintainable in a sense that it needs manual checks/fixes any time
> we change output format, while prod
Alex Fernandez wrote:
> > now this is nothing against you personally - its true for all devs here -
> > when
> > one is looks on the lyx project from a wider time range developers come and
> > leave and you will have hard time to find most of devs which were 10 years
> > before on this list. but t
On Fri, Oct 23, 2009 at 11:05 PM, Pavel Sanda wrote:
> at least by me this was considered and in fact was starting point of some
> doubting. project, which you may not be aware of
> (http://www.netmeister.org/apps/lyx2html/), was triggering in me the feeling
> that history is repeating again. one
Alex Fernandez wrote:
> But there is an additional consequence not usually considered by LyX
> developers: since "eLyXer state" is independent of "LyX state", and
> much simpler, eLyXer enables new uses for "LyX format" (i.e. .lyx
> files) for people that won't or can't install LyX. Examples: remot
2009/10/23 rgheck :
> Yes, that's exactly right. If we expect lyx2lyx to be used (more) from
> outside LyX, then it (or a link) should be installed into the path.
At least, LyX could set the PATH (does it already?) to add scripts/,
and maybe also,
the python path to add lyx2lyx/. This would allow
On Fri, Oct 23, 2009 at 12:36 AM, rgheck wrote:
>> Producing HTML output by parsing LyX documents is what eLyXer does. It
>> has so far proved to be an interesting challenge, and in my biased
>> opinion the results are better than any TeX->HTML converters or than
>> native HTML output from within
On 10/23/2009 09:57 AM, Guenter Milde wrote:
On 2009-10-22, rgheck wrote:
The best solution, it seems to me, would be for elyxer to read the
format line and, if it is not to its liking, then it can call lyx2lyx
itself. But I'd guess this would be difficult to implement, since
finding lyx2ly
On 2009-10-22, rgheck wrote:
> On 10/22/2009 05:04 PM, Alex Fernandez wrote:
>> On Thu, Oct 22, 2009 at 12:39 AM, Pavel Sanda wrote:
I do remember that the last time there was some opposition to this
integration, so I would prefer to hear some more opinions first.
>>> i dont think you
On 2009-10-22, rgheck wrote:
> On 10/22/2009 05:53 PM, Alex Fernandez wrote:
>> On Thu, Oct 22, 2009 at 10:25 AM, Jean-Marc Lasgouttes
>> wrote:
>>> Le 22/10/2009 09:29, Abdelrazak Younes a écrit :
Right, it is different here as eLyXer cannot rely on LyX to do the
conversion. But it sh
Pavel Sanda writes:
> from users pov this would be regression. when its thirdparty tool,
> we dont have reasponsibility for it, once we provide it officially
> the complaints go to our shoulders. resolving the regression bugs
> by removing the feature is not the way we want go imho.
+1
JMarc
Alex Fernandez wrote:
> > and it would be pita to adjust or check the script for every
> > fileformat change we do - now this pita is yours, once we
> > officially include elyxer and you disappear after two or three
> > years the pita is ours :)
>
> But it is not a PITA, it is a rewarding job. If
Uwe Stöhr schrieb:
The attached patch runs elyer.py from the bin folder of LyX (the folder
where the lyx.exe resides). Does the patch work also on Linux?
Alex?
Attached is a better version that copies the image files to the correct temp
sub folder.
p.s. I think I found the ext_copy.py probl
On 10/22/2009 05:04 PM, Alex Fernandez wrote:
On Thu, Oct 22, 2009 at 12:39 AM, Pavel Sanda wrote:
I do remember that the last time there was some
opposition to this integration, so I would prefer to hear some more
opinions first.
i dont think you will hear anything new - the basic
On 10/22/2009 05:53 PM, Alex Fernandez wrote:
On Thu, Oct 22, 2009 at 10:25 AM, Jean-Marc Lasgouttes
wrote:
Le 22/10/2009 09:29, Abdelrazak Younes a écrit :
Right, it is different here as eLyXer cannot rely on LyX to do the
conversion. But it should be pretty easy to add a call to l
On Thu, Oct 22, 2009 at 10:25 AM, Jean-Marc Lasgouttes
wrote:
> Le 22/10/2009 09:29, Abdelrazak Younes a écrit :
>>
>> Right, it is different here as eLyXer cannot rely on LyX to do the
>> conversion. But it should be pretty easy to add a call to lyx2lyx before
>> conversion.
>
> Yes. Alex, what i
On Thu, Oct 22, 2009 at 12:39 AM, Pavel Sanda wrote:
>>I do remember that the last time there was some
>> opposition to this integration, so I would prefer to hear some more
>> opinions first.
>
> i dont think you will hear anything new - the basic issue stands
> exactly the same as in the beginin
Le 22/10/2009 09:29, Abdelrazak Younes a écrit :
Right, it is different here as eLyXer cannot rely on LyX to do the
conversion. But it should be pretty easy to add a call to lyx2lyx before
conversion.
Yes. Alex, what is your take on this these days?
JMarc
Jean-Marc Lasgouttes wrote:
Le 22/10/2009 09:04, Abdelrazak Younes a écrit :
it is wrong idea to produce html output by parsing .lyx native format
and it would be pita to adjust or check the script for every
fileformat change we do - now this pita is yours, once we
officially include elyxer and
Le 22/10/2009 09:04, Abdelrazak Younes a écrit :
it is wrong idea to produce html output by parsing .lyx native format
and it would be pita to adjust or check the script for every
fileformat change we do - now this pita is yours, once we
officially include elyxer and you disappear after two or th
Pavel Sanda wrote:
I do remember that the last time there was some
opposition to this integration, so I would prefer to hear some more
opinions first.
i dont think you will hear anything new - the basic issue stands
exactly the same as in the begining:
it is wrong idea to produce html out
Alex Fernandez wrote:
> On Wed, Oct 21, 2009 at 1:52 PM, Uwe Stöhr wrote:
> >> No matter what I may have said before, I would love eLyXer to be
> >> included in LyX. There are some practical problems but nothing that
> >> could not probably be solved.
> >
> > So please ask JMarc to get SVN access
Alex Fernandez schrieb:
Just consider that on Linux (e.g. Debian) package installation is
completely different: each package places a binary in /usr/bin, and
they are all supposed to work together without making any copies
anywhere. That is why the execution path is so important on Linux.
>>
Y
On Wed, Oct 21, 2009 at 1:52 PM, Uwe Stöhr wrote:
>> No matter what I may have said before, I would love eLyXer to be
>> included in LyX. There are some practical problems but nothing that
>> could not probably be solved.
>
> So please ask JMarc to get SVN access and upload it afterwards.
I don't
Alex Fernandez schrieb:
This works. I never had elyxer.py in another folder. configure.py also finds
the other scripts in the scripts folder, so why shouldn't it find elyxer.py?
As a matter of fact, configure.py does not _find_ the other scripts;
You are right. The Win installer adds the scr
Uwe Stöhr wrote:
> I don't agree. Those few users can copy the elyxer.py file to the scripts
> folder and everything will work.
No, we do not force a specific place where the elyxer script has to be
places. The script should also be usable if it's in the PATH.
Jürgen
Hi again,
On Wed, Oct 21, 2009 at 12:26 AM, Uwe Stöhr wrote:
> This works. I never had elyxer.py in another folder. configure.py also finds
> the other scripts in the scripts folder, so why shouldn't it find elyxer.py?
As a matter of fact, configure.py does not _find_ the other scripts;
it merel
Alex Fernandez schrieb:
This is not what I understand from the code. It seems to look for
elyxer.py in all execution paths known to Python, not to LyX. On
Windows these include all Windows execution paths (the %PATH%
variable).
It first looks at the paths known by LyX and then at the paths lis
Hi Uwe,
On Tue, Oct 20, 2009 at 10:47 PM, Uwe Stöhr wrote:
> This is not correct. The code looks for a file named elyxer.py. This can
> only be found when it is in a path known by LyX. That means that it has to
> be somewhere in LyX's subfolders. Other folders aren't possible since the
> installe
> The switch is there. What I see is that with the patch LyX is going to
> look for two executables in the path: elyxer.py or elyxer:
> +path, elyxer = checkProg('a LyX -> HTML converter',
['elyxer.py','elyxer'],
> and then it is going to execute a different elyxer.py from the scripts
> direc
Alex Fernandez wrote:
> The switch is there. What I see is that with the patch LyX is going to
> look for two executables in the path: elyxer.py or elyxer:
> +path, elyxer = checkProg('a LyX -> HTML converter', ['elyxer.py',
> 'elyxer'],
> and then it is going to execute a different elyxer.py f
On Mon, Oct 19, 2009 at 9:47 AM, Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
>> The following path is needed for configure.py to make eLyXer working
>> properly. OK to go in? (It is already in trunk for some weeks.)
>
> So the directory switch has become obsolete? I remember it was introduced i
Uwe Stöhr wrote:
> No it is still there, see my patch.
I see. OK.
Jürgen
> So the directory switch has become obsolete?
No it is still there, see my patch.
regards Uwe
Uwe Stöhr wrote:
> The following path is needed for configure.py to make eLyXer working
> properly. OK to go in? (It is already in trunk for some weeks.)
So the directory switch has become obsolete? I remember it was introduced in
order to fix some problems with images.
Alex?
Jürgen
The following path is needed for configure.py to make eLyXer working properly. OK to go in? (It is
already in trunk for some weeks.)
regards Uwe
Index: configure.py
===
--- configure.py (revision 31668)
+++ configure.py (working cop
93 matches
Mail list logo
