On Wed, Jan 14, 2004 at 07:29:56PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
We just dump the shiny global cursor (without that inset caching bit).
cell0/par0/pos0
cell1/par1/pos1
cell2/par2/pos2
cell3/par2/pos3
Alternatively a simple ParIterator offset + pos
On Wed, Jan 14, 2004 at 07:29:56PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > We just dump the shiny global cursor (without that inset caching bit).
> >
> > cell0/par0/pos0
> > cell1/par1/pos1
> > cell2/par2/pos2
> > cell3/par2/pos3
>
> Alternatively a simple ParIterator
Lars Gullik Bjnnes wrote:
Ok... then I lean towards a view property instead of a buffer
property.
Why have cursor in the view and the anchor in the buffer?
Agreed.
Alfredo
On Tue, Jan 13, 2004 at 07:03:17PM +, Angus Leeming wrote:
Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a
| Buffer property, right? Eventually that is.
?? Ok... what is the anchor used for?
On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik Bjønnes wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right?
Andre Poenitz wrote:
Hm, I just noticed, vim has one cursor per buffer as well.
So all the cursor stuff should be shifted to the buffer in the end.
I don't think so: you don't lose the cursor position when you change views,
don't you? If yes, I really don't see the purpose of multiple views at
Andre Poenitz [EMAIL PROTECTED] writes:
| On Tue, Jan 13, 2004 at 07:03:17PM +, Angus Leeming wrote:
Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a
| Buffer property, right? Eventually that is.
Andre Poenitz [EMAIL PROTECTED] writes:
[...]
| I am not sure about this as I don't really know how multiple views of
| the same buffer would look like.
| If we have one cursor per view (i.e. possibly more than one per buffer),
| cursor and anchor should belong to BufferView. If there's just
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik Bjønnes wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but
Andre Poenitz wrote:
On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik Bjnnes wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Lars Gullik Bjnnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
|
On Wed, Jan 14, 2004 at 09:43:53AM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
Hm, I just noticed, vim has one cursor per buffer as well.
So all the cursor stuff should be shifted to the buffer in the end.
I don't think so: you don't lose the cursor position when you change
On Wed, Jan 14, 2004 at 09:51:36AM +0100, Alfredo Braunstein wrote:
From what I can see, vim has one cursor per
buffer, not per view. There was a message
here that emacs does the same. So one could
get the impression 'per buffer' was the
consensus in the outer world...
No, it is one
Andre Poenitz wrote:
On Wed, Jan 14, 2004 at 09:49:08AM +0100, Lars Gullik Bjnnes wrote:
| So one could
| get the impression 'per buffer' was the
| consensus in the outer world...
It is not.
Ok, so would 'everything goes to the view' settle that issue?
Thinking better, there are two
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Jan 14, 2004 at 09:49:08AM +0100, Lars Gullik Bjønnes wrote:
| So one could
| get the impression 'per buffer' was the
| consensus in the outer world...
It is not.
| Ok, so would 'everything goes to the view' settle that issue?
| Btw: What
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Emacs has got it completely wrong IMO: the anchor is per doc, but the cursor
| is per view. So when you switch you get a different selection if the cursor
| is placed differently. (at least emacs on X)
Yes. You are right.
It seems that what we'd
Lars Gullik Bjnnes wrote:
It seems that what we'd like to see is both cursor and anchor per
view.
Agreed. We can later chose to show only one active selection per LyX session
(remembering the others), or per buffer or whatever.
Alfredo
On Wed, Jan 14, 2004 at 10:08:14AM +0100, Lars Gullik Bjønnes wrote:
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Emacs has got it completely wrong IMO: the anchor is per doc, but the cursor
| is per view. So when you switch you get a different selection if the cursor
| is placed
Andre Poenitz [EMAIL PROTECTED] writes:
| Ok. This was yesterday's direction. So I'll just continue and those who
| are interested try to make up their minds on how a perfect solution
| would look like.
| Is that a plan?
yes.
--
Lgb
On Wed, Jan 14, 2004 at 10:15:47AM +0100, Alfredo Braunstein spake thusly:
Lars Gullik Bjønnes wrote:
It seems that what we'd like to see is both cursor and anchor per
view.
Agreed. We can later chose to show only one active selection per LyX session
(remembering the others), or per
Martin Vermeer [EMAIL PROTECTED] writes:
| Ehh, another thing to consider: do we want to save these?
| I once in a previous life wrote an multiple-window, multiple file
| editor that saved its state on exit, including the current cursor
| position. This would seem to indicate a buffer cursor.
|
On Wed, Jan 14, 2004 at 03:31:04PM +0100, Helge Hafting wrote:
Martin Vermeer wrote:
Ehh, another thing to consider: do we want to save these?
I once in a previous life wrote an multiple-window, multiple file
editor that saved its state on exit, including the current cursor
position. This
Andre Poenitz [EMAIL PROTECTED] writes:
| On Wed, Jan 14, 2004 at 03:31:04PM +0100, Helge Hafting wrote:
Martin Vermeer wrote:
Ehh, another thing to consider: do we want to save these?
I once in a previous life wrote an multiple-window, multiple file
editor that saved its state on exit,
On Wed, Jan 14, 2004 at 03:18:23PM +0100, Lars Gullik Bjønnes spake thusly:
If we put it back again, we should not have it as part of the buffer,
but do as emacs does and have a separate file where stuff like that is
stored (.emacs-places or something). We could have
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars If we put it back again, we should not have it as part of the
Lars buffer, but do as emacs does and have a separate file where
Lars stuff like that is stored (.emacs-places or something). We could
Lars have
On Wed, Jan 14, 2004 at 03:47:24PM +0100, Jean-Marc Lasgouttes wrote:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars If we put it back again, we should not have it as part of the
Lars buffer, but do as emacs does and have a separate file where
Lars stuff like that is stored
Andre Poenitz wrote:
We just dump the shiny global cursor (without that inset caching bit).
cell0/par0/pos0
cell1/par1/pos1
cell2/par2/pos2
cell3/par2/pos3
Alternatively a simple ParIterator offset + pos would do it.
Alfredo
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
We just dump the shiny global cursor (without that inset caching bit).
cell0/par0/pos0
cell1/par1/pos1
cell2/par2/pos2
cell3/par2/pos3
| Alternatively a simple ParIterator offset + pos would do it.
that is what I
Lars Gullik BjÃnnes wrote:
> Ok... then I lean towards a view property instead of a buffer
> property.
>
> Why have cursor in the view and the anchor in the buffer?
Agreed.
Alfredo
On Tue, Jan 13, 2004 at 07:03:17PM +, Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
>
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> >
> > | ...and anchor isn't really a BufferView property but rather a
> > | Buffer property, right? Eventually that is.
> >
> > ?? Ok... what is the
On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> >
> >> Angus Leeming <[EMAIL PROTECTED]> writes:
> >>
> >> | ...and anchor isn't really a BufferView property but rather a Buffer
> >> |
Andre Poenitz wrote:
> Hm, I just noticed, vim has one cursor per buffer as well.
> So all the cursor stuff should be shifted to the buffer in the end.
I don't think so: you don't lose the cursor position when you change views,
don't you? If yes, I really don't see the purpose of multiple views
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Jan 13, 2004 at 07:03:17PM +, Angus Leeming wrote:
>> Lars Gullik Bjønnes wrote:
>>
>> > Angus Leeming <[EMAIL PROTECTED]> writes:
>> >
>> > | ...and anchor isn't really a BufferView property but rather a
>> > | Buffer property, right?
Andre Poenitz <[EMAIL PROTECTED]> writes:
[...]
| I am not sure about this as I don't really know how multiple views of
| the same buffer would look like.
>
| If we have one cursor per view (i.e. possibly more than one per buffer),
| cursor and anchor should belong to BufferView. If there's just
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik Bjønnes wrote:
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik Bjønnes wrote:
>> >
>> >> Angus Leeming <[EMAIL PROTECTED]> writes:
>> >>
>> >> | ...and anchor isn't really a
Andre Poenitz wrote:
> On Wed, Jan 14, 2004 at 01:03:09AM +0100, Lars Gullik BjÃnnes wrote:
>> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik BjÃÂnnes wrote:
>> >
>> >> Angus Leeming <[EMAIL PROTECTED]> writes:
>> >>
>> >> | ...and anchor isn't really a BufferView property
On Wed, Jan 14, 2004 at 09:43:53AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Hm, I just noticed, vim has one cursor per buffer as well.
> > So all the cursor stuff should be shifted to the buffer in the end.
>
> I don't think so: you don't lose the cursor position when you
On Wed, Jan 14, 2004 at 09:51:36AM +0100, Alfredo Braunstein wrote:
> > From what I can see, vim has one cursor per
> > buffer, not per view. There was a message
> > here that emacs does the same. So one could
> > get the impression 'per buffer' was the
> > consensus in the outer world...
>
> No,
Andre Poenitz wrote:
> On Wed, Jan 14, 2004 at 09:49:08AM +0100, Lars Gullik BjÃnnes wrote:
>> | So one could
>> | get the impression 'per buffer' was the
>> | consensus in the outer world...
>>
>> It is not.
>
> Ok, so would 'everything goes to the view' settle that issue?
Thinking better,
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 14, 2004 at 09:49:08AM +0100, Lars Gullik Bjønnes wrote:
>> | So one could
>> | get the impression 'per buffer' was the
>> | consensus in the outer world...
>>
>> It is not.
>
| Ok, so would 'everything goes to the view' settle that issue?
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Emacs has got it completely wrong IMO: the anchor is per doc, but the cursor
| is per view. So when you switch you get a different selection if the cursor
| is placed differently. (at least emacs on X)
Yes. You are right.
It seems that what we'd
Lars Gullik BjÃnnes wrote:
> It seems that what we'd like to see is both cursor and anchor per
> view.
Agreed. We can later chose to show only one active selection per LyX session
(remembering the others), or per buffer or whatever.
Alfredo
On Wed, Jan 14, 2004 at 10:08:14AM +0100, Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Emacs has got it completely wrong IMO: the anchor is per doc, but the cursor
> | is per view. So when you switch you get a different selection if the cursor
> | is placed
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Ok. This was yesterday's direction. So I'll just continue and those who
| are interested try to make up their minds on how a perfect solution
| would look like.
>
| Is that a plan?
yes.
--
Lgb
On Wed, Jan 14, 2004 at 10:15:47AM +0100, Alfredo Braunstein spake thusly:
>
> Lars Gullik Bjønnes wrote:
>
> > It seems that what we'd like to see is both cursor and anchor per
> > view.
>
> Agreed. We can later chose to show only one active selection per LyX session
> (remembering the
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Ehh, another thing to consider: do we want to save these?
>
| I once in a previous life wrote an multiple-window, multiple file
| editor that saved its state on exit, including the current cursor
| position. This would seem to indicate a buffer cursor.
On Wed, Jan 14, 2004 at 03:31:04PM +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
>
> >Ehh, another thing to consider: do we want to save these?
> >
> >I once in a previous life wrote an multiple-window, multiple file
> >editor that saved its state on exit, including the current cursor
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jan 14, 2004 at 03:31:04PM +0100, Helge Hafting wrote:
>> Martin Vermeer wrote:
>>
>> >Ehh, another thing to consider: do we want to save these?
>> >
>> >I once in a previous life wrote an multiple-window, multiple file
>> >editor that saved
On Wed, Jan 14, 2004 at 03:18:23PM +0100, Lars Gullik Bjønnes spake thusly:
> If we put it back again, we should not have it as part of the buffer,
> but do as emacs does and have a separate file where stuff like that is
> stored (.emacs-places or something). We could have
>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> If we put it back again, we should not have it as part of the
Lars> buffer, but do as emacs does and have a separate file where
Lars> stuff like that is stored (.emacs-places or something). We could
Lars> have
On Wed, Jan 14, 2004 at 03:47:24PM +0100, Jean-Marc Lasgouttes wrote:
> > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> If we put it back again, we should not have it as part of the
> Lars> buffer, but do as emacs does and have a separate file where
> Lars> stuff like
Andre Poenitz wrote:
> We just dump the shiny global cursor (without that inset caching bit).
>
> cell0/par0/pos0
> cell1/par1/pos1
> cell2/par2/pos2
> cell3/par2/pos3
Alternatively a simple ParIterator offset + pos would do it.
Alfredo
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> We just dump the shiny global cursor (without that inset caching bit).
>>
>> cell0/par0/pos0
>> cell1/par1/pos1
>> cell2/par2/pos2
>> cell3/par2/pos3
>
| Alternatively a simple ParIterator offset + pos would do it.
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Andre'
--
Those who desire to give up Freedom in
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global
place (LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Andre'
What's the
On Tue, Jan 13, 2004 at 05:48:58PM +, Angus Leeming wrote:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global
place (LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Why do we need a stack
On Tue, Jan 13, 2004 at 07:08:35PM +0100, Alfredo Braunstein wrote:
Andre Poenitz wrote:
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices:
Andre Poenitz wrote:
For this, the topmost anchor item would still suffice. However
that feature is a pain to use if there's no way back in case one
accidentally overshoots an inset boundary. To find the way back, we'd
need the stack.
Fair enough, I forgot that one.
Alfredo
Andre Poenitz wrote:
fullCursor is the full cursor, ie. the two stacks (cursor + anchor)
of CursorSlices.
cursor is the topmost slice of the cursor stack, i.e. the position
where the blinking thing is drawn on screen.
I understand that the naming is non-perfect here...
...and anchor
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
--
Lgb
Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a
| Buffer property, right? Eventually that is.
?? Ok... what is the anchor used for?
The start of any selection. It doesn't make sense to have more than
one
Lars Gullik Bjnnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
The selection runs from anchor to cursor.
Alfredo
Angus Leeming wrote:
The start of any selection. It doesn't make sense to have more than
one start point. Indeed emacs has only one per buffer too.
I'm not sure it doesn't make sense to have different selections in different
views...
Alfredo
On Tuesday 13 January 2004 02:19 pm, Alfredo Braunstein wrote:
Angus Leeming wrote:
The start of any selection. It doesn't make sense to have more than
one start point. Indeed emacs has only one per buffer too.
I'm not sure it doesn't make sense to have different selections in
different
Kuba Ober wrote:
A per-view selection has the potential of least confusion, methinks. I
mean we either have one selection per LyX instance, or one selection per
view. By extrapolation (tm :), the middle ground of one selection per
document is kind of artificial, methinks. It's like being
Alfredo Braunstein [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
| The selection runs from
This patch got larger than expected...
It basically moves the selection anchor handling to the same global place
(LCursor) as the real cursor.
LCursor now contains two stacks of cursor slices: one for the cursor
proper and one for the anchor.
Andre'
--
Those who desire to give up Freedom in
Andre Poenitz wrote:
>
> This patch got larger than expected...
>
> It basically moves the selection anchor handling to the same global
> place (LCursor) as the real cursor.
>
> LCursor now contains two stacks of cursor slices: one for the cursor
> proper and one for the anchor.
>
> Andre'
On Tue, Jan 13, 2004 at 05:48:58PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> >
> > This patch got larger than expected...
> >
> > It basically moves the selection anchor handling to the same global
> > place (LCursor) as the real cursor.
> >
> > LCursor now contains two stacks of
Andre Poenitz wrote:
> This patch got larger than expected...
>
> It basically moves the selection anchor handling to the same global place
> (LCursor) as the real cursor.
>
> LCursor now contains two stacks of cursor slices: one for the cursor
> proper and one for the anchor.
Why do we need a
On Tue, Jan 13, 2004 at 07:08:35PM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > This patch got larger than expected...
> >
> > It basically moves the selection anchor handling to the same global place
> > (LCursor) as the real cursor.
> >
> > LCursor now contains two stacks of
Andre Poenitz wrote:
> For this, the topmost anchor item would still suffice. However
> that feature is a pain to use if there's no way back in case one
> accidentally overshoots an inset boundary. To find the way back, we'd
> need the stack.
Fair enough, I forgot that one.
Alfredo
Andre Poenitz wrote:
> fullCursor is the full cursor, ie. the two stacks (cursor + anchor)
> of CursorSlices.
>
> cursor is the topmost slice of the cursor stack, i.e. the position
> where the blinking thing is drawn on screen.
>
> I understand that the naming is non-perfect here...
...and
Angus Leeming <[EMAIL PROTECTED]> writes:
| ...and anchor isn't really a BufferView property but rather a Buffer
| property, right? Eventually that is.
?? Ok... what is the anchor used for?
--
Lgb
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | ...and anchor isn't really a BufferView property but rather a
> | Buffer property, right? Eventually that is.
>
> ?? Ok... what is the anchor used for?
The start of any selection. It doesn't make sense to have more
Lars Gullik BjÃnnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | ...and anchor isn't really a BufferView property but rather a Buffer
> | property, right? Eventually that is.
>
> ?? Ok... what is the anchor used for?
The selection runs from anchor to cursor.
Alfredo
Angus Leeming wrote:
> The start of any selection. It doesn't make sense to have more than
> one start point. Indeed emacs has only one per buffer too.
I'm not sure it doesn't make sense to have different selections in different
views...
Alfredo
On Tuesday 13 January 2004 02:19 pm, Alfredo Braunstein wrote:
> Angus Leeming wrote:
> > The start of any selection. It doesn't make sense to have more than
> > one start point. Indeed emacs has only one per buffer too.
>
> I'm not sure it doesn't make sense to have different selections in
>
Kuba Ober wrote:
> A per-view selection has the potential of "least confusion", methinks. I
> mean we either have one selection per LyX instance, or one selection per
> view. By extrapolation (tm :), the middle ground of one selection per
> document is kind of artificial, methinks. It's like
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> Angus Leeming <[EMAIL PROTECTED]> writes:
>>
>> | ...and anchor isn't really a BufferView property but rather a Buffer
>> | property, right? Eventually that is.
>>
>> ?? Ok... what is the anchor used for?
>
| The
80 matches
Mail list logo
