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 22:28:35 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <20020827022840.90B149865B@optonline.net> References: NNTP-Posting-Host: localhost.gmane.org Content-Transfer-Encoding: 7BIT X-Trace: main.gmane.org 1030415512 16766 127.0.0.1 (27 Aug 2002 02:31:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 27 Aug 2002 02:31:52 +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 17jW8z-0004ME-00 for ; Tue, 27 Aug 2002 04:31:49 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17jWe5-0005XL-00 for ; Tue, 27 Aug 2002 05:03:58 +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 17jWAH-0007uY-00; Mon, 26 Aug 2002 22:33:09 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17jW8z-0007pW-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 22:31:49 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17jW8x-0007pK-00 for emacs-devel@gnu.org; Mon, 26 Aug 2002 22:31:49 -0400 Original-Received: from mta2.srv.hcvlny.cv.net ([167.206.5.5]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17jW8x-0007pF-00; Mon, 26 Aug 2002 22:31:47 -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 <0H1H002IUDK876@mta2.srv.hcvlny.cv.net>; Mon, 26 Aug 2002 22:28:56 -0400 (EDT) Original-Received: by optonline.net (Postfix, from userid 500) id 90B149865B; Mon, 26 Aug 2002 22:28:40 -0400 (EDT) Original-Received: from mail.optonline.net (localhost [127.0.0.1]) by optonline.net (Postfix) with ESMTP id 86CF09865A; Mon, 26 Aug 2002 22:28:40 -0400 (EDT) In-Reply-To: Message from Miles Bader "of 27 Aug 2002 10:52:41 +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:6956 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6956 Miles, If I understand you correctly, almost everything that you have described is already there and is available from the menus. 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. Anyway, if you have a better design, the field is wide open. I just want to air my opinion on one suggestion of yours: 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. One thing that Ediff doesn't do (among the things that you have listed) is to give the user complete control of how exactly the windows should look like. It has its own idea (although it is more flexible than you probably think). But if you RTMF, you will see that all this is just one variable/function, which you can customize. If you have the time and a design, you can write your own window setup function and offer it to the world. --michael > Michael Kifer writes: > > Somebody> [ediff's user interface seems generally pretty bad; I > > Somebody> like the functionality, but never use it because it > > Somebody> drives me nuts every time I try] > > > > I am open to suggestions, but I don't have much time to make major changes. > > I don't think anybody expects you to, certainly not without a real plan, > and hopefully anyone who really wants a change would do the work. > > Anyway, though I don't like ediff's UI, it's not entirely clear to me > what a better UI would look like; perhaps discussion could turn up > some ideas. > > I think my main problem with ediff is that it seems way too stateful -- > it sets up an `ediff session' and puts up a special `control frame' (or > window), and generally seems very heavyweight. I guess many people like > this (it's sort of like many dedicated GUI diff programs), but I don't; > it's very un-emacsy. When I see all that state, I worry what happens if > I forget that I'm ediffing and delete a buffer or change a buffer, &c. > Maybe this worry is unwarranted, but I think it's kind of natural given > the general style of the ediff UI. > > Compared to other programs, emacs gives the user much more freedom over > the configuration of windows, etc., and the ability to freely switch to > other tasks, so very stateful UIs often cause problems. > > [The same `stateful' complaint could be made about e.g. Gnus, but I find > that when I want to use ediff, I also want to mess with CVS, visit other > source files, etc., and generally mess up the nice window configuration > ediff set up; this doesn't generally seem to happen with Gnus.] > > I'd prefer that _all_ ediff state be contained within the two buffers > being diffed; if I kill them both, poof, no more ediff state (if I kill > only one, who knows, but presumably an error when you try to perform an > ediff operation). [Maybe this is the case already, and I'm being fooled > by the appearance of the UI; what happens when you try two simulaneous > ediff sessions, for instance?] > > This of course means that something has to be done about ediff commands; > I'd be happy with a simple command-mode vs. edit-mode toggle (look at > `diff-mode' for a particularly elegant implementation, BTW -- it puts > all the special single-letter command shortcuts on a minor-mode keymap > enabled by `buffer-read-only', so when the file's editable, you can edit > it, and you can just do toggle-read-only to get the convenient shortcut > commands). > > Anyway, that's my take. > > > PS. On the other hand, I receive tons of email attesting to the contrary. > > Well, I think there's no doubt that ediff contains some great > functionality. > > -Miles > -- > `...the Soviet Union was sliding in to an economic collapse so comprehensive > that in the end its factories produced not goods but bads: finished products > less valuable than the raw materials they were made from.' [The Economist] >