Uwe Stöhr wrote:
> But what will we do for LyX 2.0 instead?
the issue has been silent for years, it has not been raised when i asked about
things for 2.0, it had not 2.0 milestone -- so why the urgency right now?
when thinking about the whole stuff, not only insetinfo conversion seems to be
the r
> yes, i'm repetitive but what can i do ;)
Nothing ;-) I was aware that I introduced a hard-coding. But the info from the bug report lead me to
this to make documents at least compilable.
> for this moment i will ask for revert.
Fine with me.
But what will we do for LyX 2.0 instead?
regards
Jean-Marc Lasgouttes wrote:
> We should really have a strict policy for new hardcoding, i.e. make it
> forbidden
> by default.
it would be enough if patches are discuscussed before committed.
yes, i'm repetitive but what can i do ;)
for this moment i will ask for revert.
pavel
Le 2 déc. 2010 à 15:29, Vincent van Ravesteijn a écrit :
We should really have a strict policy for new hardcoding, i.e. make it forbidden
>> by default.
>>
>
> Yes, you mean we can clear up half of the src/insets/*.cpp code if we
> use layouts and generalisation more.
Agreed, but this is not wha
> We should really have a strict policy for new hardcoding, i.e. make it
> forbidden
> by default.
>
Yes, you mean we can clear up half of the src/insets/*.cpp code if we
use layouts and generalisation more.
Vincent
Le 2 déc. 2010 à 15:11, Pavel Sanda a écrit :
> ugh. instead of hardcoding such hacks we should go for date inside
> insetinfo...
Yes, or have date use a fancy python script.
We should really have a strict policy for new hardcoding, i.e. make it forbidden
by default.
JMarc
uwesto...@lyx.org wrote:
> Author: uwestoehr
> Date: Thu Dec 2 05:05:35 2010
> New Revision: 36654
> URL: http://www.lyx.org/trac/changeset/36654
>
> Log:
> ExternalSupport.cpp: fix #4398 (omit the newline in the LaTeX output behind
> the ExternalInset inset if the inset type is a date)
>
> Mod
