we first do a range test, then check the status. I think this is right
in both cases.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36351 a592a061-630c-0410-9148-cb99ea01b6c8
Also, change from using the "cha" prefix for chapters, a la prettyref,
to the "chap" prefix, a la refstyle. We alias \pr@chap to \pr@cha for
prettyref users.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@36238 a592a061-630c-0410-9148-cb99ea01b6c8
for formatted references. Fixes#2295, in so far as it makes it possible
to translate formatted references.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@35623 a592a061-630c-0410-9148-cb99ea01b6c8
a lot of simplification is possible. Except some instability period...
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33389 a592a061-630c-0410-9148-cb99ea01b6c8
The idea here is to implement something like \refstepcounter for LyX. We
do this by tracking the "active" counter in Counters.cpp. We also have
to track when we go in and out of environments to which counters are
local, and so on and so forth.
This all gets done in updateLabels(), but only if we are producing
output, which is why I added the output boolean a while ago.
I expect there are bugs in here, though it seems to work pretty well
with the documents I've tested.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@33108 a592a061-630c-0410-9148-cb99ea01b6c8
as to allow us to call the routine when we are preparing for output and
so to do certain things we might not want to do every time.
This is an abuse of updateLabels(), in a way, but updateLabels() long
ago became the general recurse-through-the-Buffer routine, and to
implement the sort of thing I want to do here in validate(), say, much
of the code in updateLabels()---in particular, the counter-update
code---would have to be duplicated. So I believe this is the best, and
easiest, way to go.
Actual use of the new argument will follow.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32318 a592a061-630c-0410-9148-cb99ea01b6c8
other fixes in here, too.
There is an issue here which I guess I'll deal with later, namely, that
the name attribute for <a> is unavailable in XHTML 1.1, which is what we
need for MathML support, at least in Firefox. Firefox will deal with it
if it's there, but the document won't validate. I'll figure out what to
do about this later.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@32226 a592a061-630c-0410-9148-cb99ea01b6c8
use the label name as associated text, and put it into square brackets. It'd be
nice to be able to do more, but for that we'd need to associate counters with
the labels, which would be nice for display, too. But we don't have that yet.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31976 a592a061-630c-0410-9148-cb99ea01b6c8
This is wrong and should have been reverted long ago and since r31340 it even doesn't have any function because addToToc isn't called for an internal buffer anymore.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@31355 a592a061-630c-0410-9148-cb99ea01b6c8
* Inset::validate(): renamed to initView()
* InsetCommand:
- get rid of unneeded refresh() and updateButtonLabel_
- setParams(): call initView()
* InsetRef:
- implement initView()
- screenLabel(): transfer code to updateLabels()
- addToToc(): prefix name with BROKEN if the reference is broken.
git-svn-id: svn://svn.lyx.org/lyx/lyx-devel/trunk@23417 a592a061-630c-0410-9148-cb99ea01b6c8
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
