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

Re: 'l' breaks macro when run at the end of line

Expand Messages
  • Tom Sorensen
    ... No, that would be very bad. A lot of macro usage presumes that vim will stop when the macro fails. 10000@q -- I have absolutely no idea how many times I
    Message 1 of 13 , Sep 10, 2009
    • 0 Attachment
      On Thu, Sep 10, 2009 at 8:44 AM, Lech Lorens <lech.lorens@...> wrote:
      >
      > BTW unlike documentation e.g. for :global or :tabdo, documentation for
      > @ does not mention the expected behaviour if an error is encountered.
      > IMHO this means that errors should be ignored.

      No, that would be very bad. A lot of macro usage presumes that vim
      will stop when the macro fails.

      10000@q -- I have absolutely no idea how many times I need to run
      this macro, so just run it until it fails.

      Doing otherwise could result in some REALLY bad things happening at
      the failure position.

      Tom

      --~--~---------~--~----~------------~-------~--~----~
      You received this message from the "vim_dev" maillist.
      For more information, visit http://www.vim.org/maillist.php
      -~----------~----~----~----~------~----~------~--~---
    • Andy Wokula
      ... Macros and mappings are quite similar in this regard ... /error ... -- Andy --~--~---------~--~----~------------~-------~--~----~ You received this message
      Message 2 of 13 , Sep 10, 2009
      • 0 Attachment
        Lech Lorens schrieb:
        > BTW unlike documentation e.g. for :global or :tabdo, documentation for
        > @ does not mention the expected behaviour if an error is encountered.
        > IMHO this means that errors should be ignored.

        Macros and mappings are quite similar in this regard
        :h macro
        /error

        | Note that when an error is encountered (that causes an error message or beep)
        | the rest of the mapping is not executed. This is Vi-compatible.

        --
        Andy

        --~--~---------~--~----~------------~-------~--~----~
        You received this message from the "vim_dev" maillist.
        For more information, visit http://www.vim.org/maillist.php
        -~----------~----~----~----~------~----~------~--~---
      • Milan Vancura
        ... Sure. The only problem is that, in case I pointed out, the error throwing is not consistent: 99l run on the previous-to-last char of the line does NOT
        Message 3 of 13 , Sep 10, 2009
        • 0 Attachment
          >
          > Lech Lorens schrieb:
          > > BTW unlike documentation e.g. for :global or :tabdo, documentation for
          > > @ does not mention the expected behaviour if an error is encountered.
          > > IMHO this means that errors should be ignored.
          >
          > Macros and mappings are quite similar in this regard
          > :h macro
          > /error
          >
          > | Note that when an error is encountered (that causes an error message or beep)
          > | the rest of the mapping is not executed. This is Vi-compatible.

          Sure. The only problem is that, in case I pointed out, the error throwing is
          not consistent: '99l' run on the previous-to-last char of the line does NOT
          throw the error while even simple 'l' run on the last char of the DOES.

          Milan

          --~--~---------~--~----~------------~-------~--~----~
          You received this message from the "vim_dev" maillist.
          For more information, visit http://www.vim.org/maillist.php
          -~----------~----~----~----~------~----~------~--~---
        • Tom Sorensen
          ... Because they re not the same. If you do 9999999l would you expect vi(m) to end up on the last character of a line (barring TRUELY absurd line lengths) or
          Message 4 of 13 , Sep 10, 2009
          • 0 Attachment
            On Thu, Sep 10, 2009 at 10:20 AM, Milan Vancura <milan@...> wrote:
            > Sure. The only problem is that, in case I pointed out, the error throwing is
            > not consistent: '99l' run on the previous-to-last char of the line does NOT
            > throw the error while even simple 'l' run on the last char of the DOES.

            Because they're not the same. If you do 9999999l would you expect
            vi(m) to end up on the last character of a line (barring TRUELY absurd
            line lengths) or to beep at you if the line was too short and leave
            the cursor where it is?

            The fact of the matter is that this "difference" in behavior is vi-compliant.

            Tom

            --~--~---------~--~----~------------~-------~--~----~
            You received this message from the "vim_dev" maillist.
            For more information, visit http://www.vim.org/maillist.php
            -~----------~----~----~----~------~----~------~--~---
          • Andy Wokula
            ... consistency depends on the point of view ... I think the rule is simple: If a motion command cannot move the cursor, you will get a beep (otherwise not).
            Message 5 of 13 , Sep 10, 2009
            • 0 Attachment
              Milan Vancura schrieb:
              >> Lech Lorens schrieb:
              >>> BTW unlike documentation e.g. for :global or :tabdo, documentation for
              >>> @ does not mention the expected behaviour if an error is encountered.
              >>> IMHO this means that errors should be ignored.
              >> Macros and mappings are quite similar in this regard
              >> :h macro
              >> /error
              >>
              >> | Note that when an error is encountered (that causes an error message or beep)
              >> | the rest of the mapping is not executed. This is Vi-compatible.
              >
              > Sure. The only problem is that, in case I pointed out, the error throwing is
              > not consistent: '99l' run on the previous-to-last char of the line does NOT
              > throw the error while even simple 'l' run on the last char of the DOES.
              >
              > Milan

              consistency depends on the point of view ...

              I think the rule is simple:
              If a motion command cannot move the cursor, you will get a beep (otherwise not).

              In the example, 99l moves the cursor -> no beep.

              --
              Andy

              --~--~---------~--~----~------------~-------~--~----~
              You received this message from the "vim_dev" maillist.
              For more information, visit http://www.vim.org/maillist.php
              -~----------~----~----~----~------~----~------~--~---
            • Bram Moolenaar
              ... Not a bug: 2l behaves different than ll when the second l doesn t work. 2l just stops, ll is an error and the operation is aborted. When at the
              Message 6 of 13 , Sep 10, 2009
              • 0 Attachment
                Milan Vancura wrote:

                > while playing with macros we found this bug. Consider a two-line file:
                >
                > AA
                > 2lp
                >
                > Yank the second line, put cursor at first 'A' on the first line and do @"
                > Everything is OK: the content of second line is appended after the end of the
                > first line - as the number of 'l' (2) is more than you can do on such a short
                > line as 'AA' is.
                >
                > Then do one of the following (with the same file as we started with):
                >
                > 1. replace '2' with 'l' (same meaning: '2l' = 'll') and repeat the same
                > procedure as above
                >
                > or
                >
                > 2. put the cursor at last (second) 'A' instead of the first one in the
                > procedure above.
                >
                > The result is same in both cases: nothing is appended, the macro stopped at 'l'
                > command.
                >
                > This happens ONLY if you have a cursor on the last char of the line. Otherwise
                > everything works perfectly, even if the number before 'l' is much higher than
                > the length of the line you apply the macro.
                >
                > Tested in vim 7.1, patches 1-314 and vim 7.2 patches 1-22.
                >
                > May you look at this, please?

                Not a bug: "2l" behaves different than "ll" when the second "l" doesn't
                work. "2l" just stops, "ll" is an error and the operation is aborted.
                When at the end of the line "2l" also produces an error, since it can't
                move at all.

                --
                hundred-and-one symptoms of being an internet addict:
                214. Your MCI "Circle of Friends" are all Hayes-compatible.

                /// 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.
                For more information, visit http://www.vim.org/maillist.php
                -~----------~----~----~----~------~----~------~--~---
              • Bram Moolenaar
                ... The main reason is Vi compatibility. The reasoning is that if the cursor doesn t move at all for a movement command then it s an error. If it can move
                Message 7 of 13 , Sep 11, 2009
                • 0 Attachment
                  Milan Vancura wrote:

                  > > Not a bug: "2l" behaves different than "ll" when the second "l" doesn't
                  > > work. "2l" just stops, "ll" is an error and the operation is aborted.
                  > > When at the end of the line "2l" also produces an error, since it can't
                  > > move at all.
                  >
                  > Hello Bram.
                  >
                  > I'm sorry to seem nit-picking but what you did is you perfectly
                  > described what happens (in better words than I did, or at least
                  > shorter) but you did not write any single word about why such
                  > behaviour is not a bug. Neither 99l on previous-to-last char nor '99l'
                  > on the last char can't be done (completely). I really don't see the
                  > logic in background of this.
                  >
                  > Yes, I found one point myself: I see the same behaviour in linewise
                  > mode: d99j works on any other line than the last one. But why such
                  > non-intuitive behaviour is there? Other then bug-to-bug compatibility
                  > with vi? (if that is the only reason we may think about an option and
                  > about including that option setting as a part of 'compatible' option).
                  > I tried to think about reasons (for macro programming or general
                  > usage) but found really nothing.
                  >
                  > Thank you for the explanation,

                  The main reason is Vi compatibility.

                  The reasoning is that if the cursor doesn't move at all for a movement
                  command then it's an error. If it can move less than intended then this
                  is not handled like an error. It's common to do 999l to go as far right
                  as possible.

                  Note that there are a few exceptions, again for Vi compatibility.

                  --
                  hundred-and-one symptoms of being an internet addict:
                  219. Your spouse has his or her lawyer deliver the divorce papers...
                  via e-mail.

                  /// 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.
                  For more information, visit http://www.vim.org/maillist.php
                  -~----------~----~----~----~------~----~------~--~---
                • Milan Vancura
                  Hi Bram, thank you for the answer. ... So what about an option changing this behaviour (causing all movements throwing an error if they can t be done) and add
                  Message 8 of 13 , Sep 14, 2009
                  • 0 Attachment
                    Hi Bram,

                    thank you for the answer.

                    > The main reason is Vi compatibility.

                    So what about an option changing this behaviour (causing all movements throwing
                    an error if they can't be done) and add that option to be a part of what
                    'compatible' sets?

                    > The reasoning is that if the cursor doesn't move at all for a movement
                    > command then it's an error. If it can move less than intended then this
                    > is not handled like an error. It's common to do 999l to go as far right
                    > as possible.

                    As I mentioned above: I think the right behaviour is that '999l' ends with an
                    error if there are less than 999 chars to the right and users should use '$'
                    for reaching the end of line.

                    > Note that there are a few exceptions, again for Vi compatibility.

                    Sure, I understand. I will not fight if you say strict 'no' to my idea.

                    Milan
                    --
                    Milan Vancura, Prague, Czech Republic, Europe

                    --~--~---------~--~----~------------~-------~--~----~
                    You received this message from the "vim_dev" maillist.
                    For more information, visit http://www.vim.org/maillist.php
                    -~----------~----~----~----~------~----~------~--~---
                  • Bram Moolenaar
                    ... In my opinion there are too many options already. I don t like confusing the user with yet another way to change behavior in mysterious ways. -- After a
                    Message 9 of 13 , Sep 15, 2009
                    • 0 Attachment
                      Milan Vancura wrote:

                      > thank you for the answer.
                      >
                      > > The main reason is Vi compatibility.
                      >
                      > So what about an option changing this behaviour (causing all movements throwing
                      > an error if they can't be done) and add that option to be a part of what
                      > 'compatible' sets?
                      >
                      > > The reasoning is that if the cursor doesn't move at all for a movement
                      > > command then it's an error. If it can move less than intended then this
                      > > is not handled like an error. It's common to do 999l to go as far right
                      > > as possible.
                      >
                      > As I mentioned above: I think the right behaviour is that '999l' ends with an
                      > error if there are less than 999 chars to the right and users should use '$'
                      > for reaching the end of line.
                      >
                      > > Note that there are a few exceptions, again for Vi compatibility.
                      >
                      > Sure, I understand. I will not fight if you say strict 'no' to my idea.

                      In my opinion there are too many options already. I don't like
                      confusing the user with yet another way to change behavior in mysterious
                      ways.

                      --
                      "After a few years of marriage a man can look right at a woman
                      without seeing her and a woman can see right through a man
                      without looking at him."
                      - Helen Rowland

                      /// 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.
                      For more information, visit http://www.vim.org/maillist.php
                      -~----------~----~----~----~------~----~------~--~---
                    • Milan Vancura
                      ... BTW, we already have an option for a linewise version of this problem. Respectively a flag in the option: :h cpo-- So what we only need is a characterwise
                      Message 10 of 13 , Sep 16, 2009
                      • 0 Attachment
                        >
                        >
                        > Milan Vancura wrote:
                        >
                        > > thank you for the answer.
                        > >
                        > > > The main reason is Vi compatibility.
                        > >
                        > > So what about an option changing this behaviour (causing all movements throwing
                        > > an error if they can't be done) and add that option to be a part of what
                        > > 'compatible' sets?
                        > >
                        > > > The reasoning is that if the cursor doesn't move at all for a movement
                        > > > command then it's an error. If it can move less than intended then this
                        > > > is not handled like an error. It's common to do 999l to go as far right
                        > > > as possible.
                        > >
                        > > As I mentioned above: I think the right behaviour is that '999l' ends with an
                        > > error if there are less than 999 chars to the right and users should use '$'
                        > > for reaching the end of line.
                        > >
                        > > > Note that there are a few exceptions, again for Vi compatibility.
                        > >
                        > > Sure, I understand. I will not fight if you say strict 'no' to my idea.
                        >
                        > In my opinion there are too many options already. I don't like
                        > confusing the user with yet another way to change behavior in mysterious
                        > ways.

                        BTW, we already have an option for a linewise version of this problem.
                        Respectively a flag in the option: :h cpo--
                        So what we only need is a characterwise version of this flag and to turn both
                        of them on by default in vim (or after :set nocompatible).

                        I found nothing mysterious about using '$' to reach the end of line instead of
                        <magical_constant>l :-)

                        Milan

                        --~--~---------~--~----~------------~-------~--~----~
                        You received this message from the "vim_dev" maillist.
                        For more information, visit http://www.vim.org/maillist.php
                        -~----------~----~----~----~------~----~------~--~---
                      Your message has been successfully submitted and would be delivered to recipients shortly.