Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo Finally, a patch that fixes a critical bug (as opposed to fixing
Bo WONTFIX). :-) Description:
Bo Create a 2 by 1 table with several characters in the lower cell,
Bo select both cells and S-Right when the cursor is in the upper
Bo cell. This crashes
Jean-Marc Lasgouttes wrote:
Bo Finally, a patch that fixes a critical bug (as opposed to fixing
Bo WONTFIX). :-) Description:
Bo Create a 2 by 1 table with several characters in the lower cell,
Bo select both cells and S-Right when the cursor is in the upper
Bo cell. This crashes lyx.
I
I do not think the analysis is correct. The real problem is that
saveSelection is not prepared (like most of our cut-and-paste
mechanism) to handle multi-cell selections.
How come my analysis is incorrect? We are talking about the same thing.
I said: saveSelection can not handle this case so I
Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo How come my analysis is incorrect? We are talking about the same
Bo thing.
Bo I said: saveSelection can not handle this case so I do not call
Bo it. You said: let me disable this case in saveSelection.
Bo I actually said: saveSelection should not be
Try the following: create a 2x1 table with 2 characters in cell 1 and
4 in cell 4. Put cursor at the end of cell 2 and do Shift-Up,
Shift-Left.
I see.
You get a crash, but no LFUN_FINISHED action is invoked. It is really
multi-cell selection that is broken.
But my patch was correct in that
Bo == Bo Peng [EMAIL PROTECTED] writes:
Bo But my patch was correct in that saveSelection should not be
Bo called before LFUN_FINISHED is processed in that particular case.
Bo The patch fixes the problem and save the correct selected text
Bo (things in the lower cell).
saveSelection does not
saveSelection does not hurt even in the LFUN_FINISHED case. At worst
it is useless.
Logically speaking, we should saveSelection after cur has moved to its
place. In that case, cur is undispatched so saveSelection should not
be called.
I am not sure the patch is done at the right place. The
Bo Peng wrote:
saveSelection does not hurt even in the LFUN_FINISHED case. At worst
it is useless.
Logically speaking, we should saveSelection after cur has moved to its
place. In that case, cur is undispatched so saveSelection should not
be called.
Maybe the best would be calling
Logically speaking, we should saveSelection after cur has moved to its
place. In that case, cur is undispatched so saveSelection should not
be called.
Maybe the best would be calling saveSelection at the end of
Cursor::dispatch (maybe adding the check if the cursor has moved), and
nowhere
Bo Peng wrote:
Logically speaking, we should saveSelection after cur has moved to its
place. In that case, cur is undispatched so saveSelection should not
be called.
Maybe the best would be calling saveSelection at the end of
Cursor::dispatch (maybe adding the check if the cursor has
Alfredo == Alfredo Braunstein [EMAIL PROTECTED] writes:
That makes sense but as I have said (or implied), to avoid
introduction of new bugs, it is unwise to overhaul clipboards now.
JMarc's two-liner stops crashes, my two-liners saves selection
correctly for that particular case. I think
Alfredo Seems fair enough ;-)
Go for it,
Will do.
but Alfredo's suggestion is the way to go later.
I hope Alfredo will go further enough to merge text and table clipboards. :-)
Bo
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Finally, a patch that fixes a critical bug (as opposed to fixing
Bo> WONTFIX). :-) Description:
Bo> Create a 2 by 1 table with several characters in the lower cell,
Bo> select both cells and S-Right when the cursor is in the upper
Bo> cell.
Jean-Marc Lasgouttes wrote:
> Bo> Finally, a patch that fixes a critical bug (as opposed to fixing
> Bo> WONTFIX). :-) Description:
>
> Bo> Create a 2 by 1 table with several characters in the lower cell,
> Bo> select both cells and S-Right when the cursor is in the upper
> Bo> cell. This
I do not think the analysis is correct. The real problem is that
saveSelection is not prepared (like most of our cut-and-paste
mechanism) to handle multi-cell selections.
How come my analysis is incorrect? We are talking about the same thing.
I said: saveSelection can not handle this case so I
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> How come my analysis is incorrect? We are talking about the same
Bo> thing.
Bo> I said: saveSelection can not handle this case so I do not call
Bo> it. You said: let me disable this case in saveSelection.
Bo> I actually said: saveSelection
Try the following: create a 2x1 table with 2 characters in cell 1 and
4 in cell 4. Put cursor at the end of cell 2 and do Shift-Up,
Shift-Left.
I see.
You get a crash, but no LFUN_FINISHED action is invoked. It is really
multi-cell selection that is broken.
But my patch was correct in that
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> But my patch was correct in that saveSelection should not be
Bo> called before LFUN_FINISHED is processed in that particular case.
Bo> The patch fixes the problem and save the correct selected text
Bo> (things in the lower cell).
saveSelection does not hurt even in the LFUN_FINISHED case. At worst
it is useless.
Logically speaking, we should saveSelection after cur has moved to its
place. In that case, cur is undispatched so saveSelection should not
be called.
I am not sure the patch is done at the right place. The
Bo Peng wrote:
>>
>> saveSelection does not hurt even in the LFUN_FINISHED case. At worst
>> it is useless.
>
> Logically speaking, we should saveSelection after cur has moved to its
> place. In that case, cur is undispatched so saveSelection should not
> be called.
Maybe the best would be
> Logically speaking, we should saveSelection after cur has moved to its
> place. In that case, cur is undispatched so saveSelection should not
> be called.
Maybe the best would be calling saveSelection at the end of
Cursor::dispatch (maybe adding the check if the cursor has moved), and
nowhere
Bo Peng wrote:
>> > Logically speaking, we should saveSelection after cur has moved to its
>> > place. In that case, cur is undispatched so saveSelection should not
>> > be called.
>>
>> Maybe the best would be calling saveSelection at the end of
>> Cursor::dispatch (maybe adding the check if the
> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>> That makes sense but as I have said (or implied), to avoid
>> introduction of new bugs, it is unwise to overhaul clipboards now.
>> JMarc's two-liner stops crashes, my two-liners saves selection
>> correctly for that particular
Alfredo> Seems fair enough ;-)
Go for it,
Will do.
but Alfredo's suggestion is the way to go later.
I hope Alfredo will go further enough to merge text and table clipboards. :-)
Bo
Finally, a patch that fixes a critical bug (as opposed to fixing WONTFIX). :-)
Description:
Create a 2 by 1 table with several characters in the lower cell,
select both cells and S-Right when the cursor is in the upper cell.
This crashes lyx.
Problem:
Text3.cpp: LFUN_CHAR_FORWARD_SELECT:
Finally, a patch that fixes a critical bug (as opposed to fixing WONTFIX). :-)
Description:
Create a 2 by 1 table with several characters in the lower cell,
select both cells and S-Right when the cursor is in the upper cell.
This crashes lyx.
Problem:
Text3.cpp: LFUN_CHAR_FORWARD_SELECT:
26 matches
Mail list logo
