all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Lennart Borgman'" <lennart.borgman@gmail.com>,
	"'Deniz Dogan'" <deniz.a.m.dogan@gmail.com>
Cc: joakim@verona.se, 'Emacs-Devel devel' <emacs-devel@gnu.org>
Subject: RE: Differences between ibuffer and dired
Date: Thu, 1 Jul 2010 09:47:30 -0700	[thread overview]
Message-ID: <BCE5CBD889F3424AA2204D15E1EF0C99@us.oracle.com> (raw)
In-Reply-To: <AANLkTilgDiG1LAcpvQit__fEd9IX7b8OKrMhxSyNkOiy@mail.gmail.com>

> > 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	other threads:[~2010-07-01 16:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-01 13:49 Differences between ibuffer and dired Deniz Dogan
2010-07-01 14:34 ` joakim
2010-07-01 15:16   ` Deniz Dogan
2010-07-01 15:28     ` Lennart Borgman
2010-07-01 16:47       ` Drew Adams [this message]
2010-07-01 18:33         ` Wojciech Meyer
2010-07-01 21:34         ` Stephen Berman
2010-07-01 21:38           ` Deniz Dogan
2010-07-01 21:48             ` Drew Adams
2010-07-01 23:27               ` Lennart Borgman
2010-07-02  0:09                 ` Drew Adams
2010-07-02  0:13                   ` Lennart Borgman
2010-07-02  0:38                     ` Drew Adams
2010-07-02  1:02                       ` Lennart Borgman
2010-07-02 20:57                 ` Juri Linkov
2010-07-02 22:36                   ` Lennart Borgman
2010-07-01 21:41           ` Drew Adams
2010-07-02  4:56         ` joakim
2010-07-02  5:31           ` Drew Adams
2010-07-02  8:17             ` joakim
2010-07-02 14:26               ` Drew Adams
2010-07-02 20:57           ` Juri Linkov
2010-07-23 15:40 ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BCE5CBD889F3424AA2204D15E1EF0C99@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=deniz.a.m.dogan@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=joakim@verona.se \
    --cc=lennart.borgman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.