bug#36556: 26.2; python.el pdbtracking sometimes kills buffers when it shouldn't (plus fix)

[Noam Postavsky]

Ken Manheimer <ken.manheimer@gmail.com> writes:

>> > 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.

My understanding is that python-pdbtrack-set-tracked-buffer has to
decide whether or not to (a) make a new buffer for visiting FILE-NAME
(in which case pdb should kill that buffer when done with it), or (b)
use an existing one (in which case, the buffer should be left open).

If (or find-file-visit-truename find-file-visit-truename) is t, and
FILE-NAME is visitied via an alternate name, then the current
implementation will get nil from get-file-buffer, create a "new" buffer
with find-file-noselect (and register that buffer in
python-pdbtrack-buffers-to-kill).  However, find-file-noselect will
return an existing buffer, so killing this buffer is a bug (i.e., the
function think it's in case (a), but it's actually in case (b)).

If (or find-file-visit-truename find-file-visit-truename) is nil, then
find-file-noselect would really return a new buffer in that situation,
so it would be correct to kill it (i.e., with these settings, we are in
case (a)).

Do I have a mistake in the above?