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

[RFC] Script line numbers in error messages

Expand Messages
  • Nikolay Pavlov
    There one inconvenient thing in error messages: they come with line numbers relative to the function start. This means to see the line that caused the error
    Message 1 of 5 , Sep 26 2:27 AM

      There one inconvenient thing in error messages: they come with line numbers relative to the function start. This means to see the line that caused the error you either need to use :fu or find function name in a file (and file is only seen with :verb fu), be sure you open all folds contained in a function and use 12j for line 12.

      I suggest to add the following information to the error message: file where function was defined and line number in this file. Proposed format:

          Error detected while processing function Error
          defined in /tmp/error.vim, line 3: script line 4:
          line    1:
          E492: Not an editor command: error

      . This additional line will not be present if function was not defined in a script and "script line 4:" part will not be present if function was defined inside :execute.

      :verbose fun should also provide this information

             function Error()
          Last set at line 3 from /tmp/error.vim
          1      error
             endfunction

      This way to find where error occurred you only need to switch to the file explicitly listed in the error message and do 4gg.

      This and absence of normal names for anonymous functions inconvenience bugged me for a long time, but while names were already altered in extended-funcref branch this issue can be discussed here and merged into default much earlier.

      --
      --
      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
       
      ---
      You received this message because you are subscribed to the Google Groups "vim_dev" group.
      To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • LCD 47
      ... [...] Since you ask: I completely agree with your statement of the problem. I have somewhat mixed feelings about your suggested solution though. The way
      Message 2 of 5 , Sep 26 1:29 PM
        On 26 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
        > There one inconvenient thing in error messages: they come with line
        > numbers relative to the function start. This means to see the line
        > that caused the error you either need to use :fu or find function name
        > in a file (and file is only seen with :verb fu), be sure you open all
        > folds contained in a function and use 12j for line 12.
        >
        > I suggest to add the following information to the error message: file
        > where function was defined and line number in this file. Proposed
        > format:
        >
        > Error detected while processing function Error
        > defined in /tmp/error.vim, line 3: script line 4:
        > line 1:
        > E492: Not an editor command: error
        >
        > . This additional line will not be present if function was not defined
        > in a script and "script line 4:" part will not be present if function
        > was defined inside :execute.
        [...]

        Since you ask: I completely agree with your statement of the
        problem. I have somewhat mixed feelings about your suggested solution
        though. The way I see it, something like this might be a better choice:

        Error detected in "/tmp/error.vim", line 4, in function s:Error():
        E492: Not an editor command: error

        (please note the human-readable name for a local function). This could
        be achieved if all functions would keep track of where they came from,
        and local functions would keep track of their names. The name of the
        script might be replaced by "stdin", or "exec", or some other best
        effort attempt to make sense if the function doesn't come from a script.

        As far as I can tell, this is all information that is actually
        useful for debugging, and I'd say it would largely cover all common
        situations. This approach would fail if the script a function came from
        got deleted, or has changed since Vim read it, or aything similar, but I
        don't think anybody would realistically care about that case.

        In particular, I can't think of any reason to keep around the
        line numbers relative to the start of the function, at least not for
        functions that came from scripts.

        /lcd

        --
        --
        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

        ---
        You received this message because you are subscribed to the Google Groups "vim_dev" group.
        To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
        For more options, visit https://groups.google.com/groups/opt_out.
      • Nikolay Pavlov
        ... Relative numbers must be kept for functions defined with :execute (because such functions will share the same number for all their lines). They are also
        Message 3 of 5 , Sep 26 7:32 PM


          On Sep 27, 2013 12:29 AM, "LCD 47" <lcd047@...> wrote:
          >
          > On 26 September 2013, Nikolay Pavlov <zyx.vim@...> wrote:
          > > There one inconvenient thing in error messages: they come with line
          > > numbers relative to the function start. This means to see the line
          > > that caused the error you either need to use :fu or find function name
          > > in a file (and file is only seen with :verb fu), be sure you open all
          > > folds contained in a function and use 12j for line 12.
          > >
          > > I suggest to add the following information to the error message: file
          > > where function was defined and line number in this file. Proposed
          > > format:
          > >
          > >     Error detected while processing function Error
          > >     defined in /tmp/error.vim, line 3: script line 4:
          > >     line    1:
          > >     E492: Not an editor command: error
          > >
          > > . This additional line will not be present if function was not defined
          > > in a script and "script line 4:" part will not be present if function
          > > was defined inside :execute.
          > [...]
          >
          >     Since you ask: I completely agree with your statement of the
          > problem.  I have somewhat mixed feelings about your suggested solution
          > though.  The way I see it, something like this might be a better choice:
          >
          >         Error detected in "/tmp/error.vim", line 4, in function s:Error():
          >         E492: Not an editor command: error
          >
          > (please note the human-readable name for a local function).  This could
          > be achieved if all functions would keep track of where they came from,
          > and local functions would keep track of their names.  The name of the
          > script might be replaced by "stdin", or "exec", or some other best
          > effort attempt to make sense if the function doesn't come from a script.
          >
          >     As far as I can tell, this is all information that is actually
          > useful for debugging, and I'd say it would largely cover all common
          > situations.  This approach would fail if the script a function came from
          > got deleted, or has changed since Vim read it, or aything similar, but I
          > don't think anybody would realistically care about that case.
          >
          >     In particular, I can't think of any reason to keep around the
          > line numbers relative to the start of the function, at least not for
          > functions that came from scripts.

          Relative numbers must be kept for functions defined with :execute (because such functions will share the same number for all their lines). They are also useful for :break* since this will not be patched to use absolute numbers: it is easy to imagine the situation where you set breakpoint immediately after seeing a error message at the line where error is shown.

          Until extended-funcref names for the functions are to be kept such that you can immediately use :fu to see them (after extended-funcref you cannot see function definition for anonymous functions unless you can access appropriate funcrefs). I guess though that for anonymous functions format of the function name can be changed to something like "(42)s:original.name" (AFAIR this is very easy) and :fu may be changed to recognize such format.

          Also note that your suggested format moves too much information into one line: normally function name is a sequence of .. separated names which may be very lengthy. It is better to avoid wrapping.

          >     /lcd
          >
          > --
          > --
          > 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
          >
          > ---
          > You received this message because you are subscribed to the Google Groups "vim_dev" group.
          > To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          > For more options, visit https://groups.google.com/groups/opt_out.

          --
          --
          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
           
          ---
          You received this message because you are subscribed to the Google Groups "vim_dev" group.
          To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
          For more options, visit https://groups.google.com/groups/opt_out.
        • Axel Bender
          I d also like this same feature when it comes to debugging: e.g. function Rename.. 1_DoArea..S_Rename.. 1_AnalyzeLine line 17: ... is less easy to read
          Message 4 of 5 , Sep 27 1:21 AM
            I'd also like this same feature when it comes to debugging:

            e.g.

            function Rename..<SNR>1_DoArea..S_Rename..<SNR>1_AnalyzeLine
            line 17: ...

            is less easy to read than (e.g.)

            function Rename..<SNR>1_DoArea..S_Rename..<SNR>1_AnalyzeLine
            line 173 (AnalyzeLine 17): ...

            --
            --
            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

            ---
            You received this message because you are subscribed to the Google Groups "vim_dev" group.
            To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
            For more options, visit https://groups.google.com/groups/opt_out.
          • ZyX
            ... This variant is missing script name. -- -- You received this message from the vim_dev maillist. Do not top-post! Type your reply below the text you are
            Message 5 of 5 , Sep 27 7:10 AM
              On Friday, September 27, 2013 12:21:49 PM UTC+4, Axel Bender wrote:
              > I'd also like this same feature when it comes to debugging:
              >
              > e.g.
              >
              > function Rename..<SNR>1_DoArea..S_Rename..<SNR>1_AnalyzeLine
              > line 17: ...
              >
              > is less easy to read than (e.g.)
              >
              > function Rename..<SNR>1_DoArea..S_Rename..<SNR>1_AnalyzeLine
              > line 173 (AnalyzeLine 17): ...

              This variant is missing script name.

              --
              --
              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

              ---
              You received this message because you are subscribed to the Google Groups "vim_dev" group.
              To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscribe@....
              For more options, visit https://groups.google.com/groups/opt_out.
            Your message has been successfully submitted and would be delivered to recipients shortly.