From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Network security manager Date: Tue, 18 Nov 2014 11:24:20 -0800 Message-ID: <546B9CE4.20100@dancol.org> References: <87sihg7r73.fsf@alrua-karlstad.karlstad.toke.dk> <87a93oilxl.fsf@lifelogs.com> <87oas4h555.fsf@lifelogs.com> <87a93oh180.fsf@lifelogs.com> <83h9xw9zg3.fsf@gnu.org> <83d28k9yb9.fsf@gnu.org> <837fys9wt7.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c8wLqh7EM6RWUcWmfBOdVdRtc5Ip73EAR" X-Trace: ger.gmane.org 1416338698 23535 80.91.229.3 (18 Nov 2014 19:24:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 18 Nov 2014 19:24:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 18 20:24:52 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 1XqoOR-0000BD-Pm for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 20:24:51 +0100 Original-Received: from localhost ([::1]:54907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqoOR-0006sd-Dc for ged-emacs-devel@m.gmane.org; Tue, 18 Nov 2014 14:24:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38914) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqoO8-0006sN-Bu for emacs-devel@gnu.org; Tue, 18 Nov 2014 14:24:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XqoO4-0007CQ-E5 for emacs-devel@gnu.org; Tue, 18 Nov 2014 14:24:32 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XqoO4-0007CI-42; Tue, 18 Nov 2014 14:24:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=pao8xTO82m3zv3ZU3QXIS/rB6u3uvELW7HiyPZCBkuc=; b=M7+my+gwb9jM1GJFY5KJDzrxJIyafPlNsi/DtRKP1tMvrJ4UrOH7nyYj20up+2CZ1a43mUA4MLFRTsBTRraJehQ/yTMRIxtediC0Q3J4HCeKr3xqW34/u924LWRW4w4x4KVlHq0zGYU2yLZdboNsH+QTEg1efSJ1BsRtdPSJ9dQa+c9KYqkkwPxlQGK3VtRohcERlSToMDdI06Na5tPUYhg3d6l9nMolz0tgtXZeyMxPNURiO11qmCzKnxXvX1p5Z1KSmWKQsgwqMOlTrl3bfbZIJHTGv2YHyAR8VgNdwMoQZznywSgm6kNyu8cDYN7ExiyHTS3vwYISOw7r5KGoow==; Original-Received: from [2620:0:1cfe:9a:2ab2:bdff:fe1c:db58] by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1XqoO3-0007bc-3n; Tue, 18 Nov 2014 11:24:27 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:177639 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c8wLqh7EM6RWUcWmfBOdVdRtc5Ip73EAR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/18/2014 11:19 AM, Lars Magne Ingebrigtsen wrote: > Eli Zaretskii writes: >=20 >>> From: Lars Magne Ingebrigtsen >>> Date: Tue, 18 Nov 2014 19:29:02 +0100 >>> Cc: emacs-devel@gnu.org >>> >>> There's a C variable called running_asynch_code, but it's not exposed= to >>> Lisp. Unless there's something else in there that can be used, shoul= d >>> we just export that to Lisp, like the `noninteractive' variable? >> >> Why do you need that exposed? If you want to know when some Lisp is >> run by a process filter, then make the filter function pass an >> argument to that Lisp saying it's run by a filter. Will that do? >=20 > Passing an argument to this function, which is way way way down in the > call stack, isn't practical. And it would be irrelevant to most of the= > url.el code, anyway. >=20 > Being able to discern whether you're running code asynchronously seems > like a generally useful thing. Our goal is to make Emacs more > asynchronous, so we need a way for functions to know what context they > are being run in, so they know what they're allowed to do You can also look at that as making it harder to debug code that magicall= y behaves differently when invoked through the repl or the debugger. Why = does this code need to know whether it's being run asynchronously? --c8wLqh7EM6RWUcWmfBOdVdRtc5Ip73EAR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUa5zlAAoJEN4WImmbpWBlvtAP/0hp++NG8wC/jiNgBXflXV5I MDnaoKO4nzzmDtsqIWI+cCuwFguGtSLRcQTdBKHXOGztzHcf8RMJIoGAP9p5SWg+ FFqw2JpcmQMyUzm2sapLVVyll2bO9eFhRc7LgHhWnhMNxOcIJKYKq4zWIp9byVck LPzE73X7G7w+dSuyvPWuqEw8sLhC3VYtSIlsqXYnwQcsUWKzizXPSn21TT4R/fK3 2fuZwV1WdxhIanhQV8G/hNFWB9VPQ58OCNwigXSZXsFZVfz5adIkrAJEHD94sPwl l3kyNY35Sf05WCcoqdaoG9knzcfsmOhKO+iatWznwq2NR4KfcVO/JLNTRMtTYJ89 64y71R2dVWCNnJBY+6woYaqGkjvhloQhACWfuopVDNqDQiGqn2zHdqG6ekMnJz6+ US/N24sKVU2I2yELJGnVrpsCai1bX+Hf1XTj3M2g+kBJuMSGq7dkupj1NXUbjA8R nDg4yAf6H4XjSX2MBj3XqY5LwPhwFvgpseyE/qE1KbQXD7j5NSIMYHk38CgMQuMY /O5Eh2b+cjnb3mFx/tcDiIHT8SH7leg561Js52TYa4L0ORJpQz0iFvW28lOTkhcs J67U5FvyUYMpbuDCiB1jkBmcOqJmIkII2eY4aM3tmmkKOgY6DuFfheoVCYTXF7t2 AXxlo9dlb9A3X6pjQdaZ =7ucN -----END PGP SIGNATURE----- --c8wLqh7EM6RWUcWmfBOdVdRtc5Ip73EAR--