On 01/03/2016 02:25 PM, Guillaume Munch wrote: > Le 03/01/2016 09:46, Georg Baum a écrit : >> Guillaume Munch wrote: >> >>> Regarding http://www.lyx.org/trac/ticket/9794, I had two questions >>> below >>> before making the requested changes: >>> >>> Le 29/12/2015 00:27, LyX Ticket Tracker a écrit : >>>> #9794: inset-modify tabular commands are incorrectly disabled >>>> -----------------------------------------+------------------------- >>>> Reporter: gadmm | Owner: lasgouttes >>>> Type: defect | Status: new >>>> Priority: high | Milestone: 2.2.0 >>>> Component: general | Version: 2.1.3 >>>> Severity: normal | Resolution: >>>> Keywords: regression patch fileformat | >>>> -----------------------------------------+------------------------- >>>> >>>> Comment (by gadmm): >>>> >>>> I now have some little more time again. Only the following >>>> remains to >>>> do: >>>> >>>> Replying to [comment:17 lasgouttes]: >>>> > * increment lyx format and add some lyx2lyx code to update info >>>> > insets. >>>> >>>> I need help for "some lyx2lyx code to update info insets", if you >>>> really want to implement these higher standards. How do I do that? >> >> If you post a description of the needed changes on the list then >> somebody >> will probably come up with a prototype lyx2lyx code that you can fine >> tune. > > > I would like to know the proper way of applying prefs2prefs_lfun from > format 3 to format 4 in the arg line in the following: > > \begin_inset Info > type "shortcut" > arg "inset-modify tabular append-column" > \end_inset > > (in Shortcuts.lyx).
This is our own file. I'd just update it manually. If you want to update it programmatically, then you need to use lyx2lyx for that, since we're updating a LyX file. prefs2prefs* are used to update ui, bind, etc, files. If you do want to do it via lyx2lyx, then just give me a list of conversions and I'll write the code. This kind of thing is easy once you've done it a few times. > We can also change it for type="icon", which will affect many more > manuals as well, though this is superfluous given that the renaming hack > that was there before is still there. Maybe we should only bother > doing it if we decide to get rid of the renaming hack at some point. Just let me know which you want. Easy both ways. Richard
