bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message

bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message

[Drew Adams]

The message says that you cannot ENABLE jit-lock-mode in an indirect
buffer.  But (jit-lock-mode nil) is meant to DISABLE it.  There should
be no such message for (jit-lock-mode nil).

[Beyond this, I hope you will revisit the behavior wrt jit-lock and
indirect buffers, to DTRT following the (unfinished) emacs-devel thread
"Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled
in indirect buffers." (2014-05-21 to 2014-05-30).  Like Vitalie, I would
like to see a solution to the problem of font-locking indirect buffers
independently of each other and of the base buffer, each according to
its major mode etc.]


In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-01 on ODIEONE
Bzr revision: 117212 michael.albinus@gmx.de-20140601104945-g88x0mwrxorz302h
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Indirect buffers

[Eli Zaretskii]

> Date: Sun, 8 Jun 2014 08:53:54 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> [Beyond this, I hope you will revisit the behavior wrt jit-lock and
> indirect buffers, to DTRT following the (unfinished) emacs-devel thread
> "Re: trunk r116426: * lisp/jit-lock.el (jit-lock-mode): Keep it disabled
> in indirect buffers." (2014-05-21 to 2014-05-30).  Like Vitalie, I would
> like to see a solution to the problem of font-locking indirect buffers
> independently of each other and of the base buffer, each according to
> its major mode etc.]

And I wish you and Vitalie just dropped the idea.  It's unworkable.
It's against the very design of the Emacs display engine.  Stefan is
right: indirect buffers are an attractive nuisance.

By the time Vitalie or someone else solves the basic problems whose
discussion has just begun in that thread, we will discover that
problems pop up all over the place.  Just wait until people start
using multi-mode implemented via indirect buffers with all the arsenal
of display-related tricks and hacks that Emacs lets you play with.
IME, you cannot possibly envision most, let alone all, of the
complications that the existing display features impose on something
like that.

And we didn't even start talking about performance, of which this
implementation will surely be a killer, except in very small buffers.

Something that at first sight already looks as going against the
current design of redisplay is simply not worth the time.  For such
fundamental features, "almost works" is really another way of saying
"broken".  If it isn't clear how to make it work "perfectly" now,
before all the complications are known, you can be sure there will be
unsolvable problems once work will have begun in earnest.

So I suggest to step back a notch, and try looking for ideas to
implement these features in a way that doesn't require different
buffers to share text.  E.g., even manually keeping several separate
buffers in sync by updating their text when it changes in one of them,
sounds like an easier way.  Emacs is very good at inserting and
deleting chunks of text into/from a buffer, and from what I've read,
all the major problems Vitalie complained about will be miraculously
solved.  It should be easy to implement a prototype in Lisp, and if it
turns out it is too slow (which I sincerely doubt), we could add some
simple infrastructure in C to speed that up.

Re: Indirect buffers

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:
> So I suggest to step back a notch, and try looking for ideas to
> implement these features in a way that doesn't require different
> buffers to share text.  E.g., even manually keeping several separate
> buffers in sync by updating their text when it changes in one of them,
> sounds like an easier way.  Emacs is very good at inserting and
> deleting chunks of text into/from a buffer, and from what I've read,
> all the major problems Vitalie complained about will be miraculously
> solved.  It should be easy to implement a prototype in Lisp, and if it
> turns out it is too slow (which I sincerely doubt), we could add some
> simple infrastructure in C to speed that up.


Forgive the plug, but this is exactly how my own linked-buffer works.

https://github.com/phillord/linked-buffer/

It works fine and is performant enough for smallish files; I haven't
tried it for much larger ones yet. This is with a very dumb
implementation (the whole buffer is copied on the after change hook).

The big advantage over indirect buffers is that I control the way in
which text in the two buffers is related; if this is `buffer-string'
you'd get the same as indirect-buffers (although less efficiently). If
you use the no-properties version, then you get something like
indirect-buffers but multi-modes work. If you use an function which
changes the text, then you can support two modes with incompatible
syntaxes. No support at all is needed from the modes.

Phil

Re: Indirect buffers

[Eli Zaretskii]

> From: phillip.lord@newcastle.ac.uk (Phillip Lord)
> Cc: Drew Adams <drew.adams@oracle.com>,  Vitalie Spinu <spinuvit@gmail.com>,  Stefan Monnier <monnier@iro.umontreal.ca>,  <emacs-devel@gnu.org>
> Date: Mon, 09 Jun 2014 11:49:05 +0100
> 
> Forgive the plug, but this is exactly how my own linked-buffer works.
> 
> https://github.com/phillord/linked-buffer/
> 
> It works fine and is performant enough for smallish files; I haven't
> tried it for much larger ones yet. This is with a very dumb
> implementation (the whole buffer is copied on the after change hook).
> 
> The big advantage over indirect buffers is that I control the way in
> which text in the two buffers is related; if this is `buffer-string'
> you'd get the same as indirect-buffers (although less efficiently). If
> you use the no-properties version, then you get something like
> indirect-buffers but multi-modes work. If you use an function which
> changes the text, then you can support two modes with incompatible
> syntaxes. No support at all is needed from the modes.

Thanks for the pointer.  I indeed wondered how was it possible that no
one came up with such a simple idea, so now I'm happy I was wrong.

bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

> The message says that you cannot ENABLE jit-lock-mode in an indirect
> buffer.  But (jit-lock-mode nil) is meant to DISABLE it.  There should
> be no such message for (jit-lock-mode nil).

I've pushed a fix now.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no