Re: Differences between ibuffer and dired

[Wojciech Meyer]

Hi,

Important topic. it would be on my wish list too. (mobile so excuse formatting).

Wojciech

On 7/1/10, Drew Adams <address@hidden> wrote:
>> > 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.
>
>
>
>

-- 
Sent from my mobile device