From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: The window-pub branch Date: Sun, 05 Dec 2010 12:44:48 +0100 Message-ID: <4CFB7B30.9030309@gmx.at> References: <4CE56872.6050502@gmx.de> <4CE6A9C3.5060400@gmx.de> <4CE792B7.7090406@gmx.at> <4CE7DEAB.8030401@gmx.de> <4CE80D77.10801@gmx.at> <4CE83A6B.6090904@gmx.de> <4CE8EB28.3060607@gmx.at> <4CE91FED.9060705@gmx.de> <4CE95C04.1090905@gmx.at> <4CEA3A75.50100@gmx.at> <4CEA514F.2030901@gmx.de> <4CEA53A5.9080009@gmx.at> <4CEA575E.5020607@gmx.de> <4CEA78DB.6010107@gmx.at> <4CEAA8C5.6080503@gmx.at> <4CEB703A.4070309@gmx.at> <4CEBDE5B.1070904@gmx.at> <4CEBF770.6080309@gmx.at> <4CFA8432.5000708@gmx.de> 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: dough.gmane.org 1291549510 29349 80.91.229.12 (5 Dec 2010 11:45:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 5 Dec 2010 11:45:10 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: grischka Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 05 12:45:02 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PPD1a-0005VT-1c for ged-emacs-devel@m.gmane.org; Sun, 05 Dec 2010 12:45:02 +0100 Original-Received: from localhost ([127.0.0.1]:60517 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPD1Z-0000Ux-Jd for ged-emacs-devel@m.gmane.org; Sun, 05 Dec 2010 06:45:01 -0500 Original-Received: from [140.186.70.92] (port=50221 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPD1T-0000Uk-CQ for emacs-devel@gnu.org; Sun, 05 Dec 2010 06:44:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPD1S-0005nV-99 for emacs-devel@gnu.org; Sun, 05 Dec 2010 06:44:55 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:48145 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PPD1R-0005mH-PR for emacs-devel@gnu.org; Sun, 05 Dec 2010 06:44:54 -0500 Original-Received: (qmail invoked by alias); 05 Dec 2010 11:44:49 -0000 Original-Received: from 62-47-41-109.adsl.highway.telekom.at (EHLO [62.47.41.109]) [62.47.41.109] by mail.gmx.net (mp001) with SMTP; 05 Dec 2010 12:44:49 +0100 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX183fih4hD03ahjVsKjKThdHEhWQ593o65qmvTcAGy cXIzZ2RgEA7x0L User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <4CFA8432.5000708@gmx.de> X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:133431 Archived-At: > I found out that hooking ediff to use just 'display-buffer is > actually easy via 'ediff-window-setup-function'. For some value of easy ;-) > Here is some code if you want to test your future version of > 'display-buffer'. It works quite well with a slightly improved > version of EWM for 'ediff-files'. What does EWM different from the standard setup of ediff? I suppose you'd use the primary and secondary edit window for the A and B buffer and a third one (the compile window maybe) for the H buffer. Is your primary aim to keep things like the sidebar and top windows alive - that is to "embed" the ediff windows in the rest of your frame components? > The wrapper calls two functions that you'd Who is "you"? > need to have: > > my-display-multi-buffers (list-of-buffers-and-labels) > ;; display some buffers and return list of their windows I'm currently using the third argument of `display-buffer' as label (I call it TAG so far). For `pop-to-buffer' it's the fourth. > my-select-window (window) > ;; select 'window' and frame where it's on: In what sense is this different from `select-window'? In some ediff sense (I didn't look into their code)? > (setq ediff-window-setup-function [...] > (my-display-multi-buffers > `((,A . ediff-A) > (,B . ediff-B) > (,C . ediff-C) > (,H . ediff-H) The great problem I see here is that setting up a window for C might depend on _where_ A and B have been displayed before. Suppose you want to write a `display-buffer-function' for ediff-C: How would you know where A and B are displayed? If you can put all in one function (like `ediff-setup-windows-multiframe-merge') things are fairly simple. But with separate display functions things get messy. Or do you mean that `my-display-multi-buffers' itself should track such window dependencies? martin