From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Lennart Borgman (gmail)" Newsgroups: gmane.emacs.help Subject: Re: MY window tree! Date: Mon, 15 Jan 2007 15:41:44 +0100 Message-ID: <45AB92A8.7030300@gmail.com> References: <45A8B034.8020301@gmx.at> <45AA17CE.9050009@gmail.com> <45AA6B59.30203@gmx.at> <45AAA21C.6090505@gmail.com> <45AAB98F.8060404@gmail.com> <45AB2CDB.1040207@gmx.at> <45AB7C99.6050002@gmail.com> <45AB8B1F.7010408@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1168881228 10864 80.91.229.12 (15 Jan 2007 17:13:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2007 17:13:48 +0000 (UTC) Cc: martin rudalics , help-gnu-emacs@gnu.org, michael@cadilhac.name Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jan 15 18:13:46 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by lo.gmane.org with esmtp (Exim 4.50) id 1H6VJk-0002Ep-Ax for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 18:08:20 +0100 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1H6VIo-0008SU-M0 for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 18:07:24 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6T2F-0001oi-0R for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Jan 2007 09:42:07 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1H6T1w-0001ks-JC for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 09:41:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1H6T1t-0001hy-B5 for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 09:41:46 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1H6T1s-0001hf-Kh for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 09:41:44 -0500 Original-Received: from [80.76.149.212] (helo=ch-smtp01.sth.basefarm.net) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1H6T1r-0001SP-VL for help-gnu-emacs@gnu.org; Mon, 15 Jan 2007 09:41:44 -0500 Original-Received: from c83-254-145-24.bredband.comhem.se ([83.254.145.24]:60851 helo=[127.0.0.1]) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.63) (envelope-from ) id 1H6T1p-00075q-5x; Mon, 15 Jan 2007 15:41:42 +0100 User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) Original-To: Juanma Barranquero In-Reply-To: X-Antivirus: avast! (VPS 0703-1, 2007-01-15), Outbound message X-Antivirus-Status: Clean X-Scan-Result: No virus found in message 1H6T1p-00075q-5x. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1H6T1p-00075q-5x 5cf48827591038b9b86f98933c6f95c5 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:40305 Archived-At: Juanma Barranquero wrote: > On 1/15/07, Lennart Borgman (gmail) wrote: > >> But overlays are bound to buffers AFAIK. I can not see there are any >> problems with buffers here. Or am I missing something? > > Buffer B's mode, A-mode, has functions to create and maintain a list > of overlays, O1..ON, some of which have a 'window property. You change > windows and copy a subset of O1..ON, O'M..O'K. Now the buffer has > overlays A-mode knows nothing about. If A-mode has, for example, a > command to move some subset of O1..ON, it will leave behind O'M..O'K > even if they're copies of some of the ones moved. > > The problem is that by creating new overlays you're bypassing A-mode's > expectations about what B contains. If B detects the overlays by > searching them, fine. But B can use shortcuts like lists, or perhaps > hash tables. I have actually changed that to just change the 'window property of the overlays. No overlays are normally copied any more. If the window object that the 'window properties points to is not a valid window any more then I just replace that value with a pointer to the new window that have replaced the old one. I guess that for most cases this will be sufficient. But there can still be cases where a mode (or some other code) have a persisting pointer to a window object. I can not replace this pointers. I would suspect that this situation is not very common, but I am not sure. I am not aware of any such case at all so please tell me so I can get a better picture of this. >> Is not the only binding from overlays to windows the 'window property >> that can be set for some overlays. > > Perhaps, but I'm talking of the binding from overlays to buffers to > mode functions that manipulate them. > >> but it would be good to >> have primitives for handling cases like this there. > > Agreed. (After The Release And Other Usual Disclaimers) > > /L/e/k/t/u >