Ken Manheimer <address@hidden> writes:
> The problem is that this provision sometimes registers buffers that
> were present in the editing session before the pdbtracking session, so
> that pdbtracking sometimes causes pdbtracked buffers to be deleted
> when it shouldn't.
> I'm unsure what exact conditions lead to the problem,
I guess this can happen if your python source files are accessible
Yes, that turned out to be the situation in the cases I encountered. There are probably other ways a file can be found via multiple paths, like hardlinks and multiple mounts of a filesystem.
> but I'm pretty sure
> that `python-pdbtrack-set-tracked-buffer()` uses the wrong buffer-finding
> function. Instead of using `get-file-buffer()`, it should be using
> `find-buffer-visiting()`. I believe that this will solve the problem.
I think this should be conditional on (or find-file-existing-other-name
find-file-visit-truename), which is what find-file-noselect checks for.
No, as far as I can tell, that doesn't hold in this situation.
The point of this issue is to not delete a source file that was already present in the editing session before the pdb-tracking debugging process stepped through code in the file. The prior presence of the file should be respected regardless of the settings of find-file-existing-other-name or find-file-visit-truename, so these settings should not be considered for this comparison.