all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Vitalie Spinu <spinuvit@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
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	[thread overview]
Message-ID: <8738g0ccig.fsf@gmail.com> (raw)
In-Reply-To: <jwv4n0g5j42.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 23 May 2014 16:49:09 -0400")

 >>> 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	other threads:[~2014-05-23 23:15 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07 18:34 trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled in indirect buffers João Távora
2014-04-07 20:37 ` Glenn Morris
2014-04-07 20:48   ` João Távora
2014-04-07 20:40 ` Stefan Monnier
2014-05-22  4:51   ` Vitalie Spinu
2014-05-23 13:27     ` Stefan Monnier
2014-05-23 17:58       ` Vitalie Spinu
2014-05-23 20:49         ` Stefan Monnier
2014-05-23 23:15           ` Vitalie Spinu [this message]
2014-05-24  3:10             ` Stefan Monnier
2014-05-24  9:46               ` Vitalie Spinu
2014-05-24 14:35                 ` Stefan Monnier
2014-05-30 19:26                   ` Vitalie Spinu
2014-05-30 19:54                     ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8738g0ccig.fsf@gmail.com \
    --to=spinuvit@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.