On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:
> Enrico, could you have possibly look on bug #7186 when you are after
> forw/rev search now? thats much worse issue and i have really no time
> on it
Fixed at r37602.
--
Enrico
On Thu, Feb 10, 2011 at 10:02:18PM +0100, Pavel Sanda wrote:
>
> Enrico, could you have possibly look on bug #7186 when you are after
> forw/rev search now? thats much worse issue and i have really no time
> on it
It's not any better here, but I'll try to have a look.
--
Enrico
Enrico Forestieri wrote:
> Given that the patch is quite strightforward, is more accurate in
> the line counting task, does not introduce regressions, and can be
> seen as the completion of previous work, I am going to commit it.
Enrico, could you have possibly look on bug #7186 when you are after
On Thu, Feb 10, 2011 at 01:58:07AM +0100, Enrico Forestieri wrote:
>
> I have a working patch (see attached). It integrates texrow with
> otexstream and the line counting is thus automatic. I tested it
> quite thoroughly, and it seems to be better than what we have now,
> in the sense that it seem
On Sun, Jan 30, 2011 at 05:16:32PM +0100, Enrico Forestieri wrote:
> On Sat, Jan 29, 2011 at 03:56:57AM +0100, Enrico Forestieri wrote:
>
> > On Fri, Jan 28, 2011 at 11:48:52PM +0100, Jean-Marc Lasgouttes wrote:
> >
> > > Le 28 janv. 2011 à 22:55, Enrico Forestieri a écrit :
> > > >> I can do th
On Sat, Jan 29, 2011 at 03:56:57AM +0100, Enrico Forestieri wrote:
> On Fri, Jan 28, 2011 at 11:48:52PM +0100, Jean-Marc Lasgouttes wrote:
>
> > Le 28 janv. 2011 à 22:55, Enrico Forestieri a écrit :
> > >> I can do this for you, if you wish.
> > >
> > > Thanks Richard. Let's try to coordinate th
On Fri, Jan 28, 2011 at 11:48:52PM +0100, Jean-Marc Lasgouttes wrote:
> Le 28 janv. 2011 à 22:55, Enrico Forestieri a écrit :
> >> I can do this for you, if you wish.
> >
> > Thanks Richard. Let's try to coordinate the change, then.
>
> This part of your patch can go in separately, actually.
I
Le 28 janv. 2011 à 22:55, Enrico Forestieri a écrit :
>> I can do this for you, if you wish.
>
> Thanks Richard. Let's try to coordinate the change, then.
This part of your patch can go in separately, actually.
JMarc
On Fri, Jan 28, 2011 at 11:54:23AM -0500, Richard Heck wrote:
> On 01/28/2011 10:39 AM, Enrico Forestieri wrote:
> >On Fri, Jan 28, 2011 at 03:57:04PM +0100, Jean-Marc Lasgouttes wrote:
> >>Le 28 janv. 2011 à 11:57, Enrico Forestieri a écrit :
> We should maybe have a tag 'Display 1' indicatin
On 01/28/2011 10:39 AM, Enrico Forestieri wrote:
On Fri, Jan 28, 2011 at 03:57:04PM +0100, Jean-Marc Lasgouttes wrote:
Le 28 janv. 2011 à 11:57, Enrico Forestieri a écrit :
We should maybe have a tag 'Display 1' indicating whether an environment
stands on its own (like lists) or not.
On Fri, Jan 28, 2011 at 03:57:04PM +0100, Jean-Marc Lasgouttes wrote:
> Le 28 janv. 2011 à 11:57, Enrico Forestieri a écrit :
> >> We should maybe have a tag 'Display 1' indicating whether an environment
> >> stands on its own (like lists) or not.
> >
> > I also implemented this and used it for Co
Le 28 janv. 2011 à 11:57, Enrico Forestieri a écrit :
>> We should maybe have a tag 'Display 1' indicating whether an environment
>> stands on its own (like lists) or not.
>
> I also implemented this and used it for Comment and GreyedOut notes.
This requires a layout format bump.
> Please try th
Le 27 janv. 2011 à 21:46, Enrico Forestieri a écrit :
> My question is: should we accept the insertion of the extra spaces
> or should we do the right but ugly thing?
>
> I need an answer to this question before going on with the patch,
> because the answer will affect the way the otexstream class
On Wed, Jan 26, 2011 at 11:07:36PM +0100, Jean-Marc Lasgouttes wrote:
> Le 26 janv. 2011 à 22:10, Enrico Forestieri a écrit :
>
> > On Wed, Jan 26, 2011 at 09:52:39PM +0100, Jean-Marc Lasgouttes wrote:
> >
> > Yep, but an explicit method also helps in the line counting task,
> > otherwise YA meth
Le 26 janv. 2011 à 22:10, Enrico Forestieri a écrit :
> On Wed, Jan 26, 2011 at 09:52:39PM +0100, Jean-Marc Lasgouttes wrote:
>
> Yep, but an explicit method also helps in the line counting task,
> otherwise YA method has to be called to get that info. Currently it
> is done such as "lines = os.c
On Wed, Jan 26, 2011 at 09:52:39PM +0100, Jean-Marc Lasgouttes wrote:
> Le 26 janv. 2011 à 20:55, Enrico Forestieri a écrit :
> >> I would have preferred a more explicit syntax like
> >> os << breakl << "\\begin"
> >> and have all explicit \n be output.
> >
> > Hmm... iomanip's work at a lower lev
Le 26 janv. 2011 à 20:55, Enrico Forestieri a écrit :
>> I would have preferred a more explicit syntax like
>> os << breakl << "\\begin"
>> and have all explicit \n be output.
>
> Hmm... iomanip's work at a lower level and that is a simple wrapper
> around an output stream. You are however right t
On Wed, Jan 26, 2011 at 05:10:53PM +0100, Jean-Marc Lasgouttes wrote:
> Le 26/01/2011 16:37, Pavel Sanda a écrit :
> >Enrico Forestieri wrote:
> >>As already said, the class is simply a wrapper around odocstream, so it
> >>should be safe
> >
> >i see one possible collision. we maintain TeXRow struc
On Wed, Jan 26, 2011 at 05:24:24PM +0100, Jean-Marc Lasgouttes wrote:
> Le 26/01/2011 17:13, Pavel Sanda a écrit :
> >Enrico Forestieri wrote:
> >>No, I already tried to audit that. The only possibility of missing
> >>a newline would be when outputing "\nblabla", i.e., when the '\n'
> >>is the firs
Le 26/01/2011 17:19, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
Actually, I think texrow should be integrated inside the otexstream. But
this is more work, of course.
does not this object disappear after export?
anyway the only good excuse to refactorize texrow now is #7186...
At leas
Le 26/01/2011 17:13, Pavel Sanda a écrit :
Enrico Forestieri wrote:
No, I already tried to audit that. The only possibility of missing
a newline would be when outputing "\nblabla", i.e., when the '\n'
is the first char of a string. So, checking is quite strightforward.
thanks for looking into
Jean-Marc Lasgouttes wrote:
> Actually, I think texrow should be integrated inside the otexstream. But
> this is more work, of course.
does not this object disappear after export?
anyway the only good excuse to refactorize texrow now is #7186...
pavel
Enrico Forestieri wrote:
> No, I already tried to audit that. The only possibility of missing
> a newline would be when outputing "\nblabla", i.e., when the '\n'
> is the first char of a string. So, checking is quite strightforward.
thanks for looking into this. if no other comments appear
this lo
Le 26/01/2011 16:37, Pavel Sanda a écrit :
Enrico Forestieri wrote:
As already said, the class is simply a wrapper around odocstream, so it
should be safe
i see one possible collision. we maintain TeXRow structure to keep
mapping between .lyx cursor position<-> .tex lines.
Actually, I think
On Wed, Jan 26, 2011 at 04:37:29PM +0100, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > As already said, the class is simply a wrapper around odocstream, so it
> > should be safe
>
> i see one possible collision. we maintain TeXRow structure to keep
> mapping between .lyx cursor position <-> .
Enrico Forestieri wrote:
> As already said, the class is simply a wrapper around odocstream, so it
> should be safe
i see one possible collision. we maintain TeXRow structure to keep
mapping between .lyx cursor position <-> .tex lines.
the moment you start do something magical inside newline stru
26 matches
Mail list logo
