On Sunday 08 November 2009 02:00:01 rgheck wrote:
> I think Jose has been working on it here and there, but very much behind
> the scenes. My own view is that we should do one of these two things, or
> both:
After some of the current ultra-super-mega busy period is over I will post the
code I h
> On Mon, Nov 9, 2009 at 12:55 PM, Pavel Sanda wrote:
> > if you are really mind-opened to other world views, my proposal is that it
> > has
> > something to do with the design quality of the patches, than with this list
> > itself :)
>
> I did miss your review of my patch then. The only person
On 11/09/2009 09:30 AM, Jürgen Spitzmüller wrote:
Alex Fernandez wrote:
I did miss your review of my patch then. The only person that
commented on the patch offered was Jürgen, who rejected it on purely
aesthetic grounds: "I do not like the menus to be cluttered". If it is
a matter of taste
On Mon, Nov 9, 2009 at 2:41 PM, rgheck wrote:
> Well, as usual, my own response to these silly comments is to commit code
> rather than to have a pointless debate about the same issue all over again.
Yeah, you have never been known for trolling incessantly in public, or
(lately) to smear other pe
Alex Fernandez wrote:
> I did miss your review of my patch then. The only person that
> commented on the patch offered was Jürgen, who rejected it on purely
> aesthetic grounds: "I do not like the menus to be cluttered". If it is
> a matter of taste then I don't see why it can't be discussed furthe
On Mon, Nov 9, 2009 at 12:55 PM, Pavel Sanda wrote:
> if you are really mind-opened to other world views, my proposal is that it has
> something to do with the design quality of the patches, than with this list
> itself :)
I did miss your review of my patch then. The only person that
commented o
On 11/09/2009 06:55 AM, Pavel Sanda wrote:
to read another accusations on our heads after just renouncing work on the
convertors patch from Juergen is somewhat absurd.
Well, as usual, my own response to these silly comments is to commit
code rather than to have a pointless debate about the
Alex Fernandez wrote:
> On Sun, Nov 8, 2009 at 10:06 PM, rgheck wrote:
> >> What is for sure, however, is that warming up this discussion again and
> >> again will not help getting it ready either.
> >
> > Complaints do not do much good, no.
>
> On the contrary, they are the only way to improveme
On 2009-11-06, rgheck wrote:
> On 11/06/2009 05:10 AM, Guenter Milde wrote:
>> On 2009-11-06, rgheck wrote:
...
>> * People that do not like elyxer are advised not to install (or to
>>remove/disable it). For the above reasons this is much easier than
>>removing htlatex.
> How about just
On Sun, Nov 8, 2009 at 10:06 PM, rgheck wrote:
>> What is for sure, however, is that warming up this discussion again and
>> again will not help getting it ready either.
>
> Complaints do not do much good, no.
On the contrary, they are the only way to improvement. But they need
people with open e
On 11/08/2009 04:07 AM, Jürgen Spitzmüller wrote:
Alex Fernandez wrote:
Richard was talking about 1.7, but unfortunately we cannot be sure
that it will be ready for the 1.7 timeframe either.
You're right, we cannot be sure it will be ready.
I doubt we can be sure of anything oth
Uwe Stöhr wrote:
> Sorry for my mistake here. You are right this should go in for branch.
> Jürgen?
OK.
Jürgen
On Sun, Nov 8, 2009 at 6:20 PM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> What I don't understand (and I am sure I am not alone in this) is why
>> not go for the easy solution now, just for branch. This would solve
>> the problem for 1.6.x while leaving the field open for the good
>> lo
Alex Fernandez schrieb:
By the way, when I submitted the patch it worked against trunk, but
not against branch -- since trunk uses log() and branch is still using
print "". So a version which worked against both necessarily had to
remove the log messages. The attached patch restores the log mess
Alex Fernandez wrote:
> What I don't understand (and I am sure I am not alone in this) is why
> not go for the easy solution now, just for branch. This would solve
> the problem for 1.6.x while leaving the field open for the good
> long-term solution for 1.7. Attached is a patch which does just tha
On Sun, Nov 8, 2009 at 10:07 AM, Jürgen Spitzmüller wrote:
> You're right, we cannot be sure it will be ready. But the chances are not bad
> that it will. It depends on how difficult the integration of multiple
> converter chains in the exportableFormats() / getReachable() methods, and it
> essent
On Fri, Nov 6, 2009 at 8:49 PM, Uwe Stöhr wrote:
> I only want to have the patch in to make configure.py again work on all
> platforms. Please discuss all other issues on the list so that everybody can
> participate, no matter if this produces more "heat". My understanding of
> democracy is that
Alex Fernandez wrote:
> Richard was talking about 1.7, but unfortunately we cannot be sure
> that it will be ready for the 1.7 timeframe either.
You're right, we cannot be sure it will be ready. But the chances are not bad
that it will. It depends on how difficult the integration of multiple
con
On 11/07/2009 06:59 PM, Vincent van Ravesteijn wrote:
1.7 equals 2.0, we decided to change the version number,
Did we ?
I thought it was related to the XML-transition, but this seems to be a
rather vague plan that no-one is working on (I hope I don't offend
anyone). I'd almost think we can
On 11/07/2009 06:50 PM, Pavel Sanda wrote:
Alex Fernandez wrote:
Then I misunderstood, probably because your statement was part of a response
to Richard talking about trunk and my approach (look at the text I quoted).
Richard was talking about 1.7, but unfortunately we cannot be sur
Vincent van Ravesteijn wrote:
>
>> 1.7 equals 2.0, we decided to change the version number,
> Did we ?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg152783.html
> I thought it was related to the XML-transition,
exactly.
>but this seems to be a
> rather vague plan that no-one is worki
1.7 equals 2.0, we decided to change the version number,
Did we ?
I thought it was related to the XML-transition, but this seems to be a
rather vague plan that no-one is working on (I hope I don't offend
anyone). I'd almost think we can prepare for 1.8..etc. if that's the
criterium (althoug
Alex Fernandez wrote:
> > Then I misunderstood, probably because your statement was part of a response
> > to Richard talking about trunk and my approach (look at the text I quoted).
>
> Richard was talking about 1.7, but unfortunately we cannot be sure
> that it will be ready for the 1.7 timefram
On Sat, Nov 7, 2009 at 6:34 PM, Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
>> I meant that only different formats can solve it for now (LyX 1.6.x). So
>> what Alex said is exactly what I meant.
>
> Then I misunderstood, probably because your statement was part of a response
> to Richard talkin
Uwe Stöhr wrote:
> I meant that only different formats can solve it for now (LyX 1.6.x). So
> what Alex said is exactly what I meant.
Then I misunderstood, probably because your statement was part of a response
to Richard talking about trunk and my approach (look at the text I quoted).
Jürgen
> Uwe suggested that he thinks _only_ different
> formats can solve the problem, not my approach.
I meant that only different formats can solve it for _now_ (LyX 1.6.x). So what Alex said is exactly
what I meant.
regards Uwe
Alex Fernandez wrote:
> > Why don't you think my approach does not solve this?
>
> Let me answer that. Your approach is a long-term solution to the
> problem (for the 1.7 or 2.0 timeframe),
We were talking about trunk. Uwe suggested that he thinks _only_ different
formats can solve the problem,
On Sat, Nov 7, 2009 at 9:55 AM, Jürgen Spitzmüller wrote:
> Uwe Stöhr wrote:
>> > Fortunately, Jürgen's work will improve this situation a good deal for
>> > 1.7. But we still have, and will still have, the question what should be
>> > the default.
>>
>> This issue can only be solved by treating t
Uwe Stöhr wrote:
> > Fortunately, Jürgen's work will improve this situation a good deal for
> > 1.7. But we still have, and will still have, the question what should be
> > the default.
>
> This issue can only be solved by treating the HTML converters like we
> already treat the PDF converters.
On Fri, Nov 6, 2009 at 4:09 AM, rgheck wrote:
> These kinds of things matter. And given that elyxer still has some pretty
> severe limitations converting quite simple LyX documents, which htlatex does
> not have, at least on Linux, I'm a bit puzzled why we use elyxer as the
> default. I understand
On 11/05/2009 07:41 PM, Uwe Stöhr wrote:
The last weeks Alex and me were heavily busy finding a solution to
support eLyXer via configure.py that works on all systems and platforms.
The solution is a modificated version of the one that was proposed by
Alex on this list some weeks ago: first che
The last weeks Alex and me were heavily busy finding a solution to support eLyXer via configure.py
that works on all systems and platforms.
The solution is a modificated version of the one that was proposed by Alex on this list some weeks
ago: first check if eLyXer is installed as Python module
32 matches
Mail list logo
