José Matos <[EMAIL PROTECTED]> writes:
> Although it is late in the development cycle I would like to have both
> patches
> in. The last thing that I want in this type of code is to have two different
> code styles.
The patches are in.
JMarc
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> but I think it was already the
>> case before.
>
> i fail to see this...
In the sense that we always ise lyx_view_->buffer(), but we do not know
which buffer this refers to.
> anyway i went over the whole lyxfunc::dispatc
Jean-Marc Lasgouttes wrote:
> but I think it was already the
> case before.
i fail to see this... anyway i went over the whole lyxfunc::dispatch and and
checked that we don't touch buffer cache after reloadbuffer or recursive call
of dispatch. if these are the only possibilities how buffer can be
Le 21 oct. 08 à 20:43, Pavel Sanda a écrit :
Jean-Marc Lasgouttes wrote:
case LFUN_VC_CHECK_OUT:
- LASSERT(lyx_view_ && lyx_view_->buffer(), /**/);
+ LASSERT(lyx_view_ && buffer, /**/);
if (!ensureBufferClean(vie
On 21/10/2008 16:44, Jean-Marc Lasgouttes wrote:
Pavel Sanda<[EMAIL PROTECTED]> writes:
Jean-Marc Lasgouttes wrote:
Since I am a nice guy, I prepared new patches just for you.
- goodbuf-light is the one that does the useful things. It might look
simpler, but all the difficult bu
Jean-Marc Lasgouttes wrote:
> case LFUN_VC_CHECK_OUT:
> - LASSERT(lyx_view_ && lyx_view_->buffer(), /**/);
> + LASSERT(lyx_view_ && buffer, /**/);
> if (!ensureBufferClean(view()))
> break;
> -
Jean-Marc Lasgouttes wrote:
> Easy: you have 2 days to find a bug :)
nice try, but i have better things to do :D
pavel
On Tuesday 21 October 2008 15:44:40 Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> > Jean-Marc Lasgouttes wrote:
> >> Since I am a nice guy, I prepared new patches just for you.
> >>
> >> - goodbuf-light is the one that does the useful things. It might look
> >> simpler,
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Since I am a nice guy, I prepared new patches just for you.
>>
>> - goodbuf-light is the one that does the useful things. It might look
>> simpler, but all the difficult bugs are in there. Note that I added a
>> test for
Jean-Marc Lasgouttes wrote:
> Since I am a nice guy, I prepared new patches just for you.
>
> - goodbuf-light is the one that does the useful things. It might look
> simpler, but all the difficult bugs are in there. Note that I added a
> test for the validity of "buffer".
i have tested lightw
On Tuesday 21 October 2008 14:58:53 Jean-Marc Lasgouttes wrote:
> - goodbuf-extra is the one that does the trivial stuff. I am ready to
> bet a beer or two that there is 0 bug there (though I may regret
> writing that). It should be applied on top of the other one.
I am prepared to bet with yo
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> > i agree with the direction, but maybe its better to let the complete
>> > cleanup for 1.7. i'm not in a mood to test again all the cases of
>> > buffer reloading in VCS lfuns or so... for the time being i would be
>> > much
Jean-Marc Lasgouttes wrote:
> > i agree with the direction, but maybe its better to let the complete
> > cleanup for 1.7. i'm not in a mood to test again all the cases of
> > buffer reloading in VCS lfuns or so... for the time being i would be
> > much happier with some light-weight version of the
Jean-Marc Lasgouttes wrote:
> So shall I apply this flag part?
yes
pavel
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
> i agree with the direction, but maybe its better to let the complete
> cleanup for 1.7. i'm not in a mood to test again all the cases of
> buffer reloading in VCS lfuns or so... for the time being i would be
> much happier with
Pavel Sanda <[EMAIL PROTECTED]> writes:
> ok
> p
So shall I apply this flag part?
JMarc
Jean-Marc Lasgouttes wrote:
> While the current patch is not perfect (I'll post a better one soon), it
> is a step forward IMO.
>I can make a light version of the patch (which
> keeps all sorts of ugly code), but most of this code is harmless.
i agree with the direction, but maybe its better to le
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> > Jean-Marc Lasgouttes wrote:
> >> Pavel Sanda <[EMAIL PROTECTED]> writes:
> >> >> This is not supposed to modify the document IMO.
> >> >
> >> > are you sure about the insetbibtex case?
> >>
> >> The way I read the code, it j
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> Uwe Stöhr <[EMAIL PROTECTED]> writes:
>
>>> I think anyway that the patch as I posted it is safe, but as we know the
>>> devil is in the details.
>>
>> Why do you still think it is safe when it introduces a crash?:
>> http://www.mail-archive.com/ly
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> Pavel Sanda <[EMAIL PROTECTED]> writes:
>> >> This is not supposed to modify the document IMO.
>> >
>> > are you sure about the insetbibtex case?
>>
>> The way I read the code, it just spawns an editor on the .bib files. But
Pavel Sanda <[EMAIL PROTECTED]> writes:
> in such a case i seriously ask about the whole philosophy of that patch...
> wouldn't be better to cache buffer only fo lfun we know that have the tendency
> to switch to another buffer? reload came to my mind now, but who knows what
> else can happen insid
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> >> This is not supposed to modify the document IMO.
> >
> > are you sure about the insetbibtex case?
>
> The way I read the code, it just spawns an editor on the .bib files. But
> please double check, I may be wrong.
iirc som
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> I think anyway that the patch as I posted it is safe, but as we know the
>> devil is in the details.
>
> Why do you still think it is safe when it introduces a crash?:
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg145234.html
I am on the case. N
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> > Jean-Marc Lasgouttes wrote:
> >> > this patch also touch lot of other code and i'm not sure about
> >> > possible side effects. wouldn't be more clean solution introduce
> >> > LFUN_INSET_OPEN for this specific task?
> >>
>
Pavel Sanda <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> > this patch also touch lot of other code and i'm not sure about
>> > possible side effects. wouldn't be more clean solution introduce
>> > LFUN_INSET_OPEN for this specific task?
>>
>> As I understand it, only the changes to
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> This is not supposed to modify the document IMO.
>
> are you sure about the insetbibtex case?
The way I read the code, it just spawns an editor on the .bib files. But
please double check, I may be wrong.
JMarc
Jean-Marc Lasgouttes wrote:
> > this patch also touch lot of other code and i'm not sure about
> > possible side effects. wouldn't be more clean solution introduce
> > LFUN_INSET_OPEN for this specific task?
>
> As I understand it, only the changes towards the end (startig from the
> default: hand
Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
> > except the reported crash i wonder about the change of inset from
> > mutable to readonly - in the other cases we want to be inset-edit
> > mutable.
>
> I read:
>
> /*!
> * \var lyx::FuncCode lyx::LFUN_INSET_EDIT
> * \li
> I think anyway that the patch as I posted it is safe, but as we know the
> devil is in the details.
Why do you still think it is safe when it introduces a crash?:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg145234.html
regards Uwe
Pavel Sanda <[EMAIL PROTECTED]> writes:
> except the reported crash i wonder about the change of inset from
> mutable to readonly - in the other cases we want to be inset-edit
> mutable.
I read:
/*!
* \var lyx::FuncCode lyx::LFUN_INSET_EDIT
* \li Action: Edit the inset at cursor with an externa
On 21/10/2008 10:16, Jean-Marc Lasgouttes wrote:
Abdelrazak Younes<[EMAIL PROTECTED]> writes:
Could you try this patch? I think it works, but since it is a bit
lng... The idea is to
differentiate the buffer before and after dispatch.
The buffer should not change for the LFUN handle
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> Could you try this patch? I think it works, but since it is a bit
>> lng... The idea is to
>> differentiate the buffer before and after dispatch.
> The buffer should not change for the LFUN handled in
> LyXFunc::dispatch(). If it changes this mean th
On 20/10/2008 23:32, Jean-Marc Lasgouttes wrote:
Le 20 oct. 08 à 17:29, Jean-Marc Lasgouttes a écrit :
Pavel Sanda <[EMAIL PROTECTED]> writes:
i have the feeling it happens in more different cases.
on example is opening file with include insets, edit the child
document (via context menu). now a
Uwe Stöhr wrote:
> > Could you try this patch?
>
> This patch introduces a crash. I tested it by using the LaTeX-testfile I
> attached to http://bugzilla.lyx.org/show_bug.cgi?id=5372
> Instead of error messages in the console, I get now immediately a crash.
except the reported crash i wonder abou
> Could you try this patch?
This patch introduces a crash. I tested it by using the LaTeX-testfile I attached to
http://bugzilla.lyx.org/show_bug.cgi?id=5372
Instead of error messages in the console, I get now immediately a crash.
regards Uwe
Le 20 oct. 08 à 17:29, Jean-Marc Lasgouttes a écrit :
Pavel Sanda <[EMAIL PROTECTED]> writes:
i have the feeling it happens in more different cases.
on example is opening file with include insets, edit the child
document (via context menu). now any action (even mouse click)
produce undo messages
36 matches
Mail list logo
