"Bo Peng" <[EMAIL PROTECTED]> writes: >> You should also allow to do "info-inset arg". > > You mean allowing the insertion of this inset from command buffer? > Otherwise, I do not see why this is needed.
Yes, also for the benefit of lyxserver. We should allow arguments to lfuns as often as possible. > InsetCommand insists on a latex command, but this inset does not have > any. I have studied InsetCommand, InsetCollapsable, but neither of > them can be used. OK. >> I am not sure that the new support for LyXRC is worth it. Where would >> you need it? (besides "why not?"). > > When I write in lib/doc/Shortcuts.lyx "This file documents the > currently used shortcuts defined in bind file BLAH, .... Hmm, not sure this is _really_ useful. >> This means that the information would also be made available to the >> lyxserver. I do not insist on this particular implementation, but I >> thought it was worth mentioning. > > I do not quite get your idea. :-) Instead of having predetermined categories, the first argument of InsetInfo could be an lfun. Then InsetInfo would just invoke this lfun to get the needed information. This means that the information will also be available for other uses (without additional cost). >> Concerning shortcuts, I do not think it is wise to change a KeyMap >> mathod that is used elsewhere just because it does not look right for >> your use case. Actually, since the goal is to show the shortcut in the >> GUI (for the documentation), I'd suggest to stick with the first >> element only like the menus. KeyMap::print(true) is fine for that. > > I am not quite sure, because documentation is supposed to list > information exhaustively. Not really. When telling in the UserGuide that File>Open is Ctrl+O, one does not want to enumerate all possible uses. Actually you could implement both "shortcut" and "shortcuts" for these two uses. > As for printbindings, the original output [][] looks bad in a > button. Because it is used only in > LyXFunc.cpp::LyXFunc::sendDispatchMessage, so I think it is OK to > change it. Hmm. > Have you had a look at this file? I would like to add it so that > others can complete it. I think having an incomplete file in the trunk > is not a big deal. I'd rather keep the file in the hands of documenters and let them decide what to do. The file should part of the effort of building a complete reference of function. We already have enough flux in the documentation currently. JMarc
