On Wed, Jul 17, 2019 at 11:03 AM Noam Postavsky <npostavs@gmail.com> wrote:

Ken Manheimer <ken.manheimer@gmail.com> 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
through symlinks?

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.

Ken