Georg Baum wrote:
>> I'll proceed with some version of this, once we're fully agreed how to
>> do it.
>>
> I guess I made my concerns clear enough now, so please decide yourself what
> you want to implement. I don't want to hear again that I tell other people
> what they should do or not do
On Sunday 22 April 2007 6:56:19 pm Georg Baum wrote:
> I guess I made my concerns clear enough now, so please decide yourself what
> you want to implement. I don't want to hear again that I tell other people
> what they should do or not do :-)
As long as I am not the person to tell you that you
Am Sonntag, 22. April 2007 15:59 schrieb Richard Heck:
> Georg Baum wrote:
> > - Change the InsetComnmandParams constructor to take an InsetBase::Code
> > instead of a name. name_ would simply be set to the first possible name
of
> > that inset.
> >
> There's no need to worry about name_, rea
Georg Baum wrote:
> What about this solution:
>
This is pretty close to what I had, except that it uses the old
InsetBase::Code rather than constructing a new, and (as you said) nearly
duplicate enum.
> - Add an InsetBase::Code const field to InsetCommandParams that denotes the
> type of inset.
Am Freitag, 20. April 2007 17:13 schrieb Richard Heck:
>
> This is long. I'm sorry. But there are a lot of issues here.
>
> Georg Baum wrote:
> > The case that you are adressing was not thought of: Stuff that comes
from
> > a .lyx file is assumed to be correct (we do this elsewhere, too), and
w
This is long. I'm sorry. But there are a lot of issues here.
Georg Baum wrote:
> The case that you are adressing was not thought of: Stuff that comes from
> a .lyx file is assumed to be correct (we do this elsewhere, too), and we
> were not aware about the minibuffer.
>
The same issue arises w
Richard Heck wrote:
> Abdelrazak Younes wrote:
>>> +//It's not obvious this is the right place for this enum. Note
>>> that it
>>> +//serves a different purpose from the one in insetbase.C and so
>>> can't be
>>> +//replaced by it.
>> Couldn't they be merged instead? See above.
> The I
Abdelrazak Younes wrote:
>> +//It's not obvious this is the right place for this enum. Note
>> that it
>> +//serves a different purpose from the one in insetbase.C and so
>> can't be
>> +//replaced by it.
> Couldn't they be merged instead? See above.
The InsetBase::Code can be different
Richard Heck wrote:
This patch addresses the remaining issue with crashes on ill-formed
inset-insert minibuffer commands. I've also added some comments
expressing my understanding of what's going on here.
+InsetCommandParams::InsetParamType
InsetCommandParams::command2ParamType(std::string c
Richard Heck wrote:
This patch addresses the remaining issue with crashes on ill-formed
inset-insert minibuffer commands. I've also added some comments
expressing my understanding of what's going on here.
I am not well versed in this InsetCommand stuff but your patch looks
good and the comment
This patch addresses the remaining issue with crashes on ill-formed
inset-insert minibuffer commands. I've also added some comments
expressing my understanding of what's going on here.
Comments welcome. Testing desired.
Richard
--
===
11 matches
Mail list logo
