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 o
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.
th
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
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 tha
> "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 .lyx/places/#home#
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
> .lyx/places/#home#lars
On Wed, Jan 14, 2004 at 03:33:49PM +0100, Lars Gullik Bjønnes wrote:
> 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
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
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
> >pos
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 would seem to indicate a buffer cursor.
(Should LyX do this? Dunno. Ex
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 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),
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: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 dif
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
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 l
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?
>
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, the
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,
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 does emacs do if you have an active selecti
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 cha
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 bu
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 B
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 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? Even
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 a
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
> >> | proper
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 ancho
On Tue, Jan 13, 2004 at 06:46:35PM +, Angus Leeming wrote:
> 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 scr
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
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 s
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
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
> diffe
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
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
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 tha
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
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 ancho
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
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 c
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 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 c
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'
Wh
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 o
44 matches
Mail list logo
