From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Indirect buffers Date: Sun, 08 Jun 2014 19:39:49 +0300 Message-ID: <83egyz2w4q.fsf@gnu.org> References: <61933bd2-7a72-4666-bf23-deb677e1d62f@default> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1402245616 32053 80.91.229.3 (8 Jun 2014 16:40:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 8 Jun 2014 16:40:16 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Drew Adams , Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 08 18:40:09 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Wtg8f-0003xK-Bn for ged-emacs-devel@m.gmane.org; Sun, 08 Jun 2014 18:40:09 +0200 Original-Received: from localhost ([::1]:57076 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtg8e-00069N-Rh for ged-emacs-devel@m.gmane.org; Sun, 08 Jun 2014 12:40:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42217) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtg8X-00066k-93 for emacs-devel@gnu.org; Sun, 08 Jun 2014 12:40:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wtg8R-0007u6-KU for emacs-devel@gnu.org; Sun, 08 Jun 2014 12:40:01 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:55650) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wtg8R-0007tr-7M for emacs-devel@gnu.org; Sun, 08 Jun 2014 12:39:55 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N6U00L00ZM0KZ00@mtaout29.012.net.il> for emacs-devel@gnu.org; Sun, 08 Jun 2014 19:40:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N6U00EPQZN1X660@mtaout29.012.net.il>; Sun, 08 Jun 2014 19:40:14 +0300 (IDT) In-reply-to: <61933bd2-7a72-4666-bf23-deb677e1d62f@default> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172412 Archived-At: > Date: Sun, 8 Jun 2014 08:53:54 -0700 (PDT) > From: Drew Adams > > [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.