Re: Suggestions for mode-line-format changes

[Michael Kifer <kifer@cs.sunysb.edu>]

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 <kifer@cs.sunysb.edu> 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]
>