[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that
From: |
Eli Zaretskii |
Subject: |
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file |
Date: |
Sat, 20 Feb 2021 11:09:35 +0200 |
> From: Matt Armstrong <matt@rfc20.org>
> Cc: 46397@debbugs.gnu.org, eggert@cs.ucla.edu, craven@gmx.net
> Date: Fri, 19 Feb 2021 13:46:27 -0800
>
> >> I'm coming to the opinion that issuing a prompt from `unlock-buffer'
> >> itself is a bad idea, but I think prompting from `kill-buffer' is
> >> okay.
> >
> > What do you propose to do for all the other users of unlock-buffer?
>
> They continue to signal errors.
>
> I would be happy to send a list of reasons why I think this is a safer
> thing to do than prompting. (reasons that I admit I could be misguided)
I think we should audit all the callers of unlock_buffer and
unlock_file, and see if signaling an error there is really the best
alternative. I still think that prompting the user for what to do,
with one of the possible responses being "ignore", could be a better
solution, at least in some of these cases, because signaling an error
means the results of some operation are lost. For example, consider
replace-buffer-contents, which is a command -- we could signal the
error there after everything, all the heavy processing, has been done
already. Is that reasonable? Or are you relying on the ability of
unlock_file to silently ignore the errors where the user should choose
"ignore"? Because I'd like to explicitly NOT rely on that.
So yes, a list of callers and the reasons not to prompt the user there
would be a good starting point, TIA.
> >> (a) Modify `kill-buffer' to call `unlock-buffer' sooner, closer to the
> >> point where it is already running hooks prompting the user.
> >
> > Why do we need to move the call? Can we leave it in its current
> > place, and thus minimize potential unintended problems this could
> > cause?
>
> In part because `kill-buffer' currently calls `unlock-buffer' after this
> comment:
>
> /* We have no more questions to ask. Verify that it is valid
> to kill the buffer. This must be done after the questions
> since anything can happen within do_yes_or_no_p. */
OK, but then the call to unlock_buffer should have all the conditions
tested later, under which we will NOT kill the buffer. Because
otherwise we could pop the question for a buffer that we are not going
to kill.
> (This class of problem is also one of the reasons for my answer above.)
When the alternative is worse than what could possibly happen inside
do_yes_or_no_p, we may decide to ask the question anyway.
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, (continued)
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/14
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/15
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/15
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Paul Eggert, 2021/02/15
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/16
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Lars Ingebrigtsen, 2021/02/16
- bug#46397: [PATCH] Re: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/22
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file,
Eli Zaretskii <=
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/20
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Mike Kupfer, 2021/02/21
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/21
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/24
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Eli Zaretskii, 2021/02/24
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Paul Eggert, 2021/02/19
- bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/19
bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file, Matt Armstrong, 2021/02/09