Loading ...
Sorry, an error occurred while loading the content.

[patch] undo-persistence

Expand Messages
  • Christian Brabandt
    Hi Bram, here are 3 patches that improve the undo-persistence. Patch [1] sets the current save number to the last save number after loading a file (see how
    Message 1 of 5 , Sep 3, 2010
    • 0 Attachment
      Hi Bram,
      here are 3 patches that improve the undo-persistence.

      Patch [1] sets the current save number to the last save number after
      loading a file (see how 'save_cur' in the undotree() function is set to
      zero after loading a file while it should probably be the same as
      'save_last'; compare this to how 'save_cur' changes after going back one
      step in the undotree and return to the original state [e.g. after g-g+
      'save_cur' is the same as 'save_last'])

      Patch [2] Lets changenr() return the current save_nr, if the optional
      argument save_nr is given and is one.
      Currently, it is not possible to know after which save nr the buffer is,
      after moving around in the undo tree and :later <nr>f and :earlier <nr>f
      jump around only relative to the current save marks. So to decide what
      <nr> should be, one needs to know, after which save_nr the current
      buffer is.

      Patch [3] :earlier <nr>f and :later <nr>f only move relative to the
      current save number of the buffer. I think it would be nice to jump
      right to the actual save number, as it is output with :undolist.
      This patch implements :undo <nr>f to let you jump right after the
      specified save number. (Please verify, that the traversing the undo-tree
      structure works as it is supposed to be. I am not sure this is correct,
      though it seems to work)

      [1]: /home/chrisbra/undo_save_nr_cur.patch
      [2]: /home/chrisbra/changenr.patch
      [3]: /home/chrisbra/undo_savenr.patch

      regards,
      Christian

      --
      You received this message from the "vim_dev" maillist.
      Do not top-post! Type your reply below the text you are replying to.
      For more information, visit http://www.vim.org/maillist.php
    • Bram Moolenaar
      ... That looks good. Now after loading a file :earlier 1f goes to the last-but-one saved state. ... Why do this with an argument? It makes more sense to
      Message 2 of 5 , Nov 3, 2010
      • 0 Attachment
        Christian Brabandt wrote:

        > Hi Bram,
        > here are 3 patches that improve the undo-persistence.
        >
        > Patch [1] sets the current save number to the last save number after
        > loading a file (see how 'save_cur' in the undotree() function is set to
        > zero after loading a file while it should probably be the same as
        > 'save_last'; compare this to how 'save_cur' changes after going back one
        > step in the undotree and return to the original state [e.g. after g-g+
        > 'save_cur' is the same as 'save_last'])

        That looks good. Now after loading a file ":earlier 1f" goes to the
        last-but-one saved state.

        > Patch [2] Lets changenr() return the current save_nr, if the optional
        > argument save_nr is given and is one.
        > Currently, it is not possible to know after which save nr the buffer is,
        > after moving around in the undo tree and :later <nr>f and :earlier <nr>f
        > jump around only relative to the current save marks. So to decide what
        > <nr> should be, one needs to know, after which save_nr the current
        > buffer is.

        Why do this with an argument? It makes more sense to add a new function
        for this. Although the "save_cur" entry returned by undotree() already
        has this number. It would be rarely used, thus a separate function
        isn't really needed.

        > Patch [3] :earlier <nr>f and :later <nr>f only move relative to the
        > current save number of the buffer. I think it would be nice to jump
        > right to the actual save number, as it is output with :undolist.
        > This patch implements :undo <nr>f to let you jump right after the
        > specified save number. (Please verify, that the traversing the undo-tree
        > structure works as it is supposed to be. I am not sure this is correct,
        > though it seems to work)

        The :undo command only moves in the current undo branch. This would make
        it go to different branches, I don't like that.

        Copying the logic to find the position in the undo tree is not a good
        idea. Let's keep this in undo_time(). Setting "target" to the right
        value seems the only thing needed there.

        On the other hand, does a user really remember the absolute save number?
        Even the one from :undolist is not clear about what the state of the
        text was. It only mentions the last save in a branch.

        I notice that ":undolist" only mentions the time, but now we have
        persistent undo that may be several days ago. I'll fix that.


        --
        [Autumn changed into Winter ... Winter changed into Spring ... Spring
        changed back into Autumn and Autumn gave Winter and Spring a miss and
        went straight on into Summer ... Until one day ...]
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ download, build and distribute -- http://www.A-A-P.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        You received this message from the "vim_dev" maillist.
        Do not top-post! Type your reply below the text you are replying to.
        For more information, visit http://www.vim.org/maillist.php
      • Christian Brabandt
        Hi Bram! ... Thanks for including it. ... Agreed, though the undotree() output is a little bit hard to read if you have many many undo branches. ... Hm? If I
        Message 3 of 5 , Nov 4, 2010
        • 0 Attachment
          Hi Bram!

          On Mi, 03 Nov 2010, Bram Moolenaar wrote:

          >
          > Christian Brabandt wrote:
          >
          > > Hi Bram,
          > > here are 3 patches that improve the undo-persistence.
          > >
          > > Patch [1] sets the current save number to the last save number after
          > > loading a file (see how 'save_cur' in the undotree() function is set to
          > > zero after loading a file while it should probably be the same as
          > > 'save_last'; compare this to how 'save_cur' changes after going back one
          > > step in the undotree and return to the original state [e.g. after g-g+
          > > 'save_cur' is the same as 'save_last'])
          >
          > That looks good. Now after loading a file ":earlier 1f" goes to the
          > last-but-one saved state.

          Thanks for including it.

          >
          > > Patch [2] Lets changenr() return the current save_nr, if the optional
          > > argument save_nr is given and is one.
          > > Currently, it is not possible to know after which save nr the buffer is,
          > > after moving around in the undo tree and :later <nr>f and :earlier <nr>f
          > > jump around only relative to the current save marks. So to decide what
          > > <nr> should be, one needs to know, after which save_nr the current
          > > buffer is.
          >
          > Why do this with an argument? It makes more sense to add a new function
          > for this. Although the "save_cur" entry returned by undotree() already
          > has this number. It would be rarely used, thus a separate function
          > isn't really needed.

          Agreed, though the undotree() output is a little bit hard to read if you
          have many many undo branches.

          > > Patch [3] :earlier <nr>f and :later <nr>f only move relative to the
          > > current save number of the buffer. I think it would be nice to jump
          > > right to the actual save number, as it is output with :undolist.
          > > This patch implements :undo <nr>f to let you jump right after the
          > > specified save number. (Please verify, that the traversing the undo-tree
          > > structure works as it is supposed to be. I am not sure this is correct,
          > > though it seems to work)
          >
          > The :undo command only moves in the current undo branch. This would make
          > it go to different branches, I don't like that.

          Hm? If I use :undo {N} it moves to any branch that was specified,
          doesn't it?

          > Copying the logic to find the position in the undo tree is not a good
          > idea. Let's keep this in undo_time(). Setting "target" to the right
          > value seems the only thing needed there.
          >
          > On the other hand, does a user really remember the absolute save number?
          > Even the one from :undolist is not clear about what the state of the
          > text was. It only mentions the last save in a branch.

          Don't know. But since the undotree() function can gives you all save
          numbers, it would make sense to jump right after that.

          > I notice that ":undolist" only mentions the time, but now we have
          > persistent undo that may be several days ago. I'll fix that.

          Thanks. I noticed that when working on the histwin plugin. Though there
          I switched to the undotree() function after patch 7.3.005 (I believe),
          which returns the correct time (and I can format it as needed).

          regards,
          Christian

          --
          You received this message from the "vim_dev" maillist.
          Do not top-post! Type your reply below the text you are replying to.
          For more information, visit http://www.vim.org/maillist.php
        • Bram Moolenaar
          ... Right, it s already inconsistent. A number for u means the number of times to undo, for :undo it means a change number to jump to. Hmm, in that
          Message 4 of 5 , Nov 4, 2010
          • 0 Attachment
            Christian Brabandt wrote:

            > > > Patch [3] :earlier <nr>f and :later <nr>f only move relative to the
            > > > current save number of the buffer. I think it would be nice to jump
            > > > right to the actual save number, as it is output with :undolist.
            > > > This patch implements :undo <nr>f to let you jump right after the
            > > > specified save number. (Please verify, that the traversing the undo-tree
            > > > structure works as it is supposed to be. I am not sure this is correct,
            > > > though it seems to work)
            > >
            > > The :undo command only moves in the current undo branch. This would make
            > > it go to different branches, I don't like that.
            >
            > Hm? If I use :undo {N} it moves to any branch that was specified,
            > doesn't it?

            Right, it's already inconsistent. A number for "u" means the number of
            times to undo, for ":undo" it means a change number to jump to. Hmm, in
            that context ":undo 123f" does make sense. But the relation with
            ":earlier 1f" and :later 1f" is a bit messy. We could introduce a new
            command for that. Could be ":undojump" and accept the same arguments
            are :earlier and :later, but as an absolute number. Could also make
            this work for time (conversion from string to seconds might not be so
            easy though).

            > > Copying the logic to find the position in the undo tree is not a good
            > > idea. Let's keep this in undo_time(). Setting "target" to the right
            > > value seems the only thing needed there.
            > >
            > > On the other hand, does a user really remember the absolute save number?
            > > Even the one from :undolist is not clear about what the state of the
            > > text was. It only mentions the last save in a branch.
            >
            > Don't know. But since the undotree() function can gives you all save
            > numbers, it would make sense to jump right after that.

            Well, if you are using that function you can also see how many saves you
            have to go forward or backward. I was wondering how much it helps to be
            able to do this directly. Also because it adds quite a bit of code.

            This is a hint for a much simpler implementation: subtract the current
            save number from the desired one and executed an :earlier or :laster
            command. Wouldn't that work?

            --
            TIM: That is not an ordinary rabbit ... 'tis the most foul cruel and
            bad-tempered thing you ever set eyes on.
            ROBIN: You tit. I soiled my armour I was so scared!
            "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
            \\\ download, build and distribute -- http://www.A-A-P.org ///
            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

            --
            You received this message from the "vim_dev" maillist.
            Do not top-post! Type your reply below the text you are replying to.
            For more information, visit http://www.vim.org/maillist.php
          • Christian Brabandt
            Hi Bram! ... I wouldn t do this. I like it the way it is. u jumps within the current undo branch and :undo jumps to any other (absolute) position. One could
            Message 5 of 5 , Nov 5, 2010
            • 0 Attachment
              Hi Bram!

              On Do, 04 Nov 2010, Bram Moolenaar wrote:

              > Right, it's already inconsistent. A number for "u" means the number of
              > times to undo, for ":undo" it means a change number to jump to. Hmm, in
              > that context ":undo 123f" does make sense. But the relation with
              > ":earlier 1f" and :later 1f" is a bit messy. We could introduce a new
              > command for that. Could be ":undojump" and accept the same arguments
              > are :earlier and :later, but as an absolute number. Could also make
              > this work for time (conversion from string to seconds might not be so
              > easy though).

              I wouldn't do this. I like it the way it is. 'u' jumps within the
              current undo branch and :undo jumps to any other (absolute) position.
              One could make it accept an absolute date/time stamp. But IMHO there is
              no need for :undojump, IMHO.

              > This is a hint for a much simpler implementation: subtract the current
              > save number from the desired one and executed an :earlier or :laster
              > command. Wouldn't that work?

              Like the attached patch does? Or do you mean to implement it in
              VimScript, like this:

              func! s:Undo(...)
              let nr=undotree().save_cur
              if empty(a:000)
              exe "earlier " . nr . "f"
              elseif (a:1 - nr < 0)
              exe "earlier " . (nr - a:1) . "f"
              else
              exe "later " . (a:1 - nr) . "f"
              endif
              endfunc
              com! -nargs=? UndoSave call s:Undo(<q-args>)

              regards,
              Christian

              --
              You received this message from the "vim_dev" maillist.
              Do not top-post! Type your reply below the text you are replying to.
              For more information, visit http://www.vim.org/maillist.php
            Your message has been successfully submitted and would be delivered to recipients shortly.