Re: Network security manager

[Lars Magne Ingebrigtsen]

Eli Zaretskii <address@hidden> writes:

> But you were suggesting that as a general principle, not as solution
> to that particular problem alone?  Your question about "a scenario"
> also sounded as something rather general.  And that is how I
> understood it and replied.

I'm not sure, but I suspect that `inhibit-quit' is not a complete
solution to the general problem of determining when we're allowed to
prompt people from asynchronous code.  I think Ted outlined a mechanism
that would work well, but would need extension to other
non-process-based forms of asynchronous code, like timers.

(Executive summary: The asynchronous code should be allowed to prompt
users in buffers "where it belongs", so if the user has moved on to a
different buffer, then it should not prompt.)

> As for Lars's situation, there is a much simpler solution to that,
> which I already pointed out earlier in this thread.  It is also much
> cleaner, IMO.

The solution you outlined ("just bind a variable") would not work for
the specific HTTPS problem that started the discussion, since url.el
works very asynchronously -- the actual code is run outside of the
dynamic extent of the binding.

But like I said about a hundred messages earlier in this thread, and
which is understandable if you and Stefan didn't catch, I've solved this
specific problem by introducing new functionality to url.el (see the
`url-request-noninteractive' parts in the nsm branch).

So you can stop discussing this specific problem.  :-)  The general
problem remains, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no