Lars,
can I make one point here. This is preliminary work. Nobody was suggesting
that it would be the best possible way.
Right. Now I've said that, I'll answer your points.
> | * Adds a "Use Natbib" check button to the Document dialog (tab Extra).
> I'd rather hide this from the user (and I really want to get rid of
> the extra stuff).
This means that natbib will always be used. Is this what you want? Why?
Moreover, the \usepackage{natbib} command can take a raft of options. This
should go in the Document dialog somewhere, probably in it's own, dedicated
tab folder.
> | * When natbib is enabled, the Citation dialog has a choice for the \citeX
> | command.
> Those commands should be renamed no "\citeX" anything should ever be
> visible to the user.
Whilst I see that I could use two checkboxes to go from \citeX to \citeX* or
from \citeX to \CiteX, natbib supports so many different \citeX commands that
I really can't see how better to do this. Anyway, the principle point
remains. This is preliminary work.
> | * Toggling "Use Natbib" Off will not change the LaTeX output from \citet,
> | \citep etc to \cite. Ie, the output will be incorrect. You'll have to
> | open/close each Citation inset by hand.
>
> So this should not be fixed in the inset, but discovered upon
> writeout.
Yes, this is what I've just done. Overload the InsetCite::Latex() method.
However, if we ALWAYS use natbib, then the code isn't needed. So, the "design
argument" should be thrashed out.
> | * Cannot input comments before the citation when in natbib mode.
> | The InsetCommandParams::options field must be altered to take
> | multiple options before this can occur. Thoughts:
> |
> | make options a vector<string> and access is with
> | void setOption(string, int = 0)
> | string getOption(int = 0)
>
> hmm, why the int? use a map instead.
> Look in Variables.C.
My turn to hmm. Not sure I understand you. A generic latex command can take
multiple options
\cmdname [option1] [option2] [option X] {contents}
why would a map represent this concept more cleanly? Are you talking about
using a map to store the data rather than a vector? But this is an
implementation detail, not an interface one.
> | I'm not at all sure that I've done the use_natbib stuff correctly.
> | Basically, I just copied use_amsmath. It all seems to work, but if
> | someone in the know would check this over, I'd be very grateful.
>
> A branch to do this in would probably be nice.
Ok. Will this work: (and do I have write permission?)
To create a branch of lyx-devel
===============================
1. create a tag at the current point
cvs tag natbib-TAG lyx-devel
2. create a branch tag on that tag
cvs rtag -b -r natbib-TAG natbib-BRANCH lyx-devel
3. checkout
cvs checkout -r natbib-BRANCH
4. apply my changes to this checked out code
patch -p0 < patch_natbib
5. commit the changes
cvs commit
Angus
