From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: grischka Newsgroups: gmane.emacs.devel Subject: Re: The window-pub branch Date: Sun, 05 Dec 2010 21:27:58 +0100 Message-ID: <4CFBF5CE.9090200@gmx.de> 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> <4CFB7B30.9030309@gmx.at> 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 1291580911 8024 80.91.229.12 (5 Dec 2010 20:28:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 5 Dec 2010 20:28:31 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 05 21:28:25 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 1PPLC3-0002QM-W6 for ged-emacs-devel@m.gmane.org; Sun, 05 Dec 2010 21:28:24 +0100 Original-Received: from localhost ([127.0.0.1]:56570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPLC3-0007P4-Dr for ged-emacs-devel@m.gmane.org; Sun, 05 Dec 2010 15:28:23 -0500 Original-Received: from [140.186.70.92] (port=58725 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPLBz-0007Ox-3T for emacs-devel@gnu.org; Sun, 05 Dec 2010 15:28:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPLBx-0002vm-OZ for emacs-devel@gnu.org; Sun, 05 Dec 2010 15:28:19 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:54578 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PPLBx-0002vQ-Cv for emacs-devel@gnu.org; Sun, 05 Dec 2010 15:28:17 -0500 Original-Received: (qmail invoked by alias); 05 Dec 2010 20:28:14 -0000 Original-Received: from unknown (EHLO [10.74.53.17]) [82.113.106.193] by mail.gmx.net (mp066) with SMTP; 05 Dec 2010 21:28:14 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX18eX14+1QUeK3NcOezQukZCY0jkRivh1pz8DlWvXN j2Fu50oQjun+lJ User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4CFB7B30.9030309@gmx.at> 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:133438 Archived-At: martin rudalics wrote: > > 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? Well, my primary aim was to make some tests in the first place. I'v tested with GUD too. It actually started working after I advised 'split-window' to do nothing. Of course new ideas come to mind soon. For example support for switching the entire layout descriptions in order to have some such as an 'ediff-perspective' or 'gud-perspective'. As opposed to "embedding" the windows in the existing layout if you want to. > > > The wrapper calls two functions that you'd > > Who is "you"? > > > need to have: > > I apologize, "you" does NOT have to need this. > > 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. After all it wouldn't be emacs if there were not at least two ways to do the same thing just not quite. > > > 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)? No, just different in the sense that it should really work. (Also for windows on other frames that is). > > > (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. I was under the impression that it was exactly this problem that you wanted to solve. That is how to show some content such that it's combined with some other content in some reasonable way UI-wise. > Suppose you want > to write a `display-buffer-function' for ediff-C: How would you know > where A and B are displayed? I would not want to write such function in the first place. > If you can put all in one function (like > `ediff-setup-windows-multiframe-merge') things are fairly simple. For some value of simple ;-) See ediff-wind.el ... > But with separate display functions things get messy. But the idea is messy: That the shared resource screen space could be used without proper synchronization. > Or do you mean that > `my-display-multi-buffers' itself should track such window dependencies? Yes this can be one point to have such interface: It could consider dependencies between windows if suitable. Also it could optimize away the otherwise very short-lived window configurations. EWM however neither is trying to optimize nor is it non-deterministic as to where show what window. It has a more basic problem that it cannot currently guarantee the live-p-ness of 4 windows as returned from distinct calls to ewm-display-buffer. Other than that my implementation is in fact logically identical to: (defun my-display-multi-buffers (alist) (mapcar (lambda (e) (ewm-display-buffer (car e) (cdr e))) alist )) with: ewm-display-buffer (buffer &optional label) --- grischka > > martin >