On Sep 27, 2013 12:29 AM, "LCD 47" <[email protected]> wrote: > > On 26 September 2013, Nikolay Pavlov <[email protected]> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
