From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 23:10:43 -0400 Message-ID: References: <87k39ee7qm.fsf@gmail.com> <87ioowcr7l.fsf@gmail.com> <8738g0ccig.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400901071 21932 80.91.229.3 (24 May 2014 03:11:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 May 2014 03:11:11 +0000 (UTC) Cc: emacs-devel@gnu.org To: Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 24 05:11:04 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 1Wo2MR-0003l5-O7 for ged-emacs-devel@m.gmane.org; Sat, 24 May 2014 05:11:03 +0200 Original-Received: from localhost ([::1]:46479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wo2MR-0005zB-6m for ged-emacs-devel@m.gmane.org; Fri, 23 May 2014 23:11:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58883) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wo2MH-0005z2-8Y for emacs-devel@gnu.org; Fri, 23 May 2014 23:11:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wo2M9-0002XD-OC for emacs-devel@gnu.org; Fri, 23 May 2014 23:10:53 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:45333) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wo2M9-0002X3-JZ for emacs-devel@gnu.org; Fri, 23 May 2014 23:10:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVPO+KQe/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqgXGBWyE X-IPAS-Result: ArUGAIDvNVPO+KQe/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASpGYFqgXGBWyE X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="63927016" Original-Received: from 206-248-164-30.dsl.teksavvy.com (HELO pastel.home) ([206.248.164.30]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 23 May 2014 23:10:43 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 1A557601D9; Fri, 23 May 2014 23:10:43 -0400 (EDT) In-Reply-To: <8738g0ccig.fsf@gmail.com> (Vitalie Spinu's message of "Fri, 23 May 2014 16:15:51 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:172054 Archived-At: > Note that if I am in the indirect buffer, I don't want to run > base-buffer after/before-change-functions at all! The problem is that you're not the only user of after/before-change-functions. In the general case, all the related buffers might care to know that some part of their text has been modified. > 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. Why prohibit the hooks from the base buffer? If they're there it's presumably because they're needed. > Kinda mind-stretch. That there is no way to figure out indirect > buffers from the base buffer complicates the stuff even further. It's easy to find all the indirect buffers. In your case you'll just want to find the indirect buffer that corresponds to a particular buffer position, and that's something I'd expect you need at other places anyway. > 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. Running the after/before-change-functions of the base buffer in the base buffer means that "the action happens in the current buffer", and indeed it does: a buffer-modification happens in all the related buffers, not just in the one that happens to be current. > 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?). That means the other related buffers aren't told about the modification in their text, which is also unexpected. > What can go wrong with "run hooks in the current buffer only" > implementation? OK, let's say you chunks chunk 1 in mode A chunk 2 in mode B chunk 3 in mode A And let's say that mode A does some clever caching, so it sets up an after-change-functions hook to flush its cache. Now you go and delete a block of text in chunk 3, mode A is not warned about it and fails to flush its cache which now holds completely broken data about chunk 3. Of course, running the after-change-functions only in the base buffer won't directly help with that. I find such discussions depressing, because they always go back to "indirect buffers are an attractive nuisance", introducing more problems than they solve. > The idea of indirect buffers is great. On its own, it's almost great. But once you throw in text-properties, overlays, and buffer-local variables, plus the fact that the choice between text-properties and overlays is never based on whether "it should be shared between indirect buffers or not", plus ... it's just a big mess that just shuffles problems around without helping solve them. Stefan