From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.help Subject: Re: indirect-buffers and text-properties Date: Fri, 31 Jan 2014 09:52:09 +0000 Message-ID: <87a9eccwc6.fsf@newcastle.ac.uk> References: <87fvo5r6uk.fsf@newcastle.ac.uk> <8761p1r214.fsf@newcastle.ac.uk> <87txclpj72.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391161949 12528 80.91.229.3 (31 Jan 2014 09:52:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jan 2014 09:52:29 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Stefan Monnier Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jan 31 10:52:36 2014 Return-path: Envelope-to: geh-help-gnu-emacs@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 1W9Alz-0004BT-NH for geh-help-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 10:52:31 +0100 Original-Received: from localhost ([::1]:53994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Alz-0004dq-EX for geh-help-gnu-emacs@m.gmane.org; Fri, 31 Jan 2014 04:52:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Alm-0004di-So for help-gnu-emacs@gnu.org; Fri, 31 Jan 2014 04:52:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W9Ali-0000ar-4E for help-gnu-emacs@gnu.org; Fri, 31 Jan 2014 04:52:18 -0500 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:49605) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W9Alh-0000aT-Rz for help-gnu-emacs@gnu.org; Fri, 31 Jan 2014 04:52:14 -0500 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129]) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1W9Alg-0001bO-Ct; Fri, 31 Jan 2014 09:52:13 +0000 Original-Received: from localhost (jangai.ncl.ac.uk [10.66.67.223]) (authenticated bits=0) by smtpauth-vm.ncl.ac.uk (8.13.8/8.13.8) with ESMTP id s0V9qBoF012965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 31 Jan 2014 09:52:12 GMT In-Reply-To: (Stefan Monnier's message of "Thu, 30 Jan 2014 11:17:39 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:95828 Archived-At: Stefan Monnier writes: >> I would, but I am not sure what the correct behavour is. >> Consider: >> Window 1 (point at beg) >> ---- >> Window 2 (point at end) >> C-x 1 >> Window 1 (point at beg) > >> C-x 2 >> Window 1 (point at beg) >> ---- >> Window 2 (point at beg) > >> If one of the two windows is indirect, at least point is preserved >> somewhere, so I can get back to it. > > We could stash the window-point to some buffer-local variable > buffer-other-points when the window is removed, and when the buffer is > displayed in a new window, we could check if buffer-other-points holds > other locations and reuse them. And/or provide a new command to cycle > through those buffer-other-points. And/or use the mark-ring instead of > buffer-other-points and just let the user use mark-ring navigation to > return to the previous position. I think the cycling might be the best way; so when a window disappears, point is stored just before it goes. It would be rather like registers but automatic. In fact, I do use registers for this, but find it works poorly because I have to remember that I am going to want to go back to something. Having a buffer automatically do this when a new window is displayed might be difficult; I think it would need an awful lot of DWIM semantics, and I am not sure what these would be. >> Okay, I have to accept your word on this, but I can't see another >> solution in my head. The best I have come up with is to hook into the >> change-functions, and link two (otherwise independent buffers) together >> so that the text in both is identical. AFAICT this is tractable, at >> least if I only edit one of them. > > I tend to this the "multiple major-mode in a single buffer" option would > work better. > > But in any case, there is no simple solution like "indirect-buffer". > > Each of the major modes that participate in a mixed-mode buffer needs to > be written in a way that is aware of the fact that there can be other > modes on other parts of the buffer. Indeed. I shall look at these solutions before I go further; but fiddling with major modes to make them work together is also a costly exercise. Phil