Re: Feature Request: Auto-jumping to source file (.el) upon elisp error

[Nordlöw]

On Dec 10, 10:59 am, Stefan Kamphausen <ska...@gmx.net> wrote:
> Hi,
>
> "Nordlöw" <per.nord...@gmail.com> writes:
> > My highest priority Emacs feature request:
>
> > When I encounter an error in elisp code I always wonder: Is there a
> > way for Emacs to automatically split my elisp-error window in two and
> > replace one of the windows with the relating source file and jump to
> > position in that buffer where the error occurrred, like we are used to
> > with practically all other languages/IDEs?
>
> to me it seems that just the right thing happens.
>
> For example, when I start a un-customized emacs:
>
> shell> emacs -q
>
> put the following into my scratch buffer:
> ----------------------------------------------------------------------
> (defun produce-an-error ()
>   (interactive)
>   (goto-char))
>
> (setq debug-on-error t)
>
> (produce-an-error)
> ----------------------------------------------------------------------
>
> and do a M-x eval-current-buffer I get a second window showing a
> backtrace:
> ----------------------------------------------------------------------
> Debugger entered--Lisp error: (wrong-number-of-arguments goto-char 0)
>   (goto-char)
>   produce-an-error()
>   eval-current-buffer()
>   call-interactively(eval-current-buffer)
>   execute-extended-command(nil)
>   call-interactively(execute-extended-command)
> ----------------------------------------------------------------------
>
> The cute thing is that all known elisp functions (as opposed to
> C-builtins) will be clickable to jump to the function definition.
> Since I may be interested in various levels of the whole backtrace
> this is way better than having the program decide which one will be my
> point of interest.
>
> Just my 2ct.
>
> Regards,
> Stefan
> --
> Stefan Kamphausen ---http://www.skamphausen.de
> a blessed +42 regexp of confusion (weapon in hand)
> You hit. The format string crumbles and turns to dust.

But the top-most function, in your case produce-an-error(), is neither
clickable nor mentioned about its file/buffer-origin in the Debugger
output. This is sad because this is what the user/developer wants to
see first in order to most easily understand the top-most (call-stack)
context of the problem.

/Nordlöw