Re: r36771 - lyx-devel/trunk/src
On 12/08/2010 02:45 PM, Vincent van Ravesteijn wrote: While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what you just redid. There are also forms of this bug involving just redo, but I can't find one right now. Presumably, we need to record the state of the cursor before the move. This would mean that the Undo stack really should not be a Buffer member but a BufferView member. Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. 2) the way the undo action is shown to the user: this must be dependent on the BufferView/Cursor. This is the reason why the Undo/redo must be performed via the Cursor, no way around it. Use cases: 1) undo/redo on same view: * char insertion on view 1 * scroll elsewhere * undo on view 1 - cursor must go to undo position * redo on view 1 - cursor must stay there Last time I checked/modify this stuff this was correctly working on trunk/ 2) undo/redo on two view of same buffer * char insertion on view 1 * switch to view 2 * undo on view 2 - cursor must go to undo position, that is the char insertion done in view 1 * redo on view 2 - cursor must stay there Last time I checked/modify this stuff this was also correctly working on trunk/ Abdel.
Re: r36771 - lyx-devel/trunk/src
Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. JMarc
Re: r36771 - lyx-devel/trunk/src
Le 8 déc. 2010 à 15:01, Vincent van Ravesteijn a écrit : By the way, I see now a worse bug: 1. insert e.g. have some lower capital text 2. change to :Ahave some Blower capital textC 3. press undo. Now A, B and C disappears all together. Yuck! This is an old bug, though. JMarc
Re: r36771 - lyx-devel/trunk/src
On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. I think yes: an undo should be atomic. Presumably you can not do two changes at the same time on one given buffer. So no, only one stack. Abdel.
Re: r36771 - lyx-devel/trunk/src
On 12/09/2010 10:52 AM, Abdelrazak Younes wrote: On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. I think yes: an undo should be atomic. Presumably you can not do two changes at the same time on one given buffer. So no, only one stack. Side note: If you think more about it (and I remember giving this a long thought at the time :-)) having different stacks for different views is not manageable. First from a programming point of view, because you will have to sanitize the undo stack of all bufferviews. Second, from the user point of view, because she does one action after the other, it does not seem natural if when switching from one view to the other, you loose some undo... ok I know women supposedly are able to do many things at the same time but she still have only one keyboard :-) Abdel.
Re: r36771 - lyx-devel/trunk/src
On 12/08/2010 02:45 PM, Vincent van Ravesteijn wrote: While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what you just redid. There are also forms of this bug involving just redo, but I can't find one right now. Presumably, we need to record the state of the cursor before the move. This would mean that the Undo stack really should not be a Buffer member but a BufferView member. Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. 2) the way the undo action is shown to the user: this must be dependent on the BufferView/Cursor. This is the reason why the Undo/redo must be performed via the Cursor, no way around it. Use cases: 1) undo/redo on same view: * char insertion on view 1 * scroll elsewhere * undo on view 1 -> cursor must go to undo position * redo on view 1 -> cursor must stay there Last time I checked/modify this stuff this was correctly working on trunk/ 2) undo/redo on two view of same buffer * char insertion on view 1 * switch to view 2 * undo on view 2 -> cursor must go to undo position, that is the char insertion done in view 1 * redo on view 2 -> cursor must stay there Last time I checked/modify this stuff this was also correctly working on trunk/ Abdel.
Re: r36771 - lyx-devel/trunk/src
Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : >> Now that we are on it, might be more appropriate anyway. Undo is (I >> think) a user interface component and BufferView is responsible for >> how the Buffer is presented to the user and how the user interacts >> with the Buffer. >> > > You have two components to the Undo: > > 1) the content focused: this is the undo stack, it must be dependent on the > buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. JMarc
Re: r36771 - lyx-devel/trunk/src
Le 8 déc. 2010 à 15:01, Vincent van Ravesteijn a écrit : > By the way, I see now a worse bug: > > 1. insert e.g. "have some lower capital text" > 2. change to :"Ahave some Blower capital textC" > 3. press undo. > > Now A, B and C disappears all together. Yuck! This is an old bug, though. JMarc
Re: r36771 - lyx-devel/trunk/src
On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. I think yes: an undo should be atomic. Presumably you can not do two changes at the same time on one given buffer. So no, only one stack. Abdel.
Re: r36771 - lyx-devel/trunk/src
On 12/09/2010 10:52 AM, Abdelrazak Younes wrote: On 12/09/2010 09:30 AM, Jean-Marc Lasgouttes wrote: Le 9 déc. 2010 à 09:19, Abdelrazak Younes a écrit : Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. You have two components to the Undo: 1) the content focused: this is the undo stack, it must be dependent on the buffer, independent of the view. Just a question: should it really be independent of the view? If I edit two parts of a text, presumably I want two undo stacks. I think yes: an undo should be atomic. Presumably you can not do two changes at the same time on one given buffer. So no, only one stack. Side note: If you think more about it (and I remember giving this a long thought at the time :-)) having different stacks for different views is not manageable. First from a programming point of view, because you will have to sanitize the undo stack of all bufferviews. Second, from the user point of view, because she does one action after the other, it does not seem natural if when switching from one view to the other, you loose some undo... ok I know women supposedly are able to do many things at the same time but she still have only one keyboard :-) Abdel.
Re: r36771 - lyx-devel/trunk/src
On 12/08/2010 05:04 AM, lasgout...@lyx.org wrote: Author: lasgouttes Date: Wed Dec 8 11:04:07 2010 New Revision: 36771 URL: http://www.lyx.org/trac/changeset/36771 Log: Some Undo cleanup. Functionality should be unchanged - whitespace and typos in comments - make sure that the Undo::recordUndoXXX functions all go through Undo::Private::recordUndo While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what you just redid. There are also forms of this bug involving just redo, but I can't find one right now. Presumably, we need to record the state of the cursor before the move. Richard
Re: r36771 - lyx-devel/trunk/src
While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what you just redid. There are also forms of this bug involving just redo, but I can't find one right now. Presumably, we need to record the state of the cursor before the move. This would mean that the Undo stack really should not be a Buffer member but a BufferView member. Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. Vincent
Re: r36771 - lyx-devel/trunk/src
This would mean that the Undo stack really should not be a Buffer member but a BufferView member. But that would mean that you have different Undo stacks in different BufferViews. Well, not really, you do have different Undo stacks, but it is filled with the same elements as the Buffer changes in the same way (because it's the same Buffer). Only the cursor positions might be different. By the way, I see now a worse bug: 1. insert e.g. have some lower capital text 2. change to :Ahave some Blower capital textC 3. press undo. Now A, B and C disappears all together. If these edits are not in the same screen, some edits disappear without the user knowing it ! We should split up the undo group when the cursor moves. Vincent
Re: r36771 - lyx-devel/trunk/src
On 12/08/2010 05:04 AM, lasgout...@lyx.org wrote: Author: lasgouttes Date: Wed Dec 8 11:04:07 2010 New Revision: 36771 URL: http://www.lyx.org/trac/changeset/36771 Log: Some Undo cleanup. Functionality should be unchanged - whitespace and typos in comments - make sure that the Undo::recordUndoXXX functions all go through Undo::Private::recordUndo While you're at this, I wonder if you have a relatively easy fix for this bug. Add a character to a document, then go to the end of the document. Now do Undo, Redo. The redo moves you to the end of the document, so you don't actually see what you just redid. There are also forms of this bug involving just redo, but I can't find one right now. Presumably, we need to record the state of the cursor before the move. Richard
Re: r36771 - lyx-devel/trunk/src
> While you're at this, I wonder if you have a relatively easy fix for this > bug. Add a character to a document, then go to the end of the document. Now > do Undo, Redo. The redo moves you to the end of the document, so you don't > actually see what you just redid. There are also forms of this bug involving > just redo, but I can't find one right now. Presumably, we need to record the > state of the cursor before the move. > This would mean that the Undo stack really should not be a Buffer member but a BufferView member. Now that we are on it, might be more appropriate anyway. Undo is (I think) a user interface component and BufferView is responsible for how the Buffer is presented to the user and how the user interacts with the Buffer. Vincent
Re: r36771 - lyx-devel/trunk/src
> This would mean that the Undo stack really should not be a Buffer > member but a BufferView member. > But that would mean that you have different Undo stacks in different BufferViews. Well, not really, you do have different Undo stacks, but it is filled with the same elements as the Buffer changes in the same way (because it's the same Buffer). Only the cursor positions might be different. By the way, I see now a worse bug: 1. insert e.g. "have some lower capital text" 2. change to :"Ahave some Blower capital textC" 3. press undo. Now A, B and C disappears all together. If these edits are not in the same screen, some edits disappear without the user knowing it ! We should split up the undo group when the cursor moves. Vincent
