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
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.
As has been repeatedly said, "biblio", as returned by the bibli
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
On Wed, Apr 02, 2008 at 03:58:37PM -0400, Richard Heck wrote:
>>> But (a) none of this code would vanish if you rolled ICP into
>>> InsetCommand. All of that information would still be needed, and I'd
>>> still want at least the second and third method to be static.
>>>
>>
>> Why oh why? Wha
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
> But there is a way around, and it lives in my tree. I thought we'd agreed
> about that: we just need to make sure we keep things in sync.
Yes. I agreed because I do not have time to hammer InsetCommand, but I
would be happy if someone steps in and get rid of the source of our
discussion: params
Bo Peng wrote:
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 prin
> 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
Andre Poenitz wrote:
On Tue, Apr 01, 2008 at 07:05:41PM -0400, rgheck wrote:
There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inset that in the end achieve something pretty
similar to
void InsetMathSqrt::write(WriteStream & os) const
On Tue, Apr 01, 2008 at 07:05:41PM -0400, rgheck wrote:
>
>> There's are 400 lines of "general" read/write infrastructure plus three
>> extra static methods per inset that in the end achieve something pretty
>> similar to
>>
>> void InsetMathSqrt::write(WriteStream & os) const
>> {
There's are 400 lines of "general" read/write infrastructure plus three
extra static methods per inset that in the end achieve something pretty
similar to
void InsetMathSqrt::write(WriteStream & os) const
{
os << "\\sqrt{" << cell(0) << '}';
}
vo
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
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, really, i
> 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 fix up
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, really, is t
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
Richard Heck wrote:
> Here's why I don't want to assume that insets have fixed parameter
> lists. Two use cases:
I believe there is a misunderstanding here. With "fixed parameter list" I do
not mean a hardcoded list in the source. I do mean a list that gets read
from some configuration file and i
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?
I'll top-post this only because my remarks don't interweave cleanly with
these comments, for which, thanks.
Here's why I don't want to assume that insets have fixed parameter
lists. Two use cases:
(i) Bibliography support. We need to move away from hard-coding
CiteEngines toward a more flexi
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++
Richard Heck wrote:
> I take it that the idea is that we don't have to store the list of
> parameters, whether they're optional, etc, in each and every inset, but
> rather use a reference to the static const construct to save memory.
Saving memory was not the main reason for this implementation,
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
Richard Heck wrote:
> The obvious way to handle this is to have something like this:
> enum Optional { OPT, REQ };
> struct ParamInfo {
>std::string paramName;
>Optional opt;
>docstring value;
> }
> class ParamList {
>setValue(std::string name, docstr
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'
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
34 matches
Mail list logo
