Bug #148
C-c C-p in emacs goes to wrong line
Description
In emacs when an error occurs running code sent via C-c C-f (effectively "source") the user can use C-c C-p to go to the line in the source where the error occurred.
Unfortunately C-c C-p does the wrong thing if the error occurs in a fn from a package which was called by the user's code. This is quite confusing!
To see this, save the following in bug.cocoa5 then execute it using C-c C-f
Use QQ[x]; Coefficients(x,x); --> provokes an error -- blah -- blah
In a simple case like this it is not so hard to find where the error really lies; in more complicated situations it is rather harder! In my mind the current behaviour is surely wrong, but I am not so sure what i would regard as good/correct behaviour. I see 3 probable options
- C-c C-p simply says it cannot work in this case [major wimp out!]
- C-c C-p opens the relevant package, and goes to the correct line in the package
- C-c C-p goes to the line of the user's source file which caused the problem
Option (3) is probably the most useful, but probably also the hardest to implement (especially since some "CALLED BY" messages may be elided, I believe).
Option (1) could be used as a stop-gap (simply to avoid the current confusing behaviour).
Opinions?
History
#1
Updated by Anna Maria Bigatti almost 12 years ago
Updated by - Category set to EmacsUI
#2
Updated by John Abbott almost 12 years ago
Updated by NOTE the fn is called pop-to-buffer-cocoa5-source-find-error.
And also pop-to-buffer-cocoa5-source-find-X
Roughly speaking the command searches backwards for ERROR then from there searches forwards for WHERE.... It also looks for the last Source command, and uses that for recognising which file to look in.
We could consider:
search backward for Source command to get the file name;
go to end, search backward for ERROR, and from there search forward for the file name (basename), go to start of line (which may be either the WHERE line, a CONTEXT line, or a called by line).
Definitely more complicated than the current impl, though.
#3
Updated by Anna Maria Bigatti about 10 years ago
- Target version set to CoCoA-5.1.0 Easter14
#4
Updated by John Abbott about 10 years ago
- Target version changed from CoCoA-5.1.0 Easter14 to CoCoA-5.?.?
#5
Updated by John Abbott almost 9 years ago
I recently tried using C-c C-p and found it unhelpful; so I "stupidly" tried it a second time, and found that it was not clear what was happening. To be fair it did take me to the correct line/col in the source file, but I think the original error message ws no longer visible -- I had lots of syntax errors because of a stray single quote at the end of a line.
#6
Updated by Anna Maria Bigatti almost 9 years ago
John Abbott wrote:
I recently tried using
C-c C-pand found it unhelpful; so I "stupidly" tried it a second time, and found that it was not clear what was happening. To be fair it did take me to the correct line/col in the source file, but I think the original error message ws no longer visible -- I had lots of syntax errors because of a stray single quote at the end of a line.
I'm not quite sure I understand what you did. Anyway the first error message should also be reported in the bottom line of emacs. (I use C-c C-p a lot and find it very useful)
REPLY (JAA) I think what confused me was that in the CoCoA-5 output window the cursor was at the end of the output, and that the full error message corresponding to my problem was not visible there (I did not think to look at the minibuffer). Would it make sense to place the cursor of the CoCoA-5 output buffer at the line where the error message is?
#7
Updated by Anna Maria Bigatti almost 9 years ago
REPLY (JAA) I think what confused me was that in the CoCoA-5 output window the cursor was at the end of the output, and that the full error message corresponding to my problem was not visible there (I did not think to look at the minibuffer). Would it make sense to place the cursor of the CoCoA-5 output buffer at the line where the error message is?
OK... I need to try it (I think it is easy to implement) and see how it feels.
#8
Updated by John Abbott over 1 year ago
Anna, might you like to take a look at this?
It's not really urgent, but maybe you feel inspired?
#9
Updated by Anna Maria Bigatti over 1 year ago
- % Done changed from 0 to 20
John Abbott wrote:
Anna, might you like to take a look at this?
It's not really urgent, but maybe you feel inspired?
I had a look. A long look.
I think that I'd like option
<quote>
3. C-c C-p goes to the line of the user's source file which caused the problem
</quote>
that, in this case, would be to intecept the line "called at line .."
with
(re-search-forward "called at line\\(s?\\) \\([0-9]+\\) of " nil t)
and place the cursor there.
Problems: not always we have "called at line ..", for example if in the file we have "coefficients(x,x);" instead of "Coefficients(x,x);"
We should check if there is
"called at top-level" and do nothing
or "called at line .." and go there,
otherwise look for "WHERE: .." and go there.
At this moment, this exceeds my emacs-list programming capability ;-) even though it should be possible (and very nice to have!!) to work it out.
#10
Updated by John Abbott over 1 year ago
- Status changed from New to In Progress
To help develop better code we need some test cases. I'll type in some candidates here.
TEST CASE 1
use QQ[x]; Coefficients(x,x); -- blah blah
TEST CASE 2 same as test case 1 but small "c"
use QQ[x]; coefficients(x,x); -- blah blah
TEST CASE 3 (two files)
First file -- read this in to define new fn
define fn(f,x) return coefficients(f,x); // what if "C" is big? enddefine;
Second file: now execute this
use QQ[x]; fn(x,x); -- blah blah
QN what happens if the defn of fn is in the same file? Perhaps this is another test case!