emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled


From: Vitalie Spinu
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
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)

 >>> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]