From mboxrd@z Thu Jan  1 00:00:00 1970
From: npostavs@users.sourceforge.net
Subject: bug#25132: 26.0.50; emacs hangs when loading org file with python
 source blocks
Date: Thu, 19 Jan 2017 19:52:18 -0500
Message-ID: <878tq6wo1p.fsf__21601.3031582863$1484873577$gmane$org@users.sourceforge.net>
References: <m2fulz4mjc.fsf@CIVIC-TV.local> <qwa8c75g0r.fsf@fencepost.gnu.org>
	<4aa23451-b6cd-88b0-369e-99f6fe5f2175@gmail.com>
	<m260murisv.fsf@block-party.net> <87y3yn2x4j.fsf@users.sourceforge.net>
	<87eg0e36un.fsf@users.sourceforge.net>
	<aa494e14-f35a-92c4-b954-c7ba8e4ab4b1@yandex.ru>
Mime-Version: 1.0
Content-Type: text/plain
Return-path: <emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34254)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1cUNR2-0005Ha-HE
	for emacs-orgmode@gnu.org; Thu, 19 Jan 2017 19:52:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1cUNR1-0001NT-K1
	for emacs-orgmode@gnu.org; Thu, 19 Jan 2017 19:52:08 -0500
Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-Message-ID: <handler.25132.B25132.14848734782395@debbugs.gnu.org>
In-Reply-To: <aa494e14-f35a-92c4-b954-c7ba8e4ab4b1@yandex.ru> (Dmitry Gutov's
	message of "Thu, 19 Jan 2017 19:25:04 +0300")
List-Id: "General discussions about Org-mode." <emacs-orgmode.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/emacs-orgmode/>
List-Post: <mailto:emacs-orgmode@gnu.org>
List-Help: <mailto:emacs-orgmode-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-orgmode>,
	<mailto:emacs-orgmode-request@gnu.org?subject=subscribe>
Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org
Sender: "Emacs-orgmode"
	<emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: David Dynerman <emperordali@block-party.net>, 25132@debbugs.gnu.org, =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel <clement.pit@gmail.com>

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 08.01.2017 00:20, npostavs@users.sourceforge.net wrote:
>> -            (inhibit-modification-hooks t))
>> +            (inhibit-modification-hooks
>> +             (progn (make-local-variable 'inhibit-modification-hooks) t)))
>
> Are we not worried that inhibit-modificaiton-hooks will become
> buffer-local even after control flow leaves this let*?

My feeling is that inhibit-modification-hooks should usually be buffer
local anyway.

> If we are not, why not make inhibit-modification-hooks always
> buffer-local instead?

It would have to be in addition to, because even after doing
(make-variable-buffer-local 'var), (let ((var 'foo))...) still makes a
global binding.  `make-variable-buffer-local' only has effect for
`setq', which I think will hardly ever happen for
`inhibit-modification-hooks'.

Actually, I just grepped for inhibit-modification-hooks and the only
non-let I found is this:

(defun read-passwd (prompt &optional confirm default)
   ...
      (minibuffer-with-setup-hook
          (lambda ()
             ...
             (setq-local inhibit-modification-hooks nil) ;bug#15501.
             ...))
   ...)