73410Re: [RFC] Script line numbers in error messages
- Sep 26, 2013
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.
> 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.
- << Previous post in topic Next post in topic >>