The idea behind this patch is to make real key-value support for InsetCommand parameters possible. This should be particularly useful for the listings version of InsetInclude, though we would need some kind of UI for it before it would really be helpful. (See below for some thoughts.) This doesn't substantially change anything else, though some things do get re-arranged a bit.
Basically, the idea is this. First, we introduce a whole range of parameter types: Normal LaTeX optional and required parameters; ones for LyX's internal use (like embed); and finally, in connection with keyval, ones that represent keys and ones that represent optional and required arguments where the keyval stuff will appear. (I'm assuming here that there will always be exactly one of those, and that it will accept only keyval-type material.) The parameters themselves are stored in a map, so it's really only the output routines that need to care about the different types of parameters.
Regarding the frontend, it seems to me that something like the following would work:
(i) scan the parameter list for LATEX_KEY type parameters
(ii) the dialog will have a series of lines, each of which has a combo box listing the acceptable keys and a QLineEdit for entering its value, as well as a "delete" button of some sort for removing this key and its value
(iii) there should be an "add line" button to add a new line, activated only when all other lines are filled with values
Probably not even too hard.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23235 a592a061-630c-0410-9148-cb99ea01b6c8
I've left the typedef in TextClassPtr.h. At the moment, it's kind of silly. But I've left it mostly because it helps to identify where the TextClass's stored in the TextClassBundle are used, and maybe it'd be worth having some sort of strong typedef like the one for BaseClassIndex here.
I need to check whether the textClass_ member of InsetCollapsable is needed now. I think not.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23232 a592a061-630c-0410-9148-cb99ea01b6c8
- implement wrapper around normalize that handles specific cases
that must not be normalized (rest of bug 3313).
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23227 a592a061-630c-0410-9148-cb99ea01b6c8
random-access (i.e. O(log n)) to the n-th element in a list/set. Try
it with 1000000 keys ... no problem.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23213 a592a061-630c-0410-9148-cb99ea01b6c8
Sorry, Andre, but this broke not only the modules stuff but the general handling of TextClasses. I'm not opposed to doing this sort of thing, but it's going to be a little more complicated. I'll do it when I get a bit of time, or I can explain what the issue is here if you want to do it.
I'll separately re-commit some of the cleanup here.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23189 a592a061-630c-0410-9148-cb99ea01b6c8
Only when an LTR paragraph *ends with* an RTL chunk of text, movement was
incorrect in two ways:
1. After moving into the pargraph from the end, and then trying to move towards
the beginning of the paragraph, the cursor would immediately jump to the
previous pargraph.
2. If the cursor were placed inside the RTL text, and then we would move left
towards the beginning of the paragraph, upon reaching the end (beginning?) of
the RTL chunk, cursor would jump to the end of the paragraph, and then continue
as in (1).
(Same thing, of course, with the reverse situation, i.e., RTL paragraph ending
with LTR text).
We now deal with both of these cases correctly.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23173 a592a061-630c-0410-9148-cb99ea01b6c8
