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

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

[João Távora]

Hi,

I just read

   http://demonastery.org/2013/04/emacs-narrow-to-region-indirect/

which is a great demonstration of the utility of combining two existing
emacs core features: region-narrowing and indirect buffers.

In the comments, it goes on to suggest (as does the screen-shot) that
this could be a good replacement for the multiple-major-mode holy
grail. Someone here also asked about some kind of mini-editing-windows
after Adobe Brackets and I also think this could be a good alternative.

Problem is, that when I to switch modes in an indirect buffer, I get
this:

    "Not enabling jit-lock: it does not work in indirect buffer"

Then, no fontification and subsequent disappointment.

I don't know anything about fontification techniques, so I don't even
know if the question makes sense, but isn't there a way to get
fontification (even if slower than jit-lock-mode) in the indirect
buffer, and keep the base buffer jit-locked?

João

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

[Glenn Morris]

(Using two mailing lists is almost never appropriate.)

Indirect buffers are not well regarded; see eg

http://lists.gnu.org/archive/html/help-gnu-emacs/2014-01/msg00571.html

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

[Stefan Monnier]

> I don't know anything about fontification techniques, so I don't even
> know if the question makes sense, but isn't there a way to get
> fontification (even if slower than jit-lock-mode) in the indirect
> buffer, and keep the base buffer jit-locked?

Everything is possible, yes.  But I just recommend you don't go there,
it's a waste of time.


        Stefan

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

[João Távora]

Glenn Morris <rgm@gnu.org> writes:

> (Using two mailing lists is almost never appropriate.)

I thought this could trigger different takes from both user-level (some
easy workaround) and development perspectives (the discussion you linked
to), so I cross posted, seemed appropriate, but sorry.

> Indirect buffers are not well regarded; see eg
>
> http://lists.gnu.org/archive/html/help-gnu-emacs/2014-01/msg00571.html

Thanks, that discussion seems exhaustive, will read up.

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

[Vitalie Spinu]

 >>> Stefan Monnier on Mon, 07 Apr 2014 16:40:19 -0400 wrote:

 >> I don't know anything about fontification techniques, so I don't even
 >> know if the question makes sense, but isn't there a way to get
 >> fontification (even if slower than jit-lock-mode) in the indirect
 >> buffer, and keep the base buffer jit-locked?

 SM> Everything is possible, yes.  But I just recommend you don't go there,
 SM> it's a waste of time.

Waste of time or not, it has been done: https://github.com/vitoshka/polymode

Indirect buffers constitute the core of mode switching but are not
crucial for the rest of the package. I intentionally abstracted it from
all other stuff. If emacs ever comes with something smarter than
indirect-buffers I would be happy to adapt the mode switching mechanism.

I have been using it for more than an year in an unfinished state for
markdown and noweb and the experience was pretty delightful. Indirect
buffers are very fast and one-mode-per-indirect-buffer strategy makes
the whole system pretty robust.

Only recently I found time to finish the design, but then discovered
that jit-lock was removed. I am piggybacking on jit-lock and its removal
is a real bad luck. The last thing I need right now is to re-implement
jit-lock in indirect buffers.

Would it be possible to add a binary switch so that people can activate
jit-lock if they really need it?

Thanks, 

   Vitalie