Andre Poenitz <[EMAIL PROTECTED]> writes:
>> > Arguably the forwardInset() calls should be part of the Next Node
>> > implementation.
>>
>> ??
>
> I mean: drop the first forwardInset() call from the findInset()
> implementation and instead call it manually before calling findInset().
I see. Note
On Wed, Apr 23, 2008 at 09:38:37AM +0200, Jean-Marc Lasgouttes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> > Arguably the forwardInset() calls should be part of the Next Node
> > implementation.
>
> ??
I mean: drop the first forwardInset() call from the findInset()
implementation and
Jean-Marc Lasgouttes wrote:
I took a look at uses of _CODE and one of the first non-trivial uses I
found is:
int InsetPrintNomencl::docbook(odocstream & os, OutputParams const &) const
{
os << "\n";
int newlines = 2;
for (InsetIterator it = inset_iterator_begin(buffer().i
Pavel Sanda wrote:
Buffer & buf = bv->buffer();
DocIterator cur = doc_iterator_begin(buf.inset());
while (findInset(cur, vector(1, GRAPHICS_CODE), false))
lyxerr<<"inset found";
when i put single image in document nothing is found; i must some characters
before text to have it found.
Pavel Sanda <[EMAIL PROTECTED]> writes:
> finally i use this:
> while (findNextInset(cur, vector(1, GRAPHICS_CODE), contents)){
> //add some assert for cur.nextInset()->lyxCode() != GRAPHICS_CODE
> InsetGraphics & ins = static_cast(*cur.nextInset());
>
Note that you do not need the ve
rgheck <[EMAIL PROTECTED]> writes:
> We have that in quite a lot of places. At present, that's just how
> insets identify themselves.
Some of the places where these codes are used are mandatory (like the
factory).
> Of course, you can have some virtual method in Inset that does
> nothing, and
> > Buffer & buf = bv->buffer();
> > DocIterator cur = doc_iterator_begin(buf.inset());
> >
> > while (findInset(cur, vector(1, GRAPHICS_CODE), false))
> > lyxerr<<"inset found";
> >
> >
> > when i put single image in document nothing is found; i must some characters
> > before text to have it
Andre Poenitz <[EMAIL PROTECTED]> writes:
> Arguably the forwardInset() calls should be part of the Next Node
> implementation.
??
JMarc
On Tue, Apr 22, 2008 at 11:05:58AM +0200, Jean-Marc Lasgouttes wrote:
> Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> > hi,
> >
> > please what am i doing wrongly here (i'm trying to iterate through
> > all graphics insets):
> >
> > Buffer & buf = bv->buffer();
> > DocIterator cur = doc_iterator_be
Jean-Marc Lasgouttes wrote:
Pavel Sanda <[EMAIL PROTECTED]> writes:
But, more importantly, why do you want to iterate over graphics
insets?
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg139244.html
OK, I see now. In general, I think that we should really avoid code
th
> Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> >> But, more importantly, why do you want to iterate over graphics
> >> insets?
> >
> > http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg139244.html
>
> OK, I see now. In general, I think that we should really avoid code
> that relies on inset c
Pavel Sanda <[EMAIL PROTECTED]> writes:
>> But, more importantly, why do you want to iterate over graphics
>> insets?
>
> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg139244.html
OK, I see now. In general, I think that we should really avoid code
that relies on inset codes, but for this
> One of the first thing that findInset does is:
> tmpdit.forwardInset();
>
> This means that the first inset is just ignored. This is useful in the
> context where findinset is used (like Next Note).
>
> You should try something like:
>
> while(!cur.nextInset() || cur.nextInset().lyxCode() !=
Pavel Sanda <[EMAIL PROTECTED]> writes:
> hi,
>
> please what am i doing wrongly here (i'm trying to iterate through
> all graphics insets):
>
> Buffer & buf = bv->buffer();
> DocIterator cur = doc_iterator_begin(buf.inset());
>
> while (findInset(cur, vector(1, GRAPHICS_CODE), false))
> ly
On Mon, Mar 29, 2004 at 10:36:39AM +0200, Alfredo Braunstein wrote:
> >> PS: OT, should I rename iterators.[Ch] to pariterator.[Ch] to make things
> >> more uniform?
> >
> > Sort of. Actually, I am thinking of renaming 'insetiterator' to
> > something not having the 'inset' prefix for two reason:
Andre Poenitz wrote:
>> [if you insist with the 'empty stack' past-the-end, we could just add an
>> inset * member and use that on operator-- (and possibly even operator++)
>> for an empty stack. Then the past-the-end (and possibly also
>> before-start) position would be DocumentIterator(inset)]
>
On Sun, Mar 28, 2004 at 12:52:08PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > It is good enough if we are happy with input iterator semantics. No '--'
>
> [forward iterator semantics would be more applicable here].
>
> > there. For backwards iteration we could just use another
Andre Poenitz wrote:
> It is good enough if we are happy with input iterator semantics. No '--'
[forward iterator semantics would be more applicable here].
> there. For backwards iteration we could just use another iterator class.
Yes, but why? We give up bidi iterator semantics for no reason.
On Sat, Mar 27, 2004 at 10:37:37PM +, Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
> > Andre Poenitz wrote:
> >
> >> On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
> >>> btw, we should have a right past-the-end position for dociterator
> >>> (and all derivatives).
>
On Sat, Mar 27, 2004 at 11:35:00PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
> >> btw, we should have a right past-the-end position for dociterator (and
> >> all derivatives).
> >
> > We do.
> >
> > It's an e
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> Andre Poenitz wrote:
>>
>>> On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
btw, we should have a right past-the-end position for dociterator
(and all derivatives).
>>>
>>> We do.
>>>
>>> It's an empty cursor s
Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
>> On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
>>> btw, we should have a right past-the-end position for dociterator
>>> (and all derivatives).
>>
>> We do.
>>
>> It's an empty cursor slice stack. (which is, btw, differe
Andre Poenitz wrote:
> On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
>> btw, we should have a right past-the-end position for dociterator (and
>> all derivatives).
>
> We do.
>
> It's an empty cursor slice stack. (which is, btw, different from the
> last possible cursor pos
On Sat, Mar 27, 2004 at 01:42:30PM +0100, Alfredo Braunstein wrote:
> btw, we should have a right past-the-end position for dociterator (and all
> derivatives).
We do.
It's an empty cursor slice stack. (which is, btw, different from the
last possible cursor position, i.e. really one ++ after thi
24 matches
Mail list logo
