From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Wed, 19 Nov 2014 08:51:02 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <871toze1tl.fsf@lifelogs.com> References: <87a93oilxl.fsf@lifelogs.com> <87oas4h555.fsf@lifelogs.com> <87a93oh180.fsf@lifelogs.com> <83h9xw9zg3.fsf@gnu.org> <83d28k9yb9.fsf@gnu.org> <83ppcj9740.fsf@gnu.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1416405072 30628 80.91.229.3 (19 Nov 2014 13:51:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Nov 2014 13:51:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 19 14:51:05 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xr5ex-0003Uu-EE for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 14:51:03 +0100 Original-Received: from localhost ([::1]:58264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5ex-0000M7-4Y for ged-emacs-devel@m.gmane.org; Wed, 19 Nov 2014 08:51:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46905) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5en-0000Er-Ia for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:50:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xr5eh-00019B-F3 for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:50:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:42597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xr5eg-000195-Qr for emacs-devel@gnu.org; Wed, 19 Nov 2014 08:50:47 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xr5eb-0003MI-AZ for emacs-devel@gnu.org; Wed, 19 Nov 2014 14:50:41 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 14:50:41 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 19 Nov 2014 14:50:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 20 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:xnnmGyVKPtWqo+8rsrClk4Hbjds= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:177746 Archived-At: On Wed, 19 Nov 2014 08:40:54 -0500 Stefan Monnier wrote: >>> > I also did some further testing with my patch, and apparently timers do >>> > not set the running_asynch_code variable? They probably should set >>> > that separate variable, too. I think. >>> BTW, another existing variable that you could use is `inhibit-quit'. >> That's dangerous, IMO. Again, it uses a variable not designed for >> this functionality, IOW this could break without notice. SM> It's definitely not dangerous. IIUC he needs this info to decide SM> whether his code can prompt the user or not. Maybe it won't do the SM> right thing in 100% of the cases, but it's clear that if inhibit-quit is SM> non-nil, we're in a context where we shouldn't prompt the user. Would it work to use the logic of "the buffer that initiated the connection is in the foreground"? In that case, we could store the buffer name as an optional record in the process info structure-- `open-network-stream' could figure it out mostly automatically? Ted