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: Mon, 06 Dec 2010 23:43:39 +0100 Message-ID: <4CFD671B.5010502@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> <4CFBF5CE.9090200@gmx.de> <4CFCAB94.5010208@gmx.at> <4CFD20DF.4000701@gmx.de> <4CFD3C78.8050102@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 1291675478 7117 80.91.229.12 (6 Dec 2010 22:44:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 6 Dec 2010 22:44:38 +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 Mon Dec 06 23:44:34 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 1PPjnN-0004Ja-El for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 23:44:34 +0100 Original-Received: from localhost ([127.0.0.1]:54112 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPjnM-0007pM-OX for ged-emacs-devel@m.gmane.org; Mon, 06 Dec 2010 17:44:32 -0500 Original-Received: from [140.186.70.92] (port=56633 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPjnH-0007l0-Sw for emacs-devel@gnu.org; Mon, 06 Dec 2010 17:44:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPjnG-0004Mc-KL for emacs-devel@gnu.org; Mon, 06 Dec 2010 17:44:27 -0500 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:43169 helo=mail.gmx.net) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PPjnG-0004MG-4x for emacs-devel@gnu.org; Mon, 06 Dec 2010 17:44:26 -0500 Original-Received: (qmail invoked by alias); 06 Dec 2010 22:44:20 -0000 Original-Received: from unknown (EHLO [10.74.249.173]) [82.113.106.199] by mail.gmx.net (mp060) with SMTP; 06 Dec 2010 23:44:20 +0100 X-Authenticated: #18588216 X-Provags-ID: V01U2FsdGVkX184yjN/8xo4mofR2/asx2OyKD2BGE11L57ep03CSd 7UsnZO1MG0Q6ab User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) In-Reply-To: <4CFD3C78.8050102@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:133475 Archived-At: martin rudalics wrote: > > I need a language to express what I want, not what I don't want. > > "unsplittable" and "dedicated" are means to suppress rather than > > to express. > > An unsplittable frame is a frame that preserves its integrity and a > dedicated window is one that preserves its buffer. Would rewriting the > documentation make you happy? What about the "integrity" of GUD when its attempts to split fail altogether? Would rewriting the documentation make GUD happy? > > When WINDOW is on another frame, `select-window' does not select > > that window for input. > > A bug. How do you make it happen? Open a second frame, show *scratch*, go to the first frame, show some file, type M-: (select-window (get-buffer-window "*scratch*" t)) type some more chars. For me, chars go to file (GTK and MS-Windows). > > ediff needs input focus on the "control-buffer" window. Otherwise if > > you type 'n' it would not jump to next difference but insert 'n' into > > your file text. > > Do you want to keep the file text window selected and redirect input to > the control window? I don't use ediff (horrible UI and all). However if you know how to improve it you might talk to the ediff people ;) > >> `display-buffer' is too low level to do that. Any such context > >> awareness must be controlled by an application like ediff or GUD via > the > >> specifiers passed to `display-buffer'. > > > > Question is not "Must it work like that" but "Can it work like that". > > Can it? Last time you were seeing a "great problem". > > I still do. That is, keeping the customization interface simple and > providing everything that's need by an application is problematic. Understandable, since the problem turns out to be difficult, the assumption is easily made that it must be solved by applications themselves. However if anything has only limited awareness of the context then it's the application. Except of course when it's the only application on the entire frame. In which case there is nothing to solve because that already works. > >> What should be properly synchronized? > > > > Access from elisp packages to the shared resource screen/frame space. > > So far this has been based on a high-level (`display-buffer') interface > and a low-level (`split-window', `delete-window' and > `set-window-buffer') interface. The former should be used wherever > possible so a user can customize it. Whether we can fully get rid of > the latter is not yet clear to me. It's also a question of backward > compatibility and whether we find the people to write it. Moreover, I > still don't know whether the normal action of C-x b should be affected > by the `display-buffer' options. Sure, I know that. I was just interested in how far you got. Maybe you have some snippet that people can try at some point. > > No. It is that any layout change destroys all window objects returned > > from earlier calls because the frame is re-split from scratch. > > A frame is never split. Splitting a window cannot destroy a window > (object). > > > > Does this happen with window-pub? > > > > As well. > > As long as you don't give me a recipe I won't believe you. See also "How it works" on top of ewm.el: http://lists.gnu.org/archive/html/gnu-emacs-sources/2010-05/msg00026.html Recipe: - visit ewm.el - M-x eval-buffer - M-: (selected-window) # - F9 ;; compilation window opens - M-: (selected-window) # So well, it's a bit magic. UI-wise you're still in the same window with 'ewm.el' but in fact it's different and the old one (#15) is not live-p anymore. > > Basically what I'd like to have is window-objects that can exist > > regardless whether or not they are part of the currently displayed > > window tree. > > That's a different issue. Fitting such an object into an existing > window configuration would probably lose most of that object's > properties. Window configurations are, however, an approximation of > what you want (even if you don't like them). I don't work with approximations. The less in free software. > > martin >