When I first read this what you suggest is a valid and a nice suggestion but I tried to figure out why I haven’t needed it.
After sleeping on it I realized that there are 3 main reasons I have not had a need for this.
I have learned to use modules to keep the logical concept of the code separated. This also implies that clauses (predicates with the same functor and arity) are together and in the same module. So if I see a clause/predicate in the debugger, this helps to identify the module which identifies the source code file. Along the same lines when I compile a program I eliminate all warnings of the form
Clauses of <functor/arity> are not together in the source-file
I make extensive use of low level unit test. This significantly cuts down on the times I need to use the debugger to find bugs deeply nested in the code. This does not mean that when I first write a test for new predicate it does not have bugs and I do not have to use the debugger, but when I do have to use the debugger with a new test, the bug is typically in the few lines of the predicate being tested.
When I have lots of predicates for a clause, I add comments to identify the specific predicate and give them a unique name and number. The comments show up in gtrace and make it easy to identify the line. e.g.
% Addition evaluation rule 03
% X + -(Y) -> negated number
Granted this is still a manual search at times for the specific predicate, but the search can be done with the source code editor search which is very fast.
When developing code I sometimes have source code files that has both code and test cases combined with line counts in the thousands.