Am 04.11.2010 um 00:32 schrieb Pavel Sanda:
> Stephan Witt wrote:
> CVS improvement if info inset output is possible (after review) for
> 2.0-beta?
if its possible to make it simple and stupid using the current philosophy
then yes.
if you need to redesign things arou
Stephan Witt wrote:
> >>> CVS improvement if info inset output is possible (after review) for
> >>> 2.0-beta?
> >>
> >> if its possible to make it simple and stupid using the current philosophy
> >> then yes.
> >> if you need to redesign things around, please let it sleep, its too late.
> >
> >
Concerning this code in parser_tools.py:
def get_value(lines, token, start, end = 0, default = ""):
""" get_value(lines, token, start[[, end], default]) -> list of strings
Return tokens after token for the first line, in lines, where
token is the first element."""
i = find_toke
On 11/03/2010 04:12 PM, rgh...@lyx.org wrote:
Author: rgheck
Date: Wed Nov 3 21:12:18 2010
New Revision: 36012
URL: http://www.lyx.org/trac/changeset/36012
Log:
Fix bug #7014. The problem here is that we get DEFSKIP if we don't
recognize the argument, but that leads to an infinite loop.
T
On 11/03/2010 10:55 AM, Scott Otterson wrote:
I have a document from which latex can successfully produce a .dvi
file (latex test.tex; latex test.tex).
But when I try to import it into lyx (file-->Import-->Latex(Plain)),
lyx produces a lyx file but then hangs forever when it tries to read
it.
Jean-Pierre Chrétien a écrit :
Richard Heck a écrit :
On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote:
Jean-Pierre Chrétien a écrit :
OK, so, for the time being, anyway, we think refstyle support is
complete? Or am I misremembering some other issue?
Extra \makeatother/\makeatletter in
On Wed, Nov 3, 2010 at 4:41 PM, Pavel Sanda wrote:
> Scott Otterson wrote:
> > They write in latex only (so far), and suspect that lyx will just add
> > overhead when we transfer drafts around.
>
> if they want to stay with latex their suspiction is correct.
> lyx<->latex transfer will most proba
Scott Otterson wrote:
> They write in latex only (so far), and suspect that lyx will just add
> overhead when we transfer drafts around.
if they want to stay with latex their suspiction is correct.
lyx<->latex transfer will most probably become nigthmares for you.
pavel
They write in latex only (so far), and suspect that lyx will just add
overhead when we transfer drafts around.
Scott
On Wed, Nov 3, 2010 at 4:09 PM, Pavel Sanda wrote:
> Scott Otterson wrote:
> > Like everybody else, I'm hoping for an answer right away: Some
> colleagues
> > and I are starting
Am 03.11.2010 um 12:13 schrieb Abdelrazak Younes:
> People should have two checkout: branch and trunk, period.
I have three:
* branch,
* trunk for work and another
* trunk for trying out my patches before posting to list.
Stephan
Am 02.11.2010 um 22:43 schrieb Stephan Witt:
> Am 02.11.2010 um 19:27 schrieb Pavel Sanda:
>
>>> CVS improvement if info inset output is possible (after review) for
>>> 2.0-beta?
>>
>> if its possible to make it simple and stupid using the current philosophy
>> then yes.
>> if you need to rede
Scott Otterson wrote:
> Like everybody else, I'm hoping for an answer right away: Some colleagues
> and I are starting work on a paper, and they suspect that me using lyx will
> cause headaches -- sure enough, I have a problem on the first test. So, any
> quick workarounds will be greatly appreci
I have a document from which latex can successfully produce a .dvi
file (latex test.tex; latex test.tex).
But when I try to import it into lyx (file-->Import-->Latex(Plain)),
lyx produces a lyx file but then hangs forever when it tries to read it.
This failure happens on lyx 1.6.7 (windows); 1.6.
Am 03.11.2010 um 12:21 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> The problem with the error messages lead me to the status check
>> implementation.
>> Now it is in place I think it's much better with it then without it.
>> I'd say it should not be dropped.
>>
>> Please, ask your questions yo
On 11/03/2010 03:17 PM, Pavel Sanda wrote:
True but this is a drawback that comes from our linear development model.
As soon as we switch to "one feature = one branch" then citing branch or a
tag (don't forget that git tags are real tags) will be just fine. No more
needs to cite a commit.
Richard Heck a écrit :
On 11/02/2010 02:01 PM, Jean-Pierre Chrétien wrote:
Jean-Pierre Chrétien a écrit :
OK, so, for the time being, anyway, we think refstyle support is
complete? Or am I misremembering some other issue?
Extra \makeatother/\makeatletter in LaTeXFeatures.cpp and problem o
Abdelrazak Younes wrote:
>> there is also compromise possible - we freeze until the horrible number of
>> bugs
>> shrinks somewhat.
>>
>
> Do you have numbers? I am not sure trunk is so full of bugs when compared
> to pre-1.6 or pre-1.5... I am quite sure though that the first 1.5 or 1.6
i
On 11/03/2010 01:27 PM, Pavel Sanda wrote:
Abdelrazak Younes wrote:
It's the job of the
maintainer to recall the relevent developer his duty with regards to the
branch bug fixing. And Juergen is very goo at it. Artificially imposing a
not convincing. in many bugs its hard to decide wh
Abdelrazak Younes wrote:
> It's the job of the
> maintainer to recall the relevent developer his duty with regards to the
> branch bug fixing. And Juergen is very goo at it. Artificially imposing a
not convincing. in many bugs its hard to decide whose is in charge and they
just stay.
> limit o
Stephan Witt wrote:
> The problem with the error messages lead me to the status check
> implementation.
> Now it is in place I think it's much better with it then without it.
> I'd say it should not be dropped.
>
> Please, ask your questions you have regarding CvsStatus and I'll explain.
the dar
On 11/03/2010 12:39 AM, Pavel Sanda wrote:
Vincent van Ravesteijn wrote:
I wanted to propose to start the 2.0.x branch when you enter the
feature-freeze/beta state. This would allow to continue redesigning and
refactoring the code, because I stumble on this everytime I try to fix real
proble
Jean-Marc Lasgouttes wrote:
> Le 03/11/2010 01:23, Pavel Sanda a écrit :
>> for now my plan was to freeze any refactorizing which is for the sake of
>> clean
>> code or good architecture.
>
> OTOH, now is a good time for patches that do heavy search and replace or
> stuff like that. This would he
On Tue, Nov 02, 2010 at 07:52:05PM -0400, Richard Heck wrote:
> That said, it's fine with me if we switch trunk to >=Qt 4.4 after the split.
That is already the case, as it does not compile anymore with Qt < 4.4,
thanks to the essential export in thread feature.
--
Enrico
On 11/02/2010 11:50 PM, Pavel Sanda wrote:
Peter Kümmel wrote:
exclude it just out of lazyness. After all, there might still be some
conservative admins out there.
well, conservative admins... current release of centos has 4.2.1...
Will a conservative admin install LyX 2?
Le 03/11/2010 01:23, Pavel Sanda a écrit :
for now my plan was to freeze any refactorizing which is for the sake of clean
code or good architecture.
OTOH, now is a good time for patches that do heavy search and replace or
stuff like that. This would help future backporting of trunk fixes.
JM
Le 03/11/2010 00:52, Richard Heck a écrit :
That said, it's fine with me if we switch trunk to >=Qt 4.4 after the
split.
+1
JMarc
26 matches
Mail list logo
