From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vitalie Spinu Newsgroups: gmane.emacs.devel Subject: Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers. Date: Fri, 23 May 2014 16:15:51 -0700 Organization: UCLA Anderson School of Management Message-ID: <8738g0ccig.fsf@gmail.com> References: <87k39ee7qm.fsf@gmail.com> <87ioowcr7l.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400886970 18368 80.91.229.3 (23 May 2014 23:16:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 May 2014 23:16:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 24 01:16:03 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 1Wnyh0-0001DI-Qj for ged-emacs-devel@m.gmane.org; Sat, 24 May 2014 01:16:03 +0200 Original-Received: from localhost ([::1]:46024 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnyh0-00061j-2L for ged-emacs-devel@m.gmane.org; Fri, 23 May 2014 19:16:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnygw-00061T-4m for emacs-devel@gnu.org; Fri, 23 May 2014 19:15:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wnygu-0007lm-9n for emacs-devel@gnu.org; Fri, 23 May 2014 19:15:58 -0400 Original-Received: from mail-pb0-x234.google.com ([2607:f8b0:400e:c01::234]:63387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wnygu-0007lY-0f for emacs-devel@gnu.org; Fri, 23 May 2014 19:15:56 -0400 Original-Received: by mail-pb0-f52.google.com with SMTP id rr13so4798548pbb.39 for ; Fri, 23 May 2014 16:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=ZI3YdYOgSCjYXJBPrwT9xawid2jo0UE/wrq54NY3IWk=; b=0JtBcHNKassjOIzYynvHg9RlJu6ocalSpq/ZcQe8noDYcG2KokdHN6zlITFh82FTr+ p6YyZf2WVK39fTmKbD4pN8E1b9UuPrKhc4ZcTYf2ecqsl3c2MWkb3ZzI+HHC1rq61mK3 93Vnl6lUvIVz9v2Y311wNfPtzNbdLpkbZwr9AHzPFKvjXb/3X+9qqVvTwAeNFawdddcr rmro/YSsBuPIJykOpxaaW4+w1binbAs8BdHUOZX6sufkB8Mbu7luJLQFO08wxglh/bhA 8yt48QoXpufNwAbPmQf8DDYvG1qcP+XUe7W/SIqS0+XCLhV87+4zcxoymP7WZgZEcRWh hKGQ== X-Received: by 10.66.139.168 with SMTP id qz8mr9615337pab.3.1400886954842; Fri, 23 May 2014 16:15:54 -0700 (PDT) Original-Received: from localhost ([2607:f010:2e9:2:7218:8bff:feae:a65e]) by mx.google.com with ESMTPSA id i10sm20086687pat.36.2014.05.23.16.15.53 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 23 May 2014 16:15:53 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 23 May 2014 16:49:09 -0400") User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c01::234 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:172053 Archived-At: >>> Stefan Monnier on Fri, 23 May 2014 16:49:09 -0400 wrote: [...] >> Why exactly after/before-change-functions should work in the base buffer >> only? > It's the simplest option. If you want them to apply to other buffers > as well, then you can still get that by adding a > after/before-change-function to the base buffer which runs the > after/before-change-functions in the indirect buffer. Note that if I am in the indirect buffer, I don't want to run base-buffer after/before-change-functions at all! I only want the hooks from the indirect buffer. So, what you propose is not quite that simple, if possible at all. Each time the after/before-change-functions are initialized in indirect-buffer I will have to somehow prohibit execution of the base-buffer change-functions and execute those from indirect-buffer. Kinda mind-stretch. That there is no way to figure out indirect buffers from the base buffer complicates the stuff even further. More generally, the fact that hooks are not executed in current-buffer will probably cause havoc in other usages of indirect buffers. I imagine that all designers of after/before-change-functions assume that the action happens in the current buffer. Your proposal will invalidate this assumption. In conclusion, unless I miss something essential, I don't see it as "the simplest option". The simplest option is to execute the hooks only in the buffer that initiated the hook (always current buffer?). >> So, if I am in C++ chunk, font-lock and change-functions better be >> from and act on current C++ buffer, not on the base buffer which is >> typically in fundamental mode. > What happens if you're inside a HTML chunk which has an embedded PHP > chunk and you edit that PHP chunk from that HTML-mode buffer instead of > from the PHP-mode buffer? This is not possible by design. Whenever you move the point the buffer is switched behind the scene. So if you are in PHP chunk you are in php-mode buffer, if you are in HTML chunk you are in html-mode buffer. [...] > Indeed, there are all kinds of possible scenarios, so the C code can't > know which set of options to choose. Same as above; I am confused. What scenarios do you mean concretely? What can go wrong with "run hooks in the current buffer only" implementation? C can simply check if the hook is executed in the current buffer. If some after/before-change-function from an indirect buffer wants to make a change to base-buffer, then it can explicitly do so. This is way more straightforward than the other way around. The idea of indirect buffers is great. They share only text and text properties, otherwise they are completely independent entities. Running indirect buffer's hooks in the base-buffer would create an unnecessary functional linkage. Hence, defeating the original intent of the indirect buffers and obfuscating the reasoning about the code. Vitalie