From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Suggestions for mode-line-format changes Date: 27 Aug 2002 11:53:09 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <20020827022840.90B149865B@optonline.net> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1030416856 12592 127.0.0.1 (27 Aug 2002 02:54:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 02:54:16 +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 17jWUg-0003Gw-00 for ; Tue, 27 Aug 2002 04:54:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jWzm-000632-00 for ; Tue, 27 Aug 2002 05:26:23 +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 17jWVz-0002tB-00; Mon, 26 Aug 2002 22:55:35 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jWTl-0002qx-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 22:53:17 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jWTj-0002qk-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 22:53:17 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jWTi-0002qb-00; Mon, 26 Aug 2002 22:53:15 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g7R2rBG25988; Tue, 27 Aug 2002 11:53:11 +0900 (JST) Original-Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g7R2rB510814; Tue, 27 Aug 2002 11:53:11 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g7R2r8G05021; Tue, 27 Aug 2002 11:53:09 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g7R2r9s17026; Tue, 27 Aug 2002 11:53:09 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 1E5EB36F2; Tue, 27 Aug 2002 11:53:09 +0900 (JST) Original-To: Michael Kifer System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <20020827022840.90B149865B@optonline.net> Original-Lines: 37 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:6957 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6957 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). > 80% of ediff's functionality can be figured out without reading the > manual. Did you ever try to hit the "?" mark in that small window or > try to experiment with Menubar.Tools."Ediff Miscellanea"? > But RTFM is always a good idea. Of course. It shows lots of handy commands -- but `how to find ediff commands' wasn't what I was complaining about. > 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. -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal