Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | When I think about it: Has anybody ever tried to use a std::vector<>
>> | (-like container) instead of a std::list<> as text contai
On Thu, Mar 11, 2004 at 12:21:05PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | When I think about it: Has anybody ever tried to use a std::vector<>
> | (-like container) instead of a std::list<> as text container?
>
> You loose the fast undo/paste stuff. si
Andre Poenitz <[EMAIL PROTECTED]> writes:
| When I think about it: Has anybody ever tried to use a std::vector<>
| (-like container) instead of a std::list<> as text container?
You loose the fast undo/paste stuff. since you will need to
reallocate... with std::list a splice is done.
What are the
On Thu, Mar 11, 2004 at 11:38:16AM +0100, Alfredo Braunstein wrote:
> > (1) A 'stable' iterator not dependent on the location of some random
> > chunk in memory (aka 'pointer'). Ok, that was already defeated by having
> > the inset_ cache, but my original intention wsa to get rid of that.
>
> Why
Andre Poenitz wrote:
> No, both have to be kept in sync. This should be O(1) though for
> standard operations like initialization, one up, one down etc.
>
>> Doesn't that defeat the purpose of having the offset at all
>
> Partially, yes.
>
>> (hum... what was it again)?
>
> (1) A 'stable' iter
On Wed, Mar 10, 2004 at 09:05:40AM +0100, Alfredo Braunstein wrote:
> > The obvious idea is to use and/or cache some ParagraphList iterator
> > instead of the par offset...
> >
> > Maybe we've to use both. In fact, it's almost the same as with the
> > 'inset_' member: This is just a form of a cach
Andre Poenitz wrote:
> The obvious idea is to use and/or cache some ParagraphList iterator
> instead of the par offset...
>
> Maybe we've to use both. In fact, it's almost the same as with the
> 'inset_' member: This is just a form of a cache itself.
Right.
> So we'd remove the 'paroffset_type
On Tue, Mar 09, 2004 at 09:25:29AM +0100, Alfredo Braunstein wrote:
> On Friday 05 March 2004 19:45, Andre Poenitz wrote:
> > > On Thursday 04 March 2004 17:15, you wrote:
> > >> > Do you have an idea why is it slow?
> > >>
> > >> No(t yet).
> > >
> > > Looking at it a bit closely, I do. I'm pretty
Andre Poenitz wrote:
> In theory, this could be used in undo instead of the current triplet
> (quadrupel) of data. Unfortunately, DocIterator is too slow for it
> (currently) (~30s for traversing the UserGuide)
Do you have an idea why is it slow? We should make it fast enough; then we
could ditch
On Mon, Mar 01, 2004 at 03:31:34PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This splits the cursor into an 'iterator' part (that can be
> > reused...) and a 'selection handling + real cursor stuff' part.
> > Reason should be obvious.
>
> The patch doesn't contain "dociterator
Andre Poenitz wrote:
>
> This splits the cursor into an 'iterator' part (that can be
> reused...) and a 'selection handling + real cursor stuff' part.
> Reason should be obvious.
The patch doesn't contain "dociterator.[Ch]". Just three references
to their existence.
There appear to be some con
Andre Poenitz wrote:
>
> This splits the cursor into an 'iterator' part (that can be reused...)
> and a 'selection handling + real cursor stuff' part. Reason should be
> obvious.
could you send dociterator.[Ch] please?
Alfredo
12 matches
Mail list logo
