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 10:58:22 -0700 Organization: UCLA Anderson School of Management Message-ID: <87ioowcr7l.fsf@gmail.com> References: <87k39ee7qm.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1400867924 21677 80.91.229.3 (23 May 2014 17:58:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 May 2014 17:58:44 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 23 19:58:39 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 1Wntjm-0007Hh-77 for ged-emacs-devel@m.gmane.org; Fri, 23 May 2014 19:58:34 +0200 Original-Received: from localhost ([::1]:45046 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wntjl-0000GQ-Un for ged-emacs-devel@m.gmane.org; Fri, 23 May 2014 13:58:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wntjj-0000GA-AC for emacs-devel@gnu.org; Fri, 23 May 2014 13:58:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wntjg-00040c-7R for emacs-devel@gnu.org; Fri, 23 May 2014 13:58:31 -0400 Original-Received: from mail-ie0-x22f.google.com ([2607:f8b0:4001:c03::22f]:32877) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wntjf-00040G-VV for emacs-devel@gnu.org; Fri, 23 May 2014 13:58:28 -0400 Original-Received: by mail-ie0-f175.google.com with SMTP id y20so5362976ier.20 for ; Fri, 23 May 2014 10:58:26 -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=jHbL6fz9aZsBWekhVKT+0uUd9gIQDGpygfexU1If8EE=; b=S6hkavk335zEcYieDAtEmk8JrlnYYGGWdAiE23RFpRN2nBpjFhT+C93L15k4acUcO/ 7h3WkD1Hf+4VszYShN+9mBhu6MsdTRHp2hxlWJVBvyWlVdsyZSKd6mqpViquDpRHZfdk ySm3vT+TKSopoNt3MycS4XKOCiEsw5omB8gbBj7hNEPEkrhDXDbbN4BHO2VZ75suo6E4 2NWvOBmR6ibiciWDYIvZZXgWNVtJ+oMukuDXYtlI0R8IFjEZy8Biolfp825ZsdBnpST/ S6Kn0mzgJPcNKK2Pu4q1/JkGL/9Q4N6VUC4Is/gGykK3S3CVop2FPSVNvp0rGhog5+v9 Mm6g== X-Received: by 10.42.62.133 with SMTP id y5mr6529922ich.6.1400867906052; Fri, 23 May 2014 10:58:26 -0700 (PDT) Original-Received: from localhost ([2602:306:cf9d:36e0:7218:8bff:feae:a65e]) by mx.google.com with ESMTPSA id vu3sm5675553igc.6.2014.05.23.10.58.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 23 May 2014 10:58:24 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 23 May 2014 09:27:35 -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:4001:c03::22f 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:172048 Archived-At: >>> Stefan Monnier on Fri, 23 May 2014 09:27:35 -0400 wrote: >> Waste of time or not, it has been done: https://github.com/vitoshka/polymode > How 'bout we add it to GNU ELPA? That would be great, but how often can I update it at ELPA? AFAIK elpa is for "stable" packages and polymode is still pretty far from being stable. There is still some work to be done - chunk cashing with text properties, indentation tweaks, poly-web-mode, etc. MELPA works just great for quick syncs. [...] > So when jit-lock is triggered it has to refontify in all buffers that > share the same base buffer. And if font-lock is activated in several > buffers which share the same base buffer, they'll fight over their > shared `face' text-property. I think I saw a couple of infloops because of that. > A related issue is that after/before-change-functions are currently only > run in the current-buffer, even though the changes affect all buffers > which share the same base-buffer. > I think the right fix is to change the C code such that > fontification-functions and after/before-change-functions are always > obeyed only in the base buffer. I.e. when displaying an indirect > buffer, we'd check the fontification-functions of the base buffer and > run jit-lock in that base-buffer. When making changes in an indirect > buffer, we'd check after/before-change-functions in the base buffer > and run them there. Why exactly after/before-change-functions should work in the base buffer only? At least from polymode prospective it would be ideal if font-lock/change-functions could act *only* on current buffer. In polymode each mode has its own buffer and font-lock and change-functions are very different in base and indirect buffers. 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. I guess for after/before-change-functions this argument applies more broadly. One might want to have a change-function that acts differently depending on whether the current buffer is indirect or not. For example auto complete popup implemented with overlays must act in current buffer because overlays are not shared. How about fixing the problem by enforcing the font-lock/change-functions only in the current buffer? That is, when in indirect buffer, fontify only indirect buffer, when in the base buffer, fontify only the base buffer. I thought this was how it worked before. > Do you think you could try to write such a patch? I am not familiar with emacs C internals but I can definitely look into that; great opportunity to learn. It won't be very quick, though. Vitalie