emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Differences between ibuffer and dired


From: Drew Adams
Subject: RE: Differences between ibuffer and dired
Date: Thu, 1 Jul 2010 09:47:30 -0700

> > I would like that very much. I'm just afraid that both modes are so
> > old that people have gotten very used to the keymaps by now and will
> > be very reluctant to relearn them if we change them now.
> 
> Just prepare to make it an option if old users complain. I would guess
> that very many are annoyed by the difference today.

If you really must do this kind of thing, please keep it to a minimum.  And
please propose and discuss each key change on its own merits.

And remember that Dired is _much_ older - Ibuffer is only a few years old
(~2007, IIUC).  Attempts to move toward consistency here should, other things
being equal, move toward the Dired bindings, not those of Ibuffer.  

To the extent that consistency here is important, Ibuffer should have dealt with
it at the time it was created.  And maybe it did: Perhaps the designers of
Ibuffer had good reasons for any inconsistencies they introduced between Ibuffer
and Dired.  (That does not necessarily mean they were right.)  To the extent
that any such inconsistencies were simply oversights, they can be considered
Ibuffer bugs.

Keep in mind too that it is not simply the habits of users that will be
affected.  3rd-party libraries are likely to have adopted the bindings of one or
the other of these libraries, for consistency with it (and hence with user
habits).

For example, Bookmark+ is consistent with Dired's bindings (e.g. wrt marking and
removing marks and flags).  Dired has been present since Day One; it has many,
many users; and it has likely influenced a good deal of non-core code by now.
Do not gratuitously change its bindings.

Finally, remember that there can be good reasons for inconsistency between
different parts of a system.  In particular, it can be the case that consistency
(or optimization or convenience or some other quality) _within_ a part calls for
inconsistency _between_ parts.

For example, the key bindings within Ibuffer need to work together and fit the
logic and use of Ibuffer features, and that consideration could argue in favor
of differences with Dired.  (Just hypothetical - I know little about Ibuffer
itself.)

In sum:

* Treat proposed changes on a case-by-case basis, discussing them.
* Respect Dired.  Respect time.  Respect user numbers.
* Consider consistency wrt its scope.  And remember that it is not the only
important quality.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]