From: Bill Wohler <wohler@newt.com>
To: Matt Armstrong <matt@rfc20.org>
Cc: eggert@cs.ucla.edu, 46397@debbugs.gnu.org, craven@gmx.net,
Mike Kupfer <mkupfer@alum.berkeley.edu>
Subject: bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file
Date: Sun, 14 Mar 2021 11:03:33 -0700 [thread overview]
Message-ID: <2702033.1615745013@olgas.newt.com> (raw)
In-Reply-To: <m21rd8zxm9.fsf@matts-mbp-2016.lan>
Matt Armstrong <matt@rfc20.org> wrote:
> Mike Kupfer <mkupfer@alum.berkeley.edu> writes:
>
> > (Adding Bill Wohler, who has a better grasp than I about why MH-E does
> > some things.)
> >
> > Matt Armstrong wrote:
> >
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >>
> >> > 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.
> > [...]
> >> * lisp/mh-e/mh-show.el (mh-clean-msg-header, mh-unvisit-file):
> >> hard to say, very old code...
> >> * lisp/mh-e/mh-comp.el (mh-read-draft): ditto.
> >
> > I'm not sure I completely understanding the logic behind those calls to
> > unlock-buffer, but I'll take a stab at it.
>
> [...]
>
> Thanks for those analysis Mike. They make sense to me.
This code was likely originally written in the 80s and well before my
time in any case, and it isn't code that I've worked with. I concur with
Mike's analysis as well, and thank him for diving in.
[...]
> > I don't understand the proposal for unlock-buffer (or something under
> > it) to prompt the user. IIUC, the proposal is for a prompt like
> >
> >> /tmp/x/y lock is invalid; assume unlocked? (yes or no)
> >
> > I assume that if the user responds with "yes", unlock-buffer returns
> > and the caller is none the wiser. If the user responds with "no",
> > what happens?
> >
> > mike
>
> I think under the current idea, in the case of `kill-buffer', answering
> "no" from the prompt the buffer un-killed. I think the technical
> mechanism would be to either re-signal the underlying 'file-error or
> signal a new 'unlock-error that contains similar information.
Since I'm reading this out of context, I don't understand it :-). I
think that if an MH-E user, including me, got the prompt that Mike
suggested, she would be pretty confused. If the issue at hand arises, it
would be preferable to speak in the MH-E user's language, such as: Error
recycling draft buffer, discard or keep? [keep].
--
Bill Wohler <wohler@newt.com> aka <Bill.Wohler@nasa.gov>
http://www.newt.com/wohler/, GnuPG ID:610BD9AD
next prev parent reply other threads:[~2021-03-14 18:03 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-09 9:47 bug#46397: 27.1; Cannot delete buffer pointing to a file in a path that includes a file Peter
2021-02-09 23:47 ` Matt Armstrong
2021-02-10 0:23 ` Matt Armstrong
2021-02-10 15:05 ` Eli Zaretskii
2021-02-10 19:23 ` Paul Eggert
2021-02-10 19:45 ` Eli Zaretskii
2021-02-10 22:39 ` Matt Armstrong
2021-02-12 7:43 ` Eli Zaretskii
2021-02-12 9:36 ` Paul Eggert
2021-02-12 11:33 ` Eli Zaretskii
2021-02-12 23:59 ` Matt Armstrong
2021-02-13 8:07 ` Eli Zaretskii
2021-02-11 22:14 ` Matt Armstrong
2021-02-12 2:20 ` Paul Eggert
2021-02-12 7:15 ` Eli Zaretskii
2021-02-13 1:15 ` Matt Armstrong
2021-02-13 1:26 ` Paul Eggert
2021-02-13 8:21 ` Eli Zaretskii
2021-02-13 8:28 ` Eli Zaretskii
2021-02-14 0:49 ` Matt Armstrong
2021-02-14 19:22 ` Eli Zaretskii
2021-02-14 22:16 ` Matt Armstrong
2021-02-15 15:09 ` Eli Zaretskii
2021-02-16 0:49 ` Matt Armstrong
2021-02-16 1:55 ` Paul Eggert
2021-02-16 15:06 ` Eli Zaretskii
2021-02-16 11:53 ` Lars Ingebrigtsen
2021-02-22 19:24 ` bug#46397: [PATCH] " Matt Armstrong
2021-02-19 19:10 ` Matt Armstrong
2021-02-19 19:23 ` Eli Zaretskii
2021-02-19 21:46 ` Matt Armstrong
2021-02-20 9:09 ` Eli Zaretskii
2021-02-21 0:36 ` Matt Armstrong
2021-02-21 23:43 ` Mike Kupfer
2021-02-22 1:42 ` Matt Armstrong
2021-03-14 18:03 ` Bill Wohler [this message]
2021-03-17 23:36 ` Matt Armstrong
2021-02-24 17:37 ` Matt Armstrong
2021-02-24 18:50 ` Eli Zaretskii
2021-03-01 16:59 ` Eli Zaretskii
2021-03-05 22:19 ` Matt Armstrong
2021-03-06 9:36 ` Eli Zaretskii
2021-03-06 23:39 ` Matt Armstrong
2021-03-07 2:50 ` Paul Eggert
2021-03-07 5:57 ` Matt Armstrong
2021-02-19 19:45 ` Paul Eggert
2021-02-19 21:52 ` Matt Armstrong
2021-03-08 2:18 ` Matt Armstrong
2021-03-11 14:34 ` Eli Zaretskii
2021-03-17 23:49 ` Matt Armstrong
2021-03-17 23:51 ` Matt Armstrong
2021-03-20 10:43 ` Eli Zaretskii
2021-03-22 1:43 ` Matt Armstrong
2021-03-27 9:20 ` Eli Zaretskii
2021-02-10 0:26 ` Matt Armstrong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2702033.1615745013@olgas.newt.com \
--to=wohler@newt.com \
--cc=46397@debbugs.gnu.org \
--cc=craven@gmx.net \
--cc=eggert@cs.ucla.edu \
--cc=matt@rfc20.org \
--cc=mkupfer@alum.berkeley.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).