From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Michael Kifer Newsgroups: gmane.emacs.devel Subject: Re: Suggestions for mode-line-format changes Date: Mon, 26 Aug 2002 23:38:50 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <20020827033855.4F0729865B@optonline.net> References: NNTP-Posting-Host: localhost.gmane.org Content-Transfer-Encoding: 7BIT X-Trace: main.gmane.org 1030419593 12801 127.0.0.1 (27 Aug 2002 03:39:53 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 03:39:53 +0000 (UTC) Cc: "Kim F. Storm" , rms@gnu.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17jXCp-0003KI-00 for ; Tue, 27 Aug 2002 05:39:51 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jXhx-0007AR-00 for ; Tue, 27 Aug 2002 06:12:01 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jXE6-0000dk-00; Mon, 26 Aug 2002 23:41:10 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jXCS-0000cf-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 23:39:28 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jXCQ-0000cR-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 23:39:27 -0400 Original-Received: from mta2.srv.hcvlny.cv.net ([167.206.5.5]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jXCQ-0000cI-00; Mon, 26 Aug 2002 23:39:26 -0400 Original-Received: from optonline.net (ool-18baa562.dyn.optonline.net [24.186.165.98]) by mta2.srv.hcvlny.cv.net (iPlanet Messaging Server 5.2 HotFix 0.9 (built Jul 29 2002)) with ESMTP id <0H1H00288GTBD2@mta2.srv.hcvlny.cv.net>; Mon, 26 Aug 2002 23:39:11 -0400 (EDT) Original-Received: by optonline.net (Postfix, from userid 500) id 4F0729865B; Mon, 26 Aug 2002 23:38:55 -0400 (EDT) Original-Received: from mail.optonline.net (localhost [127.0.0.1]) by optonline.net (Postfix) with ESMTP id 364269865A; Mon, 26 Aug 2002 23:38:55 -0400 (EDT) In-Reply-To: Message from Miles Bader "of 27 Aug 2002 11:53:09 +0900." Original-To: Miles Bader X-Mailer: mh-e 6.1; nmh 1.0.4; Emacs 21.1 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6958 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6958 Miles Bader said: > > Michael Kifer writes: > > If I understand you correctly, almost everything that you have described is > > already there and is available from the menus. > > Well, either you don't understand me correctly, or else the menus and > documentation (which I did read) are designed for those smarter or more > patient than I. As far as I can see, _none_ of what I described is > available. > > In particular, it appears that you _always_ need a control frame/window, > and that ediff commands _only_ work in the control frame/window (even if > I type `M-x ediff-next-difference' in one of the buffers being diffed, > it just gives me an error saying that). Yes, you always need the control buffer. But you can hide it and the other windows if you need to do something else. There is a mechanism to easily find suspended ediff sessions and resume them. Your complaint was about the inability to switch to other emacs jobs and I am saying that this is not the case. It seems that none of what you explicitly listed in your original message is the real problem. Instead, you are complaining about the design decision that the small control window must be present at all times. In this regard, I think you might not have understood what I said about a bad suggestion in your previous message. The same buffer can be involved in different ediff sessions. I consider this essential. You can't just start typing commands into a buffer being diffed without first indicating which session the buffer is involved in is current. The UI by which you indicate this is not present in ediff, but can be added, because each buffer already knows the set of sessions it is in. However, I won't be the one to implement this because I think it is going to be confusing and is not necessary. > > If all the state is contained in *both* buffers (or 3 buffers), as you > > suggest, then it is a *bad* idea. The state should be in *one* > > buffer, as it is in Ediff. It was designed this way because it is > > important to be able to run multiple simultaneous diffing sessions > > that involve overlapping buffers or parts of buffers. > > It sounds like the best thing to do is have all ediff state contained > in a lisp value, which is pointed to by whatever buffers, but > presumably this would be a big change to the code. It is already contained in one place -- the control buffer. It is possible to make this buffer invisible as I indicated above and instead implement a mechanism by which you indicate the current control session. But I think this is a bad idea. This is how emerge works, and I don't like its interface. I want to be able to edit the buffers without typing special commands by just moving the mouse there. --michael