Re: [RFC] Missing DocIterator methods

d. Sounds simple and I want to use the DocIterator for that. >Nevertheless I missed two methods to use DocIterators for backward >iteration. First I’d like to have the opposite test to atEnd() - name >it atBegin() to stop the loop at beginning. Second there is the >possibility to go f

Re: [RFC] Missing DocIterator methods

On 8/14/20 4:02 PM, Stephan Witt wrote: > Hi all, > > to implement the correct and Mac conforming solution for navigation through > the LyX document with keyboard I need to go forward and backward. Sounds > simple and I want to use the DocIterator for that. Nevertheless I missed

[RFC] Missing DocIterator methods

Hi all, to implement the correct and Mac conforming solution for navigation through the LyX document with keyboard I need to go forward and backward. Sounds simple and I want to use the DocIterator for that. Nevertheless I missed two methods to use DocIterators for backward iteration. First

Re: proper way to check inclusion among DocIterator ?

On 24/04/2017 21:54, Jean-Marc Lasgouttes wrote: Le 21/04/17 à 01:15, Tommaso Cucinotta a écrit : Hi, is there an easy way to check whether a DocIterator d is positioned within two others a and b ? (that is, going through the document using forwardPos(), one encounters a, then d, then b

Re: proper way to check inclusion among DocIterator ?

Le 21/04/17 à 01:15, Tommaso Cucinotta a écrit : Hi, is there an easy way to check whether a DocIterator d is positioned within two others a and b ? (that is, going through the document using forwardPos(), one encounters a, then d, then b). AFAIU, DocIterator::operator() just compares nesting

proper way to check inclusion among DocIterator ?

Hi, is there an easy way to check whether a DocIterator d is positioned within two others a and b ? (that is, going through the document using forwardPos(), one encounters a, then d, then b). AFAIU, DocIterator::operator() just compares nesting levels, but no pos() nor pit() etc. Thanks

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

Le 23/03/2015 20:17, Richard Heck a écrit : For now, I pushed a fix at c2f785bdc. Richard, I will have to backport it to branch, since the faulty commit is ported at d5eeabcfd. OK. Done. JMarc

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

DocIterator::sanitize only adds editable insets This fixes the crash on ticket #9432, but the bug there has other causes. This causes a new crash for me: 1. start a new LyX document 2. alt+m f to create a fraction 3. alt+m r to insert a root 4. undo Indeed :( It turns out that editable

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

On Mon, Mar 23, 2015 at 2:55 PM, Jean-Marc Lasgouttes wrote: > Le 23/03/2015 19:45, Kornel Benko a écrit : >> >> That was fast. The new test passes. > > > Scott already did the detective work, it was not so difficult. I will have > to learn git bisect one day. When you do, remember that 'git bise

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

Le 23/03/2015 19:45, Kornel Benko a écrit : That was fast. The new test passes. Scott already did the detective work, it was not so difficult. I will have to learn git bisect one day. JMarc

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

Lasgouttes > >> Date: Mon Mar 9 11:14:26 2015 +0100 > >> > >> Check that DocIterator::sanitize only adds editable insets > >> > >> This fixes the crash on ticket #9432, but the bug there has other > >> causes. > > >

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

Le 21/03/2015 20:42, Scott Kostyshak a écrit : On Tue, Mar 10, 2015 at 11:17 AM, Jean-Marc Lasgouttes wrote: commit 17e435c47e36effd36d25cec900369e04f6acb4e Author: Jean-Marc Lasgouttes Date: Mon Mar 9 11:14:26 2015 +0100 Check that DocIterator::sanitize only adds editable insets

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

Am Samstag, 21. März 2015 um 15:42:37, schrieb Scott Kostyshak > On Tue, Mar 10, 2015 at 11:17 AM, Jean-Marc Lasgouttes > wrote: > > commit 17e435c47e36effd36d25cec900369e04f6acb4e > > Author: Jean-Marc Lasgouttes > > Date: Mon Mar 9 11:14:26 2015 +0100 > >

Re: [LyX/master] Check that DocIterator::sanitize only adds editable insets

On Tue, Mar 10, 2015 at 11:17 AM, Jean-Marc Lasgouttes wrote: > commit 17e435c47e36effd36d25cec900369e04f6acb4e > Author: Jean-Marc Lasgouttes > Date: Mon Mar 9 11:14:26 2015 +0100 > > Check that DocIterator::sanitize only adds editable insets > > This fixes the

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

Sidharth Kshatriya wrote: > > I find the source code very lightly commented unfortunately. Even if every > > class had a 3-4 lines describing what it did, it would have been great. It > > would be wonderful if some more human commenting of each class were part of > > the goals of the 2.0 version.

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

Thanks for your reply Richard. After reading your and Vincent's comments, I felt my questions relating to the DocIterator were well answered. Sure, I look forward to you suggesting enhancement features to implement. Thanks, Sidharth On Sun, Jun 13, 2010 at 11:16 PM, Richard Heck wrote:

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

On 06/13/2010 01:22 PM, Sidharth Kshatriya wrote: On Sun, Jun 13, 2010 at 9:58 PM, Vincent van Ravesteijn >wrote: Are you interested in implementing a certain feature ? If it's not too difficult, we can guide you and explain you the things you'll find on your roa

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

On Sun, Jun 13, 2010 at 9:58 PM, Vincent van Ravesteijn wrote: > Are you interested in implementing a certain feature ? If it's not too > difficult, we can guide you and explain you the things you'll find on your > road. It's indeed useful if you document it immediately. I myself have tried > to d

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

On 06/13/2010 11:13 AM, Sidharth Kshatriya wrote: I want to understand * What is the use of the inset_ member in the DocIterator class? Each CursorSlice has a link to its corresponding inset so what is the use of inset_ in the DocIterator class? I don't know this code terribly well,

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

Op 13-6-2010 17:13, Sidharth Kshatriya schreef: I want to understand * What is the use of the inset_ member in the DocIterator class? Each CursorSlice has a link to its corresponding inset so what is the use of inset_ in the DocIterator class? I don't have a good answer, but if you cre

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

he internals of LyX was >> http://wiki.lyx.org/Devel/Diagrams Are there any more such pages like >> this out there? This one page has helped me so much! However I have a few >> questions please >> >> I want to understand >> * What is the use of the inset_ member

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

Basically I want to understand how the diagram of http://wiki.lyx.org/Devel/Diagrams corresponds to the implementation. I have figured out that each CursorSlice relates to one node in the stack of parents upto the root InsetText but can't understand the role of inset_ in DocIterator. On Sun

Re: Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

e there any more such pages like this > out there? This one page has helped me so much! However I have a few > questions please > > I want to understand > * What is the use of the inset_ member in the DocIterator class? Each > CursorSlice has a link to its corresponding inset so wh

Wish to understand DocIterator class + Willing to Volunteer to document LyX internals

ease I want to understand * What is the use of the inset_ member in the DocIterator class? Each CursorSlice has a link to its corresponding inset so what is the use of inset_ in the DocIterator class? * What happens if there are multiple cells? * In the example described in the diagram in the link

Re: Unimplemented DocIterator::backwardPar()

Tommaso Cucinotta <[EMAIL PROTECTED]> writes: > This method seems to be in the header file, but not in > the implementation one. Indeed. Do you need it? JMarc

Unimplemented DocIterator::backwardPar()

This method seems to be in the header file, but not in the implementation one. T.

Re: DocIterator

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

Re: DocIterator

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

Re: DocIterator

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

Re: DocIterator

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 befor

Re: DocIterator

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

Re: DocIterator

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

Re: DocIterator

> > 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 docum

Re: DocIterator

Andre Poenitz <[EMAIL PROTECTED]> writes: > Arguably the forwardInset() calls should be part of the Next Node > implementation. ?? JMarc

Re: DocIterator

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): > > >

