Leuven, E. wrote:
> maybe time to buy a new laptop?
Oh yes. Please :-)
Jürgen
Jürgen wrote:
> Leuven, E. wrote:
>> i understand that backward output compatibility was convenient, but you
>> must admit that these are not typical use cases
>
> What is "typical"? These cases are much more typical for me than the case
> outline by you. So it just depends on the user's context.
Leuven, E. wrote:
> i understand that backward output compatibility was convenient, but you
> must admit that these are not typical use cases
What is "typical"? These cases are much more typical for me than the case
outline by you. So it just depends on the user's context.
> (also, in both situ
Jürgen wrote:
> Just two scenarios which I more or less found myself into in the past:
>
> 1. LyX 1.5 has a bug
> 2. my laptop refuses to work
i understand that backward output compatibility was convenient, but you must
admit that these are not typical use cases (also, in both situations (last
Leuven, E. wrote:
> ...i would expect this to be pretty rare, so would rather suggest a --spitz
> switch ;-)
--ed ist shorter ;-)
> more seriously, when would one need backward output compatibility?
>
> i can think of a scenario when working with a co-author who doesn't have
> the latest lyx inst
Jürgen Spitzmüller wrote:
> If it's just a mode (i.e. a --edwin switch), it's o.k.
i would be honored of course, but...
> However, I think I'm not the only user who relies on backwards output
> compatibility.
...i would expect this to be pretty rare, so would rather suggest a --spitz
switch ;-)
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> If it's just a mode (i.e. a --edwin switch), it's o.k. However, I think I'm
> not the only user who relies on backwards output compatibility.
The problem of course is that it means double work...
JMarc
Jean-Marc Lasgouttes wrote:
> Before you ask, I do not have precise examples right now.
But I have ;-)
> It is just
> an impression. There were talks with tex2lyx about having a relaxed
> mode just for that.
If it's just a mode (i.e. a --edwin switch), it's o.k. However, I think I'm
not the o
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> I also think that the heavy use of ERT in reversion is going too
>> far.
>
> Why?
I am not sure we manage to preserve exact page breaks anyway. So we
try hard to preserve form, at the cost of loosing semantics.
Befor
Jean-Marc Lasgouttes wrote:
> I also think that the heavy use of ERT in
> reversion is going too far.
Why?
> What about this alternate idea: add a note in the text explaining
> what got removed. Of course, this raises the problem of
> localization...
This will trigger great fun with something li
Leuven, E. wrote:
> > So you want to remove every new feature on reversion? That's the
> > consequence of "revert to what is _natively_ supported" (your
> > interpretation, if I'm not mistaken).
>
> yes
OK. Then we remove natbib citations and replace them with numerical for v.
1.1, because we do
Jean-Marc Lasgouttes wrote:
"Leuven, E." <[EMAIL PROTECTED]> writes:
so if people think that we should litter the reverted document with
ert just because we can, so be it. but at more conceptual level i
think that this is a perverse result of the possibility of ert.
I do not know what
Leuven, E. wrote:
Jürgen Spitzmüller wrote:
Leuven, E. wrote:
as i wrote: revert to what is supported
i think that this is a clear and very standard policy
So you want to remove every new feature on reversion? That's the consequence
of "revert to what is _natively_ supported" (
"Leuven, E." <[EMAIL PROTECTED]> writes:
> so if people think that we should litter the reverted document with
> ert just because we can, so be it. but at more conceptual level i
> think that this is a perverse result of the possibility of ert.
I do not know what you are talking about, and theref
Leuven, E. wrote:
> i think that this is a clear and very standard policy
note for example that this is not the case of pdfoptions now.
we are converting our info into preamble of older .lyx files.
pavel
Jürgen Spitzmüller wrote:
> Leuven, E. wrote:
>> as i wrote: revert to what is supported
>>
>> i think that this is a clear and very standard policy
>
> So you want to remove every new feature on reversion? That's the consequence
> of "revert to what is _natively_ supported" (your interpretation,
Leuven, E. wrote:
> as i wrote: revert to what is supported
>
> i think that this is a clear and very standard policy
So you want to remove every new feature on reversion? That's the consequence
of "revert to what is _natively_ supported" (your interpretation, if I'm not
mistaken).
If you read
> Also, if we go that route, where do you draw the line?
as i wrote: revert to what is supported
i think that this is a clear and very standard policy
...
this being said, i don't care too much about this reversion stuff myself
Leuven, E. wrote:
> a case can be made though for reversion to the subset that is supported by
> lyx
>
> (for those wanting non-lossy reversion there is always export->latex)
I think we should conform to a coherent policy. And our policy for lyx2lyx
reversion used to be what I outlined. For good
>> i realize that this leads to dataloss, but in this case i definitely prefer
>> dataloss and tables i can edit in lyx to big blurs of ert and no
>> dataloss...
>
> well. I understand. But our goal with revertion to old formats is not as much
> comfortable UI but identical output (as much as poss
Leuven, E. wrote:
> i realize that this leads to dataloss, but in this case i definitely prefer
> dataloss and tables i can edit in lyx to big blurs of ert and no
> dataloss...
well. I understand. But our goal with revertion to old formats is not as much
comfortable UI but identical output (as mu
Jürgen wrote:
>>Leuven, E. wrote:
>> do we want this for 1.6 or should i wait?
>
> This is a most welcome feature, but IMHO it's too late for 1.6.
sure
> Some minor comments:
>
> * the lyx2lyx reversion leads to dataloss. Instead of just removing the
> options, you'll have to revert those tabul
ping
-Original Message-
From: Leuven, E. [mailto:[EMAIL PROTECTED]
Sent: Fri 5/16/08 13:43
To: lyx-devel@lists.lyx.org
Subject: tabular width
i've added setting the tabular width through the ui in the attached (also see
screenshot)
the patch is straightforward:
add '
Leuven, E. wrote:
> do we want this for 1.6 or should i wait?
This is a most welcome feature, but IMHO it's too late for 1.6.
> comments on the patch welcome of course
Some minor comments:
* the lyx2lyx reversion leads to dataloss. Instead of just removing the
options, you'll have to revert th
24 matches
Mail list logo
