Le 15/12/2015 18:03, Richard Heck a écrit :
On 12/11/2015 05:36 PM, Guillaume Munch wrote: >> Dear list, >> >> >> Following the discussions in
<http://www.lyx.org/trac/ticket/9794>, >> here are a series of patches meant to address #9794 (inset-modify >> tabular commands are incorrectly disabled) and #4189 >> (Edit->Rows&Columns not shown when in mathed insert). > > There is a somewhat more general issue here: Dispatched LFUNs are > generally caught by the first inset that knows how to handle the > relevant command. So this can cause problems with embedded insets. I > did some work on this a while ago in the InsetModify-Incomplete > branch of my personal repo: > http://git.lyx.org/?p=developers/rgheck/lyx.git;a=summary I'm not > sure how this relates to your patches. > > Richard >

Dear Richard

Please make sure that you reply to the list :)

Regarding 2.2.0:

It is clear that the change you are suggesting is bigger and requires more testing. This does not look like something that can be done for 2.2.0. Thus my question is, how do we want to address #9794 for the next two years? Because in any case, we need some new lfun which is not AtPoint. Indeed, for tabular commands, it is meaningless to dispatch to the inset in front of the cursor because we cannot guess which cell is targeted.

This new lfun table-modify was the best option as far as the discussions went in the ticket, and it does not preclude a bigger change for 2.3.0. Therefore, can I please commit this patch?

Regarding 2.3.0:

You are right, while writing the patch I indeed thought that a bigger problem was maybe that insets should not catch inset-modify commands not meant for them. Similar issues remain in the tabular dialog for this reason, as I wrote in the commit. I now think that one should, as you do in your patch above, test for the type of inset passed to inset-modify and leave the lfun undispatched when it is not the good one. This avoids the problem mentioned by Jean-Marc in the above ticket regarding "hardcoding knowledge of other insets everywhere". This would also prevent issues like <http://www.lyx.org/trac/ticket/9386>, so much that I wonder why this was not done already.

Sincerely
Guillaume


Reply via email to