* bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message @ 2014-06-08 15:53 Drew Adams 2014-06-08 16:39 ` Indirect buffers Eli Zaretskii 2016-04-29 20:44 ` bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Lars Ingebrigtsen 0 siblings, 2 replies; 5+ messages in thread From: Drew Adams @ 2014-06-08 15:53 UTC (permalink / raw To: 17738 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'' ^ permalink raw reply [flat|nested] 5+ messages in thread
* Indirect buffers 2014-06-08 15:53 bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Drew Adams @ 2014-06-08 16:39 ` Eli Zaretskii 2014-06-09 10:49 ` Phillip Lord 2016-04-29 20:44 ` bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Lars Ingebrigtsen 1 sibling, 1 reply; 5+ messages in thread From: Eli Zaretskii @ 2014-06-08 16:39 UTC (permalink / raw To: Drew Adams, Vitalie Spinu; +Cc: Stefan Monnier, emacs-devel > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Indirect buffers 2014-06-08 16:39 ` Indirect buffers Eli Zaretskii @ 2014-06-09 10:49 ` Phillip Lord 2014-06-09 14:41 ` Eli Zaretskii 0 siblings, 1 reply; 5+ messages in thread From: Phillip Lord @ 2014-06-09 10:49 UTC (permalink / raw To: Eli Zaretskii; +Cc: Vitalie Spinu, Stefan Monnier, Drew Adams, emacs-devel 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Indirect buffers 2014-06-09 10:49 ` Phillip Lord @ 2014-06-09 14:41 ` Eli Zaretskii 0 siblings, 0 replies; 5+ messages in thread From: Eli Zaretskii @ 2014-06-09 14:41 UTC (permalink / raw To: Phillip Lord; +Cc: spinuvit, monnier, drew.adams, emacs-devel > 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message 2014-06-08 15:53 bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Drew Adams 2014-06-08 16:39 ` Indirect buffers Eli Zaretskii @ 2016-04-29 20:44 ` Lars Ingebrigtsen 1 sibling, 0 replies; 5+ messages in thread From: Lars Ingebrigtsen @ 2016-04-29 20:44 UTC (permalink / raw To: Drew Adams; +Cc: 17738 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-04-29 20:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-06-08 15:53 bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Drew Adams 2014-06-08 16:39 ` Indirect buffers Eli Zaretskii 2014-06-09 10:49 ` Phillip Lord 2014-06-09 14:41 ` Eli Zaretskii 2016-04-29 20:44 ` bug#17738: 24.4.50; (jit-lock-mode nil) in indirect buffer: wrong message Lars Ingebrigtsen
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.