Abdelrazak Younes wrote:
[EMAIL PROTECTED] wrote:
URL: http://www.lyx.org/trac/changeset/21194
+CommandInfo const * InsetBibitem::findInfo(std::string const & /*
cmdName */)
+{
+ static const char * const paramnames[] = {"label", "key", ""};
+ static const bool isoptional[] = {true, false};
+ static const CommandInfo info = {2, paramnames, isoptional};
+ return &info;
}
Hum, I think I'd prefer a static map initialisation:
map<InsetCode, CommandInfo> command_info;
command_info[BIBITEM_CODE] = CommandInfo(2, {"label", "key", ""},
{true, false};
command_info[BIBTEX_CODE] = CommandInfo(3, {"options", "btprint",
"bibfiles", ""}, {true, true, false};
Hum... no, even that is too complicated, why not using ICPInfo
directly instead of this intermediate structure? Instead of a list,
I'd choose a vector:
typedef std::vector<ICPInfo> PList;
typeded map<InsetCode, PList> command_info;
And then in the factory or in the InsetBibitem ctor:
command_info[BIBITEM_CODE] = PList({{"label", true}, {"key", false}});
Yes, this is where I'm headed, more or less. The ICPInfo, etc, stuff is
all new, and the static this, static that is the old code. But I've not
yet figured out exactly how to do this. That's all connected with the
"Design Problem". We need, in general, in a single inset, to be able to
store different parameter lists not just for different commands but for
different buffer--command combinations, but that should be easy enough
to add once we actually have access to the buffer.
Richard
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
