On Friday 31 October 2003 10:50 am, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
> | Why not make the tree structure explicit, with leaf and node base
> | classes from which insets can derive? Wouldn't it make life much
> | simpler?
>
> Moving towards that... slowly...
Good t
Andre Poenitz wrote:
> But let's pretend for a while we don't want multiple views ;-)
Let's not. I'm not suggesting that the code needs to reflect this goal
now but it should definitely by thought about. That, after all, was
the rationale behind the discussion to date.
--
Angus
On Mon, Nov 03, 2003 at 12:16:06PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> > On Thu, Oct 30, 2003 at 05:26:11PM +0100, Alfredo Braunstein wrote:
> >> Angus Leeming wrote:
> >>
> >> > Note that multiple BufferViews implies multiple Cursors. I'm sure
> >> > that I would be pissed off
On Mon, Nov 03, 2003 at 01:04:29PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > 'semi-stable'. They don't change the structure of a parapgraph list (at
> > least currently there's no way to remove paragraph breaks etc. by s&r)
>
> ..except for removing the whole paragraph and let
Andre Poenitz wrote:
> On Thu, Oct 30, 2003 at 05:26:11PM +0100, Alfredo Braunstein wrote:
>> Angus Leeming wrote:
>>
>> > Note that multiple BufferViews implies multiple Cursors. I'm sure
>> > that I would be pissed off if I replaced "brown" with "red" in one
>> > window and found that the curso
Andre Poenitz wrote:
> On Thu, Oct 30, 2003 at 05:26:11PM +0100, Alfredo Braunstein wrote:
>> Angus Leeming wrote:
>>
>> > Note that multiple BufferViews implies multiple Cursors. I'm sure
>> > that I would be pissed off if I replaced "brown" with "red" in
>> > one window and found that the curso
On Thu, Oct 30, 2003 at 12:42:48PM -0500, Kuba Ober wrote:
> On Thursday 30 October 2003 11:26 am, Alfredo Braunstein wrote:
> > Angus Leeming wrote:
> > > Note that multiple BufferViews implies multiple Cursors. I'm sure
> > > that I would be pissed off if I replaced "brown" with "red" in one
> >
On Thu, Oct 30, 2003 at 05:26:11PM +0100, Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
> > Note that multiple BufferViews implies multiple Cursors. I'm sure
> > that I would be pissed off if I replaced "brown" with "red" in one
> > window and found that the cursor in my other BufferView had
Andre Poenitz wrote:
> 'semi-stable'. They don't change the structure of a parapgraph list (at
> least currently there's no way to remove paragraph breaks etc. by s&r)
...except for removing the whole paragraph and letting DESM do it's
nastiness...
Alfredo
On Thu, Oct 30, 2003 at 02:41:21PM +, John Levon wrote:
> On Thu, Oct 30, 2003 at 01:08:25PM +0100, Alfredo Braunstein wrote:
>
> > In which situations you think we need it to remain valid?
>
> I don't understand. Clearly, search and replace, spellcheck, merge
> changes all need a static iter
On Thu, Oct 30, 2003 at 12:15:51PM +, Angus Leeming wrote:
> IMO, we should separate the concept of 'iterator' from that of
> 'cursor'. I believe that this is André's view too.
Hm yes. But a cursor is not much more than one or two iterators (for the
selection anchor...), and not a completely
> >> It's pseudo-rubbish in that the lyx data structure is a tree
> >> in-concept only. It's actually a std::list where each
> >> Paragraph contains a std::vector and an InsetList. Insets are
> >> identified in the std::vector by chars with value
> >> 'META_INSET' and a Buffer::inset_iterator class
Kuba Ober <[EMAIL PROTECTED]> writes:
| Why not make the tree structure explicit, with leaf and node base
| classes from which insets can derive? Wouldn't it make life much
| simpler?
Moving towards that... slowly...
--
Lgb
On Thursday 30 October 2003 01:06 pm, Angus Leeming wrote:
> Kuba Ober wrote:
> > On Thursday 30 October 2003 11:26 am, Alfredo Braunstein wrote:
> >> Angus Leeming wrote:
> >> > Note that multiple BufferViews implies multiple Cursors. I'm sure
> >> > that I would be pissed off if I replaced "brown
Angus Leeming wrote:
> I know. I even described it as such ;-)
Oops sorry. I should read before posting. ;-)
Alfredo
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> It's pseudo-rubbish in that the lyx data structure is a tree
>> in-concept only. It's actually a std::list where each
>> Paragraph contains a std::vector and an InsetList. Insets are
>> identified in the std::vector by chars with value
>> 'MET
Angus Leeming wrote:
> It's pseudo-rubbish in that the lyx data structure is a tree
> in-concept only. It's actually a std::list where each
> Paragraph contains a std::vector and an InsetList. Insets are
> identified in the std::vector by chars with value 'META_INSET'
> and a Buffer::inset_iterato
Kuba Ober wrote:
> On Thursday 30 October 2003 11:26 am, Alfredo Braunstein wrote:
>> Angus Leeming wrote:
>> > Note that multiple BufferViews implies multiple Cursors. I'm sure
>> > that I would be pissed off if I replaced "brown" with "red" in
>> > one window and found that the cursor in my othe
Kuba Ober wrote:
> I think that the only real solution is that the tree must know of its
> iterators and adjust them if tree structure changes.
>
> I presume that it should call into existence a proper tree base classes
> for leafs and nodes. I wonder if they exist in the current design. [No
> ti
On Thursday 30 October 2003 11:26 am, Alfredo Braunstein wrote:
> Angus Leeming wrote:
> > Note that multiple BufferViews implies multiple Cursors. I'm sure
> > that I would be pissed off if I replaced "brown" with "red" in one
> > window and found that the cursor in my other BufferView had also
>
Angus Leeming wrote:
> Note that multiple BufferViews implies multiple Cursors. I'm sure
> that I would be pissed off if I replaced "brown" with "red" in one
> window and found that the cursor in my other BufferView had also
> changed position.
That's a very good point.
Alfredo
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> Is such a strategy possible or desirable?
>
> I hope it's not needed, because that would make the code horribly
> cluttered... but I don't see many other alternatives in the case it
> would be needed.
Note that multiple BufferViews implies m
Angus Leeming wrote:
> Is such a strategy possible or desirable?
I hope it's not needed, because that would make the code horribly
cluttered... but I don't see many other alternatives in the case it would
be needed.
Alfredo
Alfredo Braunstein wrote:
>> Help me through this, I'm getting confused. Here is my document:
>>
>> "The quick brown fox jumped over the |lazy dog."
>>
>> The position of the global cursor is indicated by '|'. Internally,
>> I imagine that this cursor contains a (valid) PosIterator.
>>
>> I wish
Alfredo Braunstein wrote:
>> The position of the global cursor is indicated by '|'. Internally, I
>> imagine that this cursor contains a (valid) PosIterator.
>>
>> I wish to find "brown":
>> PosIterator pos = search_for(buffer, "brown");
>>
>> I now wish to replace "brown" with "red". How do I d
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> John Levon wrote:
>>
>>> On Thu, Oct 30, 2003 at 01:08:25PM +0100, Alfredo Braunstein wrote:
>>>
In which situations you think we need it to remain valid?
>>>
>>> I don't understand. Clearly, search and replace, spellcheck, merge
>>> c
Alfredo Braunstein wrote:
> John Levon wrote:
>
>> On Thu, Oct 30, 2003 at 01:08:25PM +0100, Alfredo Braunstein wrote:
>>
>>> In which situations you think we need it to remain valid?
>>
>> I don't understand. Clearly, search and replace, spellcheck, merge
>> changes all need a static iterator
On Thu, Oct 30, 2003 at 03:56:24PM +0100, Alfredo Braunstein wrote:
> Is not "around", you know exactly *where*, don't you?.
Not quite. We must allow the user to make additional changes.
So we'd need something that'd pick up the cursor position into your
iterator and continue from there.
regar
John Levon wrote:
> On Thu, Oct 30, 2003 at 01:08:25PM +0100, Alfredo Braunstein wrote:
>
>> In which situations you think we need it to remain valid?
>
> I don't understand. Clearly, search and replace, spellcheck, merge
> changes all need a static iterator position whilst things change around
On Thu, Oct 30, 2003 at 01:08:25PM +0100, Alfredo Braunstein wrote:
> In which situations you think we need it to remain valid?
I don't understand. Clearly, search and replace, spellcheck, merge
changes all need a static iterator position whilst things change around
them ...
regards
john
--
Kh
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> IMO, we should separate the concept of 'iterator' from that of
>> 'cursor'. I believe that this is André's view too. (Witness his
>> occassional comments that the math cursor is a hack.) Implement the
>> cursor using the position iterator, by
Angus Leeming wrote:
> IMO, we should separate the concept of 'iterator' from that of
> 'cursor'. I believe that this is AndrÃ's view too. (Witness his
> occassional comments that the math cursor is a hack.) Implement the
> cursor using the position iterator, by all means, but enable search
> and
Angus Leeming wrote:
> Of course, having a centralised dispatch should make it quite easy to
> keep your PosIteratorItem valid. Why not add something to the block
> that Andrà uses to keep Cursor valid and see whether that can be made
> to work?
In which situations you think we need it to remain
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> Of course, having a centralised dispatch should make it quite easy
>> to keep your PosIteratorItem valid. Why not add something to the
>> block that André uses to keep Cursor valid and see whether that can
>> be made to work?
>
> In which sit
Alfredo Braunstein wrote:
>> So, how do you envisage keeping the data valid?
>
> I don't know if that is desirable. Maybe we need some simple structs
> after all. I don't know how the Cursor class will behave in this
> respect. As it is based in paroffsets, it seems that it can lose
> track if for
Angus Leeming wrote:
> I think that this is fantastic. Truly it is great to know someone who
> can turn the complex into the simple. You did it to the code in
> src/graphics and now you do it to the can of worms that is the LyX
> core. Bravo!
Angus, I certainly don't deserve this compliment, but
Alfredo Braunstein wrote:
> I've implemented a simple, standalone PosIterator, that iterates
> over cursor positions in a document (i.e. valid char positions +
> paragraph ends). I've made this in principle beacuse it would make
> trivial to fix find & replace for instance.
>
> Now, I understand
Lars Gullik BjÃnnes wrote:
> I'll comment more after thinging abit about this.
Thanks.
> | private:
> | std::vector stack_;
> | };
>
> Is it a stack or a vector? do you need access to any other element
> thatn the top one? perhaps a std::stack would do?
Right, I think I std::stack woul
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| - this seems to work now
| - it is completely standalone (no Textcursor, no bv, rows, dispatch
| or whatever... nothing. And so terribly simple). In other words,
| it doesn't have the burden of acting transitionally
39 matches
Mail list logo
