GNU bug report logs -
#36556
26.2; python.el pdbtracking sometimes kills buffers when it shouldn't (plus fix)
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Wed, Jul 17, 2019 at 11:03 AM Noam Postavsky <npostavs <at> gmail.com> wrote:
> Ken Manheimer <ken.manheimer <at> 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
[Message part 2 (text/html, inline)]
This bug report was last modified 5 years and 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.