Bo Peng wrote:
> Agreed, except that order is not a big problem, and as you have
> suggested to sort embedded files, we can also sort user bibfiles. (I
> know it is not particularly nice to reorganize user input :-).
No. The order of the bibfiles matters in many ways and must not be changed
behin
On Wed, Apr 02, 2008 at 07:28:04PM -0400, rgheck wrote:
> That said, your suggestion doesn't seem to do what Bo wants here anyway.
> The point is supposed to be that I can send mybiblio.bib wrapped up in the
> bundle and it will get used. We do NOT want the LyX file to use whatever
> file called
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 06:04:09PM -0400, Richard Heck wrote:
Isn't EmbeddedFile all about representing an "Embedded file"? If there
are problems, they need to be fixed there. But I can't imagine a solution
getting easier by requiring it to _additionally_ fit into a mapst
ng/path/yourbib.bib]
where the empty bit, in both cases, means: not embedded. (Think about
which makes sense from an XML perspective.) To do this, of course, we
would need either to extend InsetCommandParams so it understands this
kind of list (we use such lists elsewhere), or do the more radica
Enrico Forestieri wrote:
On Wed, Apr 02, 2008 at 05:20:45PM -0400, Richard Heck wrote:
Bo Peng wrote:
Agreed, except that order is not a big problem, and as you have
suggested to sort embedded files, we can also sort user bibfiles. (I
know it is not particularly nice to reorganize
On Wed, Apr 02, 2008 at 06:04:09PM -0400, Richard Heck wrote:
>> Isn't EmbeddedFile all about representing an "Embedded file"? If there
>> are problems, they need to be fixed there. But I can't imagine a solution
>> getting easier by requiring it to _additionally_ fit into a map> string>.
>
> As
On Wed, Apr 02, 2008 at 05:20:45PM -0400, Richard Heck wrote:
> Bo Peng wrote:
> > Agreed, except that order is not a big problem, and as you have
> > suggested to sort embedded files, we can also sort user bibfiles. (I
> > know it is not particularly nice to reorganize user input :-).
> >
> >
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 03:58:37PM -0400, Richard Heck wrote:
(An instance of ICP does know for which kind
of inset it is the parameters; this is just an alternative to subclasses,
hence the factory; there's no substantial issue there.)
The point is: The more unus
ding this method solved a crash in the
> inset stuff, one I inadvertently triggered by entering an ill-formed
> parameter string via the mini-buffer. (I don't recall the bug number. I can
> find it if you like.) The short version is that the parameters for a
> particular typ
Bo Peng wrote:
I thought we'd also agreed that you don't need an EmbeddedFileList, because
you don't need any of its methods, etc, etc (and my sense is that it'd be
disastrous to call them). So what you want is just a vector.
Yes, but I do not see a difference if you do not call the method
discussion: params_.
> But even if we are going to go more or less the route you suggest, then
> there are large-scale questions to be resolved first. If you're going to
> subclass InsetCommandParams, then you're going to be making a major
> architectural change, and we need to do
you're going to
subclass InsetCommandParams, then you're going to be making a major
architectural change, and we need to do it carefully. If you're going to
introduce a standalone InsetBibtexParams, then you are going to
duplicate a truckload of code unless we do the same kind of t
> But I disagree that embedded objects are parameters. In particular, I think
> using an EmbeddedFile object to represent a pair of strings is overkill that
> ultimately makes the code less comprehensible and less maintainable, because
> (a) changes to the EmbeddedFile stuff could in principle aff
Andre Poenitz wrote:
On Wed, Apr 02, 2008 at 12:52:17PM -0400, Richard Heck wrote:
///
static ParamInfo const & findInfo(std::string const &);
///
static std::string defaultCommand() { return "href"; };
///
static bool isCompatibleCommand(std::string const & s)
On Wed, Apr 02, 2008 at 12:52:17PM -0400, Richard Heck wrote:
>> ///
>> static ParamInfo const & findInfo(std::string const &);
>> ///
>> static std::string defaultCommand() { return "href"; };
>> ///
>> static bool isCompatibleCommand(std::string const & s) {
>> re
José Matos wrote:
On Wednesday 02 April 2008 18:25:11 Bo Peng wrote:
Of course I also respect your chaos judgment.
Come on this does not help any discussion. :-(
Actually, that was meant seriously and nicely. I'd said that there'd be
too much chaos if we did something, and Bo wa
Bo Peng wrote:
Please see my other message. What Andre envisages is rolling
InsetCommandParams into the insets. That could be done, of course, but there
are at least some reasons not to do it. The reasons not to do it are the
same as the reasons to have InsetGraphicsParams be separate from
On Wednesday 02 April 2008 18:25:11 Bo Peng wrote:
> Of course I also respect your chaos judgment.
Come on this does not help any discussion. :-(
> Cheers,
> Bo
--
José Abílio
> Please see my other message. What Andre envisages is rolling
> InsetCommandParams into the insets. That could be done, of course, but there
> are at least some reasons not to do it. The reasons not to do it are the
> same as the reasons to have InsetGraphicsParams be s
between
params and EmbeddedFileList if we get rid of params altogether. Even
if removing InsetCommand is too costly now, free InsetBibtex from
InsetCommand would be less work.
Please see my other message. What Andre envisages is rolling
InsetCommandParams into the insets. That could be done, of
derived from InsetCommand there is already more code
needed just to _interface_ the "nice general" code in InsetCommandParams
than an inset specific read/write implemention would take. This is
cancer that should not be allowed to grow any further.
Where is all this extra code in,
parse(cell->back().nucleus()->cell(0),
>> FLAG_ITEM, mode);
>> }
>> [...]
>> }
>>
>> i.e. in each class derived from InsetCommand there is already more code
>> needed just to _interface_ the "nice general
cell->push_back(MathAtom(new InsetMathSqrt));
parse(cell->back().nucleus()->cell(0),
FLAG_ITEM, mode);
}
[...]
}
i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_
Andre Poenitz wrote:
What is, btw, LATEX_KV_REQUIRED and LATEX_KV_OPTIONAL good for?
LyX compiles fine without those?
They're not currently used. I introduced them and then got sidetracked.
The intention is to use them to represent keyval-type parameters.
rh
qrt));
parse(cell->back().nucleus()->cell(0),
FLAG_ITEM, mode);
}
[...]
}
i.e. in each class derived from InsetCommand there is already more code
needed just to _interface_ the "nice general" code in InsetCommandParams
than an inset specific re
Pavel Sanda wrote:
After a hiatus, I'm returning to the rewrite of InsetCommandParams, the
purpose of all of this being to make things more flexible, with the
ultimate goal being biblatex support and a kind of InsetCommandFlex that
will allow user-definable such things. The next step, r
> After a hiatus, I'm returning to the rewrite of InsetCommandParams, the
> purpose of all of this being to make things more flexible, with the
> ultimate goal being biblatex support and a kind of InsetCommandFlex that
> will allow user-definable such things. The next step, rea
end(), rhs.begin());
+}
+
+
+ParamInfo::ParamData const &
+ ParamInfo::operator[](std::string const & name) const
+{
+ BOOST_ASSERT(hasParam(name));
+ const_iterator it = begin();
+ const_iterator last = end();
+ for (; it != last; ++it) {
+ if (it->name() == name)
+ return *it;
Thanks.
rh
Andre Poenitz wrote:
On Fri, Feb 22, 2008 at 10:58:29PM -0500, rgheck wrote:
Index: src/insets/InsetCommandParams.cpp
===
--- src/insets/InsetCommandParams.cpp (revision 23025)
+++ src/insets/InsetCommandParams.c
On Fri, Feb 22, 2008 at 10:58:29PM -0500, rgheck wrote:
> Index: src/insets/InsetCommandParams.cpp
> ===
> --- src/insets/InsetCommandParams.cpp (revision 23025)
> +++ src/insets/InsetCommandParams.cpp (working copy)
> @@ -42,14 +42,63
rgheck wrote:
After a hiatus, I'm returning to the rewrite of InsetCommandParams, the
purpose of all of this being to make things more flexible, with the
ultimate goal being biblatex support and a kind of InsetCommandFlex that
will allow user-definable such things. The next step, reall
After a hiatus, I'm returning to the rewrite of InsetCommandParams, the
purpose of all of this being to make things more flexible, with the
ultimate goal being biblatex support and a kind of InsetCommandFlex that
will allow user-definable such things. The next step, really, is to fi
Sorry for the top-post, but, after lots of thought about this, I've come
to the conclusion that Georg is right, and we shouldn't go the way I was
suggesting. There's then a different design problem that arises, but
I'll post a note about that later. That said:
IMHO the text classes are pretty
t; The solution towards which I'm working is to get
> each inset to tell us what parameters it wants for each command with
> which it might be associated. That is:
> virtual ParamList InsetCommand::getParamList(std::string cmd);
> replacing InsetCommandParams::findInfo(). Actually, fin
Andre Poenitz wrote:
On Fri, Oct 19, 2007 at 12:24:50AM -0400, Richard Heck wrote:
Andre Poenitz wrote:
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
So the question is: Are the added memory requirements here
objectionable?
How much would that be?
rking is to get
each inset to tell us what parameters it wants for each command with
which it might be associated. That is:
virtual ParamList InsetCommand::getParamList(std::string cmd);
replacing InsetCommandParams::findInfo(). Actually, findInfo will still
be needed, but it will j
On Fri, Oct 19, 2007 at 12:24:50AM -0400, Richard Heck wrote:
> Andre Poenitz wrote:
> >On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
> >
> >>So the question is: Are the added memory requirements here
> >>objectionable?
> >>
> >How much would that be?
> >
> I don't know C++
mption, because it enables you to
guarantee by design that an inset has only valid parameters. This was the
main reason for this implementation.
> And then every InsetCommand would have an associated ParamList in its
> InsetCommandParams.
And you can easily construct invalid insets and need to
Andre Poenitz wrote:
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
So the question is: Are the added memory requirements here
objectionable?
How much would that be?
I don't know C++ internals enough to be sure how much we're talking per
inset. We're looking at, on av
setValue(std::string name, docstring value);
>getValue(std::string name);
>isOptional(std::string name);
>addParam(ParamInfo);
> private:
>std::list plist;
> }
> And then every InsetCommand would have an associated ParamList in its
> InsetCo
On Thu, Oct 18, 2007 at 02:47:44PM -0400, Richard Heck wrote:
> So the question is: Are the added memory requirements here
> objectionable?
How much would that be?
Andre'
So, the work on making this system more flexible proceeds, with
interruptions for actual philosophy from time to time. At this point, I
have a question before I embark on the next step. The question concerns
how the list of parameters is represented in InsetCommandParams.
At present, it&#
Richard Heck wrote:
Uwe Stöhr wrote:
There are still two cases where InsetCommandParams crashes. I added
them to
http://wiki.lyx.org/Devel/RegressionListSVN
Could you please have a look at them. Both are there since my Url ->
Hyperlink patch but I can't figure out what the problem
Uwe Stöhr wrote:
There are still two cases where InsetCommandParams crashes. I added
them to
http://wiki.lyx.org/Devel/RegressionListSVN
Could you please have a look at them. Both are there since my Url ->
Hyperlink patch but I can't figure out what the problem is as I only
renamed
Uwe Stöhr schrieb:
There are still two cases where InsetCommandParams crashes.
One has gone after a complete recompilation of my tree.
regards Uwe
There are still two cases where InsetCommandParams crashes. I added them to
http://wiki.lyx.org/Devel/RegressionListSVN
Could you please have a look at them. Both are there since my Url -> Hyperlink patch but I can't
figure out what the problem is as I only renamed "url&
Uwe Stöhr wrote:
- This entry in InsertUrl.cpp
InsetUrl::InsetUrl(InsetCommandParams const & p)
: InsetCommand(p, "url")
{}
leads to a crash in InsetCommandparams.cpp line 46. Because when the
user uses the hyperlink checkbox in the URL-dialog, the inset Type has
changed - w
- This entry in InsertUrl.cpp
InsetUrl::InsetUrl(InsetCommandParams const & p)
: InsetCommand(p, "url")
{}
leads to a crash in InsetCommandparams.cpp line 46. Because when the user uses the hyperlink
checkbox in the URL-dialog, the inset Type has changed - what is corr
>> > I *think* the way to do this is:
>> >
>> > string const paramStr = InsetIncludeMailer::params2string(params_);
>> > params_.read(paramStr);
>> >
>> > Abdel...is this right, more or less?
>
> Sorry that I am slow due to lack of sleep. How can I *set* option in
> this way? You basically convert
> I *think* the way to do this is:
>
> string const paramStr = InsetIncludeMailer::params2string(params_);
> params_.read(paramStr);
>
> Abdel...is this right, more or less?
Sorry that I am slow due to lack of sleep. How can I *set* option in
this way? You basically convert params_ back and fort
[EMAIL PROTECTED] wrote:
If you look at InsetCommandParams, you'll see that params_ is set in
read(), and the other InsetCommand derived insets call read() when they
need to set params_. (When they need to read the params, they just get
params_ directly via params() and index into it.) T
>> If you look at InsetCommandParams, you'll see that params_ is set in
>> read(), and the other InsetCommand derived insets call read() when they
>> need to set params_. (When they need to read the params, they just get
>> params_ directly via params() and index
If you look at InsetCommandParams, you'll see that params_ is set in
read(), and the other InsetCommand derived insets call read() when they
need to set params_. (When they need to read the params, they just get
params_ directly via params() and index into it.) That's what I meant w
gt;
> I quickly scanned other InsetCommand derived insets, and they do not
> seem to set param_ at all.
If you look at InsetCommandParams, you'll see that params_ is set in
read(), and the other InsetCommand derived insets call read() when they
need to set params_. (When they need to
Ozgur Ugras BARAN wrote:
> On 11/4/06, Georg Baum
>> I did some testing and changes and put it in.
>> I discovered that the latest version of the nomencl package has a chnaged
>> interface, therefore I used that instead of the old one. It is possible
>> to support the old one, too, but I don't thi
On 11/4/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Am Freitag, 3. November 2006 12:23 schrieb Ozgur Ugras BARAN:
> Georg, I have updated your patch as you can see in the attachments. I
> find this way easier. I think you will find it easier to review, too.
>
> The draft documentations is also atta
Am Freitag, 3. November 2006 12:23 schrieb Ozgur Ugras BARAN:
> Georg, I have updated your patch as you can see in the attachments. I
> find this way easier. I think you will find it easier to review, too.
>
> The draft documentations is also attached. I have written it
> considering the new User
On Friday 03 November 2006 11:35 am, Ozgur Ugras BARAN wrote:
> It is not that big. I will send the patch and you decide, whether it
> can go in or not. If it can not go in, we can put it in trunk after
> the release of 1.5.
Thank you.
--
José Abílio
On 11/2/06, José Matos <[EMAIL PROTECTED]> wrote:
On Thursday 02 November 2006 12:15 pm, Georg Baum wrote:
> Ozgur Ugras BARAN wrote:
> >
> > Oh, this is bad news, since I have almost completed the multiple indices
> > stuff..
Do you have the code? :-)
Yes I do.. At least 80% of it :)) I can
mand.h"
+
+
+namespace lyx {
+
+class LaTeXFeatures;
+
+/** Used to insert notation labels
+ */
+class InsetNomencl : public InsetCommand {
+public:
+ ///
+ InsetNomencl(InsetCommandParams const &);
+ ///
+ docstring const getScreenLabel(Buffer const &) const;
+ ///
+ EDITABLE editab
On Thursday 02 November 2006 12:15 pm, Georg Baum wrote:
> Ozgur Ugras BARAN wrote:
> >
> > Oh, this is bad news, since I have almost completed the multiple indices
> > stuff..
Do you have the code? :-)
> You can be lucky that the nomencl stuff is allowed at all.
I am following the spirit of
Ozgur Ugras BARAN wrote:
> On 11/2/06, Georg Baum
> <[EMAIL PROTECTED]> wrote:
>> Shortly after you went on holiday a freeze was announced, and nothing new
>> was allowed to go in. Fortunately Jose (the 1.5.0 release manager) agreed
>> to put the nomencl stuff in.
>>
>
> Oh, this is bad news, sin
On 11/2/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Am Mittwoch, 1. November 2006 15:38 schrieb Ozgur Ugras BARAN:
> By the way, I haven't seen nomencl commit in svn. Is something
> missing, or do you need new diff?
Shortly after you went on holiday a freeze was announced, and nothing new
was allo
nterpart of Lars Gullik Bjønnes. Thanks Lars)
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef INSET_NOMENCL_H
+#define INSET_NOMENCL_H
+
+
+#include "insetcommand.h"
+
+
+namespace lyx {
+
+class LaTeXFeatures;
+
+/** Used to insert notation labels
+ */
+cl
Am Mittwoch, 1. November 2006 15:38 schrieb Ozgur Ugras BARAN:
> By the way, I haven't seen nomencl commit in svn. Is something
> missing, or do you need new diff?
Shortly after you went on holiday a freeze was announced, and nothing new
was allowed to go in. Fortunately Jose (the 1.5.0 release m
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Thank you very much! (You must be watching the svn logs very
Michael> very carefully.)
Not very carefully, but I do look at all of them (especially to see
what could be used in 1.4 too).
JMarc
Am Dienstag, 24. Oktober 2006 16:15 schrieb Jean-Marc Lasgouttes:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Can somebody add him to the credits stuff please? I don't know
> Georg> how that works.
>
> I did it (also for the new Galician translator).
Thanks.
> Please ch
Jean-Marc Lasgouttes wrote:
Also, Michael, you should not change CREDITS directly, but edit
generate_contributions.py. I propagated your latest change.
Thank you very much! (You must be watching the svn logs very very
carefully.)
Michael
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Can somebody add him to the credits stuff please? I don't know
Georg> how that works.
I did it (also for the new Galician translator). Please check that I
did it right (I kind of guessed the alphabetic ordering).
Also, Michael, you s
Am Donnerstag, 19. Oktober 2006 08:44 schrieb Ozgur Ugras BARAN:
> The diff is already in the tgz file (x.diff). It contains necessary
> makefile changes and also insetbase changes.
>
> Oh the licencing.. of course..
>
> I hereby declare that, I grant permission for all my past and future
> contr
Stupid me, I forgot the file... :)
Here it is.
On 10/20/06, Ozgur Ugras BARAN <[EMAIL PROTECTED]> wrote:
Here is the updated nomencl files.
I will be away for the next week for holidays. Everybody enjoy Denmark..
Ugras
nom.tgz
Description: GNU Zip compressed data
Here is the updated nomencl files.
I will be away for the next week for holidays. Everybody enjoy Denmark..
Ugras
es", lyx::from_utf8(split(contents, bd, ',')));
else
return false;
}
Index: src/insets/insetbibitem.C
===
--- src/insets/insetbibitem.C (revision 15393)
+++ src/insets/insetbibitem.C (working copy)
@@
Ozgur Ugras BARAN wrote:
> this diff removes most of the get/set command function calls from the
> lyx code. I didn't touch cite stuff, as we decided.
Thanks. Could you please rework the patch to use
qstring_to_ucs4()
instead of
lyx::utf8_to_ucs4(fromqstr())
?
Georg
x27;,' + bd;
- setContents(subst(contents, tmp, ""));
+ setParam("bibfiles", lyx::from_utf8(subst(contents, tmp, "")));
} else if (n == 0)
// this is the first (or only) database
- setContents(split(contents, bd, ','));
+ setParam(&q
By the way, I am starting to cleanup of get/set options/contents stuff
from Lyx code (excluding cite related files). However, tomorrow I am
going to holidays for a week. I will send you the patch as much as I
can finish. I can do the rest as I return back form holidays.
ugras
The diff is already in the tgz file (x.diff). It contains necessary
makefile changes and also insetbase changes.
Oh the licencing.. of course..
I hereby declare that, I grant permission for all my past and future
contributions to LyX project under the Gnu General Public Licence
version 2 or late
Georg Baum wrote:
> Ozgur Ugras BARAN wrote:
>
>> Here we go...
>>
>> I can't compile for gtk no more due to fontmetrics issues, therefore
>> gtk frontend haven't been tested. I have tested it before the
>> corresponding svn commit, and it was working.
>
> That is no problem.
>
> You forgot a
Ozgur Ugras BARAN wrote:
> Here we go...
>
> I can't compile for gtk no more due to fontmetrics issues, therefore
> gtk frontend haven't been tested. I have tested it before the
> corresponding svn commit, and it was working.
That is no problem.
You forgot a diff of the makefiles and insetbase.
obably simply use
> the code from InsetCommandParams::scanCommand unless somebody has a
better
> idea.
That will be the next step.
Ugras, please send an updated nomencl inset!
Georg
nomencl_lyx.tgz
Description: GNU Zip compressed data
Index: ui/stdtoolbars.ui
===
ands nesting. I'll probably simply use
> the code from InsetCommandParams::scanCommand unless somebody has a
better
> idea.
That will be the next step.
Ugras, please send an updated nomencl inset!
Georg
On 10/16/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> well, quite a diff..
>
> Giving a unique name for each params is a good idea. I didn't dare to
> touch getOptions() etc. functions since they are called everywhere. I
> see that you are bold enough. :) Thanks for the p
Ozgur Ugras BARAN wrote:
> well, quite a diff..
>
> Giving a unique name for each params is a good idea. I didn't dare to
> touch getOptions() etc. functions since they are called everywhere. I
> see that you are bold enough. :) Thanks for the patch. I can
> participate by getting rid of those ge
h. It
should finish before the weekend.
The patch seems OK. I haven't tested it, yet, I will finish in a day or two.
thanks again.
Ugras
On 10/15/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Here comes the first part of the rework of InsetCommandParams I have been
working on.
All paramete
Here comes the first part of the rework of InsetCommandParams I have been
working on.
All parameters do now have a name, and the plan is to get rid of
getOptions, getSecOptions, getContents etc. in a second step. That will
make the inset and dialog code easier to understand (especially of the
On 10/2/06, Georg Baum <[EMAIL PROTECTED]> wrote:
Ozgur Ugras BARAN wrote:
> On 9/30/06, Georg Baum
> <[EMAIL PROTECTED]> wrote:
>> This is a specialization, but I think we should keep it generic and
>> simple. InsetCommandParams would just store a number of parame
Ozgur Ugras BARAN wrote:
> On 9/30/06, Georg Baum
> <[EMAIL PROTECTED]> wrote:
>> This is a specialization, but I think we should keep it generic and
>> simple. InsetCommandParams would just store a number of parameters, and
>> the LaTeX command generated from th
ke
> \index {aaa!bbb!ccc}
> can be handled as:
> LatexCommand
> command_name index
> add_index_entry aaa
> add_index_entry bbb
> add_index_entry ccc
> end_inset
> As I said, just a speculation...
This is a specialization, but I think we should keep it generic and simple.
This is a specialization, but I think we should keep it generic
Georg> and simple. InsetCommandParams would just store a number of
Georg> parameters, and the LaTeX command generated from then would
Georg> simply be \command{param1}[optparam2][optparam3]{param4} etc.
Yes, definitely. The index inset can try to do more complicated things
from there.
Command
> command_name index
> add_index_entry aaa
> add_index_entry bbb
> add_index_entry ccc
> end_inset
> As I said, just a speculation...
This is a specialization, but I think we should keep it generic and simple.
InsetCommandParams would just store a number of parameters, and th
n, so that it should be extended. Second, I had
to change all initiations of insetcommandparams in the lyx code, but I
was not sure whether my implementation will be accepted or not. I
assume that It is accepted. Then we can go back the old constructor for the
moment, since I have already handled no
.
*/
#include
#include "insetcommandparams.h"
#include "debug.h"
#include "lyxlex.h"
using std::string;
using std::pair;
InsetCommandParams::InsetCommandParams()
{}
InsetCommandParams::InsetCommandParams(string const & n,
string const & c,
s
Hi Ugras,
I am glad to see that you worked on this.
Am Mittwoch, 27. September 2006 11:29 schrieb Ozgur Ugras BARAN:
> Dear all,
>
> At last I had time and play with the insetcommandparams as requested
> on nomencl discussion. The new implementation keeps the contents and
> o
Dear all,
At last I had time and play with the insetcommandparams as requested
on nomencl discussion. The new implementation keeps the contents and
options in lists. There is also support for individual parameters with
std::multimaps for future implementations. I haven't put any kind of
n
On Thu, Jul 04, 2002 at 06:24:39PM +0200, Lars Gullik Bjønnes wrote:
> These two shoule not be member functions, but regular functions
> instead:
I know. Was just a quick move..
> // inline perhaps?
Nah. Never inline without profiler data...
Andre'
--
Those who desire to give up Freedom in or
These two shoule not be member functions, but regular functions
instead:
bool InsetCommandParams::operator==(InsetCommandParams const & o) const
{
return cmdname == o.cmdname && contents == o.contents
&& options == o.options;
}
bool InsetCom
96 matches
Mail list logo
