> I fixed 6908, and now I should turn to tabular features. Does somebody
> have a pointer to a bug report or a list thread about that? I failed to
> find it and I would like to know what the context is.
>
The only context was bug #6908 I guess.
I realized that "INSET_MODIFY tabular delete-row" wo
Jean-Marc Lasgouttes wrote:
> Le 16/11/2010 11:55, Vincent van Ravesteijn a écrit :
>> Bug 6908 is also related to the AtPoint machinery (JMarc) and the
>> change of LFUN to LFUN_INSET_MODIFY (Abdel).
>
> I fixed 6908, and now I should turn to tabular features. Does somebody
> have a pointer to a b
Le 16/11/2010 11:55, Vincent van Ravesteijn a écrit :
Bug 6908 is also related to the AtPoint machinery (JMarc) and the
change of LFUN to LFUN_INSET_MODIFY (Abdel).
I fixed 6908, and now I should turn to tabular features. Does somebody
have a pointer to a bug report or a list thread about that?
Le 14/11/2010 01:38, Pavel Sanda a écrit :
JMarc, these two seems to have somthing in comon with you ;) : 6768 (at point
machinery), 6930 (undo broken)
These are fixed now.
JMarc
Le 22/11/2010 02:00, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
What happens if the function decides to change nothing after all? We have a
useless undo step.
so if somebody pushes ctrl+z, one step nothing happens? undo machinery could
detect and kill empty start-end undo block at the e
Jean-Marc Lasgouttes wrote:
> What happens if the function decides to change nothing after all? We have a
> useless
> undo step.
so if somebody pushes ctrl+z, one step nothing happens? undo machinery could
detect and kill empty start-end undo block at the end.
> recordUndo only applies to AtPoin
Le 18 nov. 10 à 00:53, Pavel Sanda a écrit :
The first (easy) try was to call recordUndo whenever the lfun is
not marked
readonly. However I do not like lfun relying on such behaviour from
the
dispatcher.
i didn't get why is the first solution bad. it looks less prone-to-
be-forgotten
for
Le 18 nov. 10 à 11:48, Vincent van Ravesteijn a écrit :
I added those LFUNs, so I guess I added those flags. And indeed, it
doesn't make sense.
Well, the name of the flag is not clear at all, but still, I know how
it works, so I don't know why I did this.
In the meantim, I managed to convince
> BTW, why is the following lfuns AtPoint? This is only useful if the cursor
> can be inside the inset (it may be that we should rename this flag if it is
> not clear)
>
> { LFUN_GRAPHICS_RELOAD, "graphics-reload", ReadOnly | AtPoint, Edit },
>
> { LFUN_LABEL_COPY_AS_REF, "copy-label-as-reference",
Jean-Marc Lasgouttes wrote:
>> JMarc, these two seems to have somthing in comon with you ;) : 6768 (at
>> point machinery), 6930 (undo broken)
>
> Concerning 6930, the introduction of AtPoint lead to removing a recordUndo
> call for INSET_MODIFY. Since the code is common to all AtPoint entries (a
Le 14/11/2010 01:38, Pavel Sanda a écrit :
JMarc, these two seems to have somthing in comon with you ;) : 6768 (at point
machinery), 6930 (undo broken)
Concerning 6930, the introduction of AtPoint lead to removing a
recordUndo call for INSET_MODIFY. Since the code is common to all
AtPoint en
On Sun, Nov 14, 2010 at 1:38 AM, Pavel Sanda wrote:
> hi,
>
> as we are now in beta i increased severity of bugs which are regressions
> compared to 1.6.
>
> Edwin, could you possibly look on the tabular bugs: 6908, 7021, 7007 ?
>
> JMarc, these two seems to have somthing in comon with you ;) : 6
On Tue, Nov 16, 2010 at 09:19:04AM +0100, Jean-Marc Lasgouttes wrote:
> Le 16 nov. 10 à 01:09, Enrico Forestieri a écrit :
> >On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
> >>Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
> >>>See attached patch. This solves the problem
Le 16 nov. 10 à 01:09, Enrico Forestieri a écrit :
On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
See attached patch. This solves the problem of the extra line after
\end{split}, but the code should be audited for other o
On Mon, Nov 15, 2010 at 08:41:20PM -0500, Richard Heck wrote:
> On 11/15/10 7:09 PM, Enrico Forestieri wrote:
> >On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
> >>Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
> >>>See attached patch. This solves the problem of the extra
On 11/15/10 7:09 PM, Enrico Forestieri wrote:
On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
See attached patch. This solves the problem of the extra line after
\end{split}, but the code should be audited for other occurr
On 11/15/10 7:09 PM, Enrico Forestieri wrote:
On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
See attached patch. This solves the problem of the extra line after
\end{split}, but the code should be audited for other occurr
On Tue, Nov 16, 2010 at 01:09:06AM +0100, Enrico Forestieri wrote:
> On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
> > Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
> > >See attached patch. This solves the problem of the extra line after
> > >\end{split}, but the code s
On Tue, Nov 16, 2010 at 12:01:59AM +0100, Jean-Marc Lasgouttes wrote:
> Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
> >See attached patch. This solves the problem of the extra line after
> >\end{split}, but the code should be audited for other occurrences
> >of extra newlines.
> >
> >I think
Le 15 nov. 10 à 23:48, Enrico Forestieri a écrit :
See attached patch. This solves the problem of the extra line after
\end{split}, but the code should be audited for other occurrences
of extra newlines.
I think we could also use this method for properly ending math
environments on a new line (i
On Mon, Nov 15, 2010 at 10:38:00PM +0100, Enrico Forestieri wrote:
> On Mon, Nov 15, 2010 at 11:20:34AM -0500, Richard Heck wrote:
> > On 11/13/2010 07:38 PM, Pavel Sanda wrote:
> > >perhaps Richard? - 6733 (LyX allows split environment...)
> > >
> > The only thing that can really be done here now
On Mon, Nov 15, 2010 at 11:20:34AM -0500, Richard Heck wrote:
> On 11/13/2010 07:38 PM, Pavel Sanda wrote:
> >perhaps Richard? - 6733 (LyX allows split environment...)
> >
> The only thing that can really be done here now is to try to get rid
> of that extra line after \end{split}. I don't know why
On 11/13/2010 07:38 PM, Pavel Sanda wrote:
perhaps Richard? - 6733 (LyX allows split environment...)
The only thing that can really be done here now is to try to get rid of
that extra line after \end{split}. I don't know why that is there, as I
don't know the math code at all. But I think it m
hi,
as we are now in beta i increased severity of bugs which are regressions
compared to 1.6.
Edwin, could you possibly look on the tabular bugs: 6908, 7021, 7007 ?
JMarc, these two seems to have somthing in comon with you ;) : 6768 (at point
machinery), 6930 (undo broken)
perhaps Richard? -
We have two new regression bugs:
http://bugzilla.lyx.org/show_bug.cgi?id=4430
size of view source window cannot be reduced
(must have been introduced recently)
http://bugzilla.lyx.org/show_bug.cgi?id=4431
font changes not shown in view source window
regards Uwe
25 matches
Mail list logo
