Re: [PATCH] Keep network security info buffers after use

[Karl Fogel <kfogel@red-bean.com>]

Jens Schmidt wrote:
>How about the following variation of Karl's patch, which 
>hopefully
>meets his request for simplicity and hopefully also these 
>requests of
>yours (as long as you do not count the additional multiple choice
>option as something that must be revertable by option):

FWIW, my request is not for simplicity but for discoverability.

If we have a new, separate command for getting access to cert info 
that has already passed by on the screen (during the 
`read-multiple-choice' prompt), I don't think most users are ever 
going to know that that command exists -- unless we somehow tell 
them about it *at the time when they need to know it*.

Getting prompted by `nsm-query-user' is already quite rare and is 
usually a surprise when it happens (because it's an unexpected 
interruption in what is normally a familiar UI interaction), so 
it's not a situation conducive to pre-emptive investment in an 
exploratory acquisition of knowledge.  Whatever guidance the user 
is going to get about how to handle the surprise is best provided 
in real time during the surprise itself.

Now, maybe a solution like this would work:

* During `nsm-query-user', preserve the cert info.

* After `nsm-query-user' is done, display a message saying
  something like "Use `M-x nsm-display-certificates' to view
  certificate information.".

That message would be logged in the "*Messages*" buffer, of 
course, and these days experienced users know to look there.

I don't know if the new message would be left in the minibuffer 
for long after `nsm-query-user' is done, because I don't know what 
other things typically happen immediately afterwards that might 
replace that message with their own messages in the minibuffer. 
But at least the new message would be in "*Messages*".

Thoughts?

Eli Zaretskii wrote:
> If read-multiple-choice expects a single key, then we cannot
> allow "C-x o", because those are two keys, not one.

Well, note that it already allows one to enter a recursive edit, 
which can be thought of as an arbitrary number of keys (since the 
r-m-c prompt doesn't end until after the recursive edit ends).

I think maybe I haven't really understood your objection.  I can't 
tell which of these objections you're making:

a) An implementation objection (we have no technical way to treat 
   `C-x o' specially -- it can't be done), or

b) A UX objection (the user expects the next keystroke to take 
   some final action, therefore we shouldn't confuse the user by
   doing something that breaks that pattern), or

c) A security objection (the question that `nsm-query-user' is 
   asking via r-m-c is a sensitive question, and we would open up
   new security vulnerabilities by treating `C-x o' specially).

You might be making more than one of these?

> read-multiple-choice _does_ have a way of accepting responses 
> longer
> than one key -- that's what the LONG-FORM argument is for -- but 
> that
> comes with a price, and in the case in point we don't want to 
> pay that
> price.  In other cases, if a non-modal dialog is desired, the 
> caller
> should use LONG-FORM.

I have never argued for using the LONG-FORM style in this case, 
and never argued for paying that price.

> > Take it on faith, for now, that we could make this happen. 
> > Let's 
> > just discuss whether we *want* it, assuming we can have it. 
> > If we 
> > decide we want it, I'll try to implement it, and I'll ask for 
> > help 
> > if I don't see the way.  If in the end we can't do it, fine, 
> > then 
> > we would be in exactly the situation we're now anyway.
> 
> You have already heard from me what we want (and I repeat that 
> above).

We have heard from you what *you* want.  As per above, I -- 
perhaps among others -- haven't really understood the reasons why 
you want the thing you want, and why you don't want the other 
thing I proposed.  My question above is meant to elicit that 
understanding.

Best regards,
-Karl