Re: DocIterator

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

Re: DocIterator

> 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

Re: DocIterator

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

Re: DocIterator

> 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() !=

Re: DocIterator

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 (f

DocIterator

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)) lyxerr<<"inset found";

Re: [BUG] in DocIterator::backwardPos() when used in mathed (was Re: LyX crashes when outline is visible and I click into a matrix formula (LyX svn)

for me. > > This is fixed in svn. Andre', JMarc, the problem was in > DocIterator::backwardPos(): > > void DocIterator::backwardPos() > { > //this dog bites his tail > if (empty()) { > push_back(CursorSlice(*inset_)); >

[BUG] in DocIterator::backwardPos() when used in mathed (was Re: LyX crashes when outline is visible and I click into a matrix formula (LyX svn)

the cursor is still in the formula, lyx should crash immediately. If not, click into the formula to make lyx crash. That makes the outline view pretty unusful for me. This is fixed in svn. Andre', JMarc, the problem was in DocIterator::backwardPos(): void DocIterator::backwardPos() {

Re: [patch] remove bogust const semantics in DocIterator

n (because having a behaving DocIterator const & *is* useful, and the code is a real mess in this respect). A/

Re: [patch] remove bogust const semantics in DocIterator

lice -> ConstCursorSlice). Something similar could be done for > DocIterator. > > Another option would be to use templates like some stl container do, but I > don't know what would be the advantage in this case. > > A third option would be to eliminate const_iterator semantics

Re: [patch] remove bogust const semantics in DocIterator

Andre Poenitz wrote: > Okokok ;-) What about this? It only adds 13 lines overall, buying us normal const_iterator semantics for CursorSlices (Including automatic conversion CursorSlice -> ConstCursorSlice). Something similar could be done for DocIterator. Another option would be

Re: [patch] remove bogust const semantics in DocIterator

Andre Poenitz wrote: > Okokok ;-) :-) A/

Re: [patch] remove bogust const semantics in DocIterator

; >> This the same concept as the previous post for CursorSlices. > >> > > >> > I personally agree with the two patches. > >> > >> Thanks! I'll apply on monday if there are no objections. > >> > >> btw, we should implement good con

Re: [patch] remove bogust const semantics in DocIterator

onally agree with the two patches. >> >> Thanks! I'll apply on monday if there are no objections. >> >> btw, we should implement good const semantics for CursorSlice, >> DocIterator and Cursor, it's really missing. > > Do we really need it? It probably m

Re: [patch] remove bogust const semantics in DocIterator

s! I'll apply on monday if there are no objections. > > btw, we should implement good const semantics for CursorSlice, DocIterator > and Cursor, it's really missing. Do we really need it? It probably means some code duplication, and so far the old 'fake' constness you just remove sort-of-worked. Andre' >

Re: [patch] remove bogust const semantics in DocIterator

Abdelrazak Younes wrote: > Alfredo Braunstein wrote: >> This the same concept as the previous post for CursorSlices. > > I personally agree with the two patches. Thanks! I'll apply on monday if there are no objections. btw, we should implement good const semantics for Curs

Re: [patch] remove bogust const semantics in DocIterator

Alfredo Braunstein wrote: This the same concept as the previous post for CursorSlices. I personally agree with the two patches. Abdel.

[patch] remove bogust const semantics in DocIterator

=== --- DocIterator.cpp (revision 19615) +++ DocIterator.cpp (working copy) @@ -58,7 +58,7 @@ } -Inset * DocIterator::nextInset() +Inset * DocIterator::nextInset() const { BOOST_ASSERT(!empty()); if (pos() == lastpos()) @@ -73,7 +73,7 @@ } -Inset

Re: [Cvslog] r18114 - in /lyx-devel/trunk/src: Cursor.cpp DocIterator....

> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> I there a reason why you did not do like in the attached? Abdelrazak> Not really no. At the time, I guess I was not sure if Abdelrazak> innerParagraph() would give the current paragraph of the Abdelrazak> enclosing one in tex

Re: [Cvslog] r18114 - in /lyx-devel/trunk/src: Cursor.cpp DocIterator....

Jean-Marc Lasgouttes wrote: "younes" == younes <[EMAIL PROTECTED]> writes: younes> Author: younes Date: Mon Apr 30 13:46:02 2007 New Revision: younes> 18114 younes> URL: http://www.lyx.org/trac/changeset/18114 Log: * younes> Cursor::isRTL(): correctly deal with the inner paragraph when younes

Re: [Cvslog] r18114 - in /lyx-devel/trunk/src: Cursor.cpp DocIterator....

> "younes" == younes <[EMAIL PROTECTED]> writes: younes> Author: younes Date: Mon Apr 30 13:46:02 2007 New Revision: younes> 18114 younes> URL: http://www.lyx.org/trac/changeset/18114 Log: * younes> Cursor::isRTL(): correctly deal with the inner paragraph when younes> within mathed. I there

Re: Assertions in dociterator/mathed

>>>>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I get an assertion if I leave the cursor inside a math inset and Lars> quit lyx. Lars> inset: 0xde6118 idx: 0 par: 971 pos: 477 inset: 0x1009a70 idx: Lars> 0 par: 0 pos: 4 Lars>

Assertions in dociterator/mathed

I get an assertion if I leave the cursor inside a math inset and quit lyx. inset: 0xde6118 idx: 0 par: 971 pos: 477 inset: 0x1009a70 idx: 0 par: 0 pos: 4 Assertion triggered in Paragraph& DocIterator::paragraph() by failing check "inTexted()" in file dociterator.C:157 Aborted -- Lgb

Re: [PATCH] bug 1926: Paragraph& DocIterator::paragraph() by failing check "inTexted()" in file dociterator.C:144

> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> Testing appreciated, although it seems trivially correct (I Jean-Marc> tried to use LFUN_GETLAYOUT but it (1) leaves the current Jean-Marc> math inset and (2) displays the result of the lfun in the Jean-Marc> minibuff

[PATCH] bug 1926: Paragraph& DocIterator::paragraph() by failing check "inTexted()" in file dociterator.C:144

& DocIterator::paragraph() by failing check "inTexted()" in file dociterator.C:144'' Testing appreciated, although it seems trivially correct (I tried to use LFUN_GETLAYOUT but it (1) leaves the current math inset and (2) displays the result of the lfun in the minibuf

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

Andre Poenitz <[EMAIL PROTECTED]> writes: | On Mon, Jul 26, 2004 at 08:30:56PM +0200, Lars Gullik Bjønnes wrote: >> | They are forward iterators implemented as stacks of cursor slices. >> | Or close to it. >> >> But as they are now they cannot be used with std::algorithm. > | Thaey should be usab

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

On Mon, Jul 26, 2004 at 08:30:56PM +0200, Lars Gullik Bjønnes wrote: > | They are forward iterators implemented as stacks of cursor slices. > | Or close to it. > > But as they are now they cannot be used with std::algorithm. Thaey should be usable with any algorithm that works with forward iterat

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

Andre Poenitz <[EMAIL PROTECTED]> writes: | On Sun, Jul 18, 2004 at 01:47:28AM +0200, Lars Gullik Bjønnes wrote: >> [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: >> >> | Changes should be made so that the regular stl::algorithms can be used >> | with InsetIterat

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

On Sun, Jul 18, 2004 at 01:47:28AM +0200, Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | Changes should be made so that the regular stl::algorithms can be used > | with InsetIterator and DocIterator. > > Hmm it seems that the DocIterator and

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

Lars Gullik Bjønnes wrote: > [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: > > | Changes should be made so that the regular stl::algorithms can be used > | with InsetIterator and DocIterator. ...and the bug is? Oh well... > Hmm it seems that the DocIterator and StableDocI

Re: {bug] InsetIterator and DocIterator unusable with std::algorithms

[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Changes should be made so that the regular stl::algorithms can be used | with InsetIterator and DocIterator. Hmm it seems that the DocIterator and StableDocIterator are not really iterators at all, but containers of CursorSlices. Confusing

{bug] InsetIterator and DocIterator unusable with std::algorithms

Changes should be made so that the regular stl::algorithms can be used with InsetIterator and DocIterator. -- Lgb

Re: dociterator

g not having the 'inset' prefix for two reason: 1. It makes > > typing .../src/in to go into the inset/ directory impossible > > (which I use ofter), 2. it does not fit into the > > insettabular/insetlabel/insetwhatever scheme. > > Oops, I've just renamed i

Re: dociterator

the 'inset' prefix for two reason: 1. It makes > typing .../src/in to go into the inset/ directory impossible > (which I use ofter), 2. it does not fit into the > insettabular/insetlabel/insetwhatever scheme. Oops, I've just renamed iterators.[Ch] -> dociterator.[Ch

Re: dociterator

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

Re: dociterator

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.

Re: dociterator

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

Re: dociterator

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). &g

Re: dociterator

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 derivati

Re: dociterator

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. >> >

Re: dociterator

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

Re: dociterator

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 o

dociterator

btw, we should have a right past-the-end position for dociterator (and all derivatives). Alfredo

Re: [patch] DocIterator updated

Andre Poenitz <[EMAIL PROTECTED]> writes: | Attached. Should the DocumentIterator really be initialized with a bufferview? Or a Buffer? To me it seems that DocumentIterator really should be renamed to BufferIterator. Kindo the same relationship as between vector and vector::iterator. --