Differences between ibuffer and dired

Differences between ibuffer and dired

[Deniz Dogan]

Why are there so many inconsistencies between the ibuffer and dired
keymaps? E.g. "U" in dired unmarks all marked items, but in ibuffer it
does "replace regexp". "u" on the other hand acts the same in both
modes.

In my opinion the modes are so similar in their use cases that users
should expect the keybindings to be much more similar than they are
today, at least for such basic things such as unmarking items. So why
are there so many differences between them?

-- 
Deniz Dogan

Re: Differences between ibuffer and dired

[joakim]

Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:

> Why are there so many inconsistencies between the ibuffer and dired
> keymaps? E.g. "U" in dired unmarks all marked items, but in ibuffer it
> does "replace regexp". "u" on the other hand acts the same in both
> modes.
>
> In my opinion the modes are so similar in their use cases that users
> should expect the keybindings to be much more similar than they are
> today, at least for such basic things such as unmarking items. So why
> are there so many differences between them?

Maybe we should create an experimental "keymap consitency" branch?

I also find inconsitent keymaps highly annoying.

-- 
Joakim Verona

Re: Differences between ibuffer and dired

[Deniz Dogan]

2010/7/1  <joakim@verona.se>:
> Deniz Dogan <deniz.a.m.dogan@gmail.com> writes:
>
>> Why are there so many inconsistencies between the ibuffer and dired
>> keymaps? E.g. "U" in dired unmarks all marked items, but in ibuffer it
>> does "replace regexp". "u" on the other hand acts the same in both
>> modes.
>>
>> In my opinion the modes are so similar in their use cases that users
>> should expect the keybindings to be much more similar than they are
>> today, at least for such basic things such as unmarking items. So why
>> are there so many differences between them?
>
> Maybe we should create an experimental "keymap consitency" branch?
>
> I also find inconsitent keymaps highly annoying.
>

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.

-- 
Deniz Dogan

Re: Differences between ibuffer and dired

[Lennart Borgman]

On Thu, Jul 1, 2010 at 5:16 PM, Deniz Dogan <deniz.a.m.dogan@gmail.com> 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.

RE: Differences between ibuffer and dired

[Drew Adams]

> > 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.

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 <drew.adams@oracle.com> 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

Re: Differences between ibuffer and dired

[Stephen Berman]

On Thu, 1 Jul 2010 09:47:30 -0700 "Drew Adams" <drew.adams@oracle.com> wrote:

> And remember that Dired is _much_ older - 

That's true:

   ;;; dired.el --- directory-browsing commands
   
   ;; Copyright (C) 1985, 1986, 1992, 1993, 1994, 1995, 1996, 1997, 2000,
   ;;   2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
   ;;   Free Software Foundation, Inc.
   [...]
   ;; Rewritten in 1990/1991 to add tree features, file marking and
   ;; sorting by Sebastian Kremer <sk@thp.uni-koeln.de>.
   ;; Finished up by rms in 1992.

>                                           Ibuffer is only a few years old
> (~2007, IIUC).

But that isn't:

   ;;; ibuffer.el --- operate on buffers like dired
   
   ;; Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
   ;;   2009, 2010  Free Software Foundation, Inc.
   
   ;; Author: Colin Walters <walters@verbum.org>
   ;; Maintainer: John Paul Wallington <jpw@gnu.org>
   ;; Created: 8 Sep 2000

Steve Berman

Re: Differences between ibuffer and dired

[Deniz Dogan]

2010/7/1 Stephen Berman <stephen.berman@gmx.net>:
>   ;;; ibuffer.el --- operate on buffers like dired

All the more reason for these to eventually take place! :)

-- 
Deniz Dogan

RE: Differences between ibuffer and dired

[Drew Adams]

> > And remember that Dired is _much_ older - 
> 
> That's true:
>    ;;; dired.el
>    ;; Copyright (C) 1985...
> 
> > Ibuffer is only a few years old (~2007, IIUC).
> 
> But that isn't:
>    ;;; ibuffer.el    
>    ;; Copyright (C) 2000

I see.  That's why I wrote "IIUC".
Guess I could have checked the file headers.

But I did check Emacs releases 21.3.1 and 22.1 and saw that it first appears in
GNU Emacs with 22.1 (2007).  Anyway, thanks for the clarification.

RE: Differences between ibuffer and dired

[Drew Adams]

> >   ;;; ibuffer.el --- operate on buffers like dired
> 
> All the more reason for these to eventually take place! :)

And all the more reason to figure that the Ibuffer designers were conscious of
whatever differences (inconsistencies) they introduced.

Not a proof, of course.  But the fact that Dired was partly the inspiration
suggests that they were well aware of Dired's design, its UI, and its key
bindings.  Which suggests that in the cases where they choose different bindings
they might well have had good reasons.

But perhaps Colin or John will speak up and set things straight.

Re: Differences between ibuffer and dired

[Lennart Borgman]

On Thu, Jul 1, 2010 at 11:48 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >   ;;; ibuffer.el --- operate on buffers like dired
>>
>> All the more reason for these to eventually take place! :)
>
> And all the more reason to figure that the Ibuffer designers were conscious of
> whatever differences (inconsistencies) they introduced.
>
> Not a proof, of course.  But the fact that Dired was partly the inspiration
> suggests that they were well aware of Dired's design, its UI, and its key
> bindings.  Which suggests that in the cases where they choose different bindings
> they might well have had good reasons.
>
> But perhaps Colin or John will speak up and set things straight.

While we are looking at this: Wasn't there a discussion before about
putting ibuffer on C-x C-b? I don't remember, someone had something to
say about this. Was it Juri?

RE: Differences between ibuffer and dired

[Drew Adams]

> While we are looking at this:

You mean making some keys more consistent between ibuffer and dired? See Subject
line.

> Wasn't there a discussion before about putting ibuffer on C-x C-b?

?
No connection with the current subject.

> I don't remember, someone had something to
> say about this. Was it Juri?


1. Why?
2. Why would you bring that up here, in this discussion?

Re: Differences between ibuffer and dired

[Lennart Borgman]

On Fri, Jul 2, 2010 at 2:09 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> While we are looking at this:
>
> You mean making some keys more consistent between ibuffer and dired? See Subject
> line.
>
>> Wasn't there a discussion before about putting ibuffer on C-x C-b?
>
> ?
> No connection with the current subject.
>
>> I don't remember, someone had something to
>> say about this. Was it Juri?
>
>
> 1. Why?
> 2. Why would you bring that up here, in this discussion?


I think you want to say that for you it is easier to keep those
subjects separate. I can try to remember to respect that, but for me
it is easier to do it the way I did it here.

There are simply different thinking styles.

RE: Differences between ibuffer and dired

[Drew Adams]

> >> While we are looking at this:
> >
> > You mean making some keys more consistent between ibuffer 
> > and dired?  See Subject line.
> >
> >> Wasn't there a discussion before about putting ibuffer on C-x C-b?
> >
> > ? No connection with the current subject.
> >
> >> I don't remember, someone had something to
> >> say about this. Was it Juri?
> >
> > 1. Why?
> > 2. Why would you bring that up here, in this discussion?
> 
> I think you want to say that for you it is easier to keep those
> subjects separate. I can try to remember to respect that, but for me
> it is easier to do it the way I did it here.
> 
> There are simply different thinking styles.

_I_ think I want to say that you introduced a different subject.  And that
subject would be better discussed in a different thread.  This thread is about
"Differences between ibuffer and dired".  It is easier for _the list_ as a whole
"to keep those subjects separate".  It's not about me, what's easier for me, or
my thinking style.

That point I made is not about thinking styles.
It's about mailing-list organization and etiquette.

Use any thinking style you like.  FWIW, I appreciate your thinking style.  But
please try harder not to hijack threads (yes, we are all occasionally guilty of
that).

FYI - Today alone, you also injected a proposal to add a new menu-bar menu to
consolidate all minor-mode menus into a thread about possibly including
anything.el in Emacs.  No connection.  Except perhaps that something you read in
one of that thread's mails reminded you that you had proposed that menu before,
so you proposed it again.  It's OK to bring that up again, but please just use a
new thread.

This is a pattern, and IMHO it's not helpful.  Should we be reduced to having
just one thread for everything, entitled "poubelle", "catch-all", "X" or
"Lennart"?

Think about it, please.  Even in your thinking style you might realize that your
new topics will be better treated and easier to find later if you keep them
separate.  It's easy to do.  Copy as much of the original context that made you
think of the new topic as you want.  Just change the Subject line so we know
what the topic is.  Thx.

Re: Differences between ibuffer and dired

[Lennart Borgman]

On Fri, Jul 2, 2010 at 2:38 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> While we are looking at this:
>> >
>> > You mean making some keys more consistent between ibuffer
>> > and dired?  See Subject line.
>> >
>> >> Wasn't there a discussion before about putting ibuffer on C-x C-b?
>> >
>> > ? No connection with the current subject.
>> >
>> >> I don't remember, someone had something to
>> >> say about this. Was it Juri?
>> >
>> > 1. Why?
>> > 2. Why would you bring that up here, in this discussion?
>>
>> I think you want to say that for you it is easier to keep those
>> subjects separate. I can try to remember to respect that, but for me
>> it is easier to do it the way I did it here.
>>
>> There are simply different thinking styles.
>
> _I_ think I want to say that you introduced a different subject.  And that
> subject would be better discussed in a different thread.

Yes, I know that.

> That point I made is not about thinking styles.
> It's about mailing-list organization and etiquette.

I know that too, and I agree, but maybe we think differently about
what should be exceptions. (Some messages from you recently made me
think so.)

> Use any thinking style you like.  FWIW, I appreciate your thinking style.

Oh, thanks. All our thinking styles are needed. I am very glad we do
different things so we can try to sum it up to something better than
each of us can do alone. (It is not only about the amount of work we
put in.)

> But
> please try harder not to hijack threads (yes, we are all occasionally guilty of
> that).

I will try, but to me it seems most important to not hijack the thread
if things are complicated. But I know from here and daily
conversations that we are all very different when it comes to this.

> FYI - Today alone, you also injected a proposal to add a new menu-bar menu to
> consolidate all minor-mode menus into a thread about possibly including
> anything.el in Emacs.  No connection.

No connection for you. Yes. But for me it is a natural response to the
question where to put the menu.

Answering and proposing another way at the same time saves time in my
opinion. Or should I say in my thinking/conversation style.

But this style does not always work. All centrally involved in the
discussion must be prepared for it. Otherwise it is, as I think you
suggest, disorganizing.

> Except perhaps that something you read in
> one of that thread's mails reminded you that you had proposed that menu before,
> so you proposed it again.  It's OK to bring that up again, but please just use a
> new thread.

That would defeat the purpose here.

> This is a pattern, and IMHO it's not helpful.  Should we be reduced to having
> just one thread for everything, entitled "poubelle", "catch-all", "X" or
> "Lennart"?

I am not sure which name is best.

> Think about it, please.  Even in your thinking style you might realize that your
> new topics will be better treated and easier to find later if you keep them
> separate.

I think we mostly forget old threads. What I did try here was to link
things in a way that made both subjects more understandable.

> It's easy to do.  Copy as much of the original context that made you
> think of the new topic as you want.  Just change the Subject line so we know
> what the topic is.  Thx.

Yes, it is good to do, but this was such a small thing in my opinion.
I did not really want to start a discussion about my suggestion, just
mention it in context. (Discussion about menu related things tend to
lead nowhere and I believe it is partly because we are not prepared
for the discussion since menus has not been mentioned in contexts
where it could have been appropriate.)

Re: Differences between ibuffer and dired

[joakim]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > 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.

Thats why I suggested a separate branch.  All the changes could then be
tried in the branch withouth inconveniencing users.

In the end it would be neat with some skinning facility, and keymaps
could be part of that. I dont think you could please all users. The kind
of skin to use could then be chosen on install.

I also dont like the argument that a specific keymap should be kept
because its been like that forever. I've been using Emacs since 1988 and
I would still much prefer good consistent keymaps to inconsistent ones.

> 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.
>
-- 
Joakim Verona

RE: Differences between ibuffer and dired

[Drew Adams]

> > 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.
> 
> Thats why I suggested a separate branch.  All the changes 
> could then be tried in the branch withouth inconveniencing users.

"That's why"?  Telling people to simply try a new sack of changes is not the
same as "proposing and discussing each key change".

> I also dont like the argument that a specific keymap should be kept
> because its been like that forever. I've been using Emacs 
> since 1988 and I would still much prefer good consistent keymaps to 
> inconsistent ones.

Read what I said about consistency.  There are degrees and kinds of consistency,
and no degree or kind is the be-all and end-all.  The devil is in the details.

The argument about the age of Dired is not simply an argument that what is old
is good and should never be changed.  Read what I wrote, including the part
about consistency wrt what users are used to and wrt other, non-core, code.

Read the part about "other things being equal".  No one said that any keymap
"should be kept because it's been like that forever".  You are either not
reading well or being dishonest in representing what you've read.

_Reasons_ for each binding change, please.  Just why is this or that a good
change to make?  Pick a key that you think should be changed, and support it
with an _argument_.

You seem to be only reacting, in knee-jerk fashion.  Did you actually read what
I wrote?

> > 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.

Re: Differences between ibuffer and dired

[joakim]

"Drew Adams" <drew.adams@oracle.com> writes:

>> > 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.
>> 
>> Thats why I suggested a separate branch.  All the changes 
>> could then be tried in the branch withouth inconveniencing users.
>
> "That's why"?  Telling people to simply try a new sack of changes is not the
> same as "proposing and discussing each key change".
>
>> I also dont like the argument that a specific keymap should be kept
>> because its been like that forever. I've been using Emacs 
>> since 1988 and I would still much prefer good consistent keymaps to 
>> inconsistent ones.
>
> Read what I said about consistency.  There are degrees and kinds of consistency,
> and no degree or kind is the be-all and end-all.  The devil is in the details.
>
> The argument about the age of Dired is not simply an argument that what is old
> is good and should never be changed.  Read what I wrote, including the part
> about consistency wrt what users are used to and wrt other, non-core, code.
>
> Read the part about "other things being equal".  No one said that any keymap
> "should be kept because it's been like that forever".  You are either not
> reading well or being dishonest in representing what you've read.
>
> _Reasons_ for each binding change, please.  Just why is this or that a good
> change to make?  Pick a key that you think should be changed, and support it
> with an _argument_.
>
> You seem to be only reacting, in knee-jerk fashion.  Did you actually read what
> I wrote?

You seem offended by the way I wrote. Maybe clarifying what I tried to
express will help:

- The trunk will develop exactly like it always did, with healthy discussions
  for each change. 

- There could be a "skin" branch, or "theme", or whatever more
  apropriate name we come up with.

- In the skin branch, there could be a "consistency" skin that
  sacrifices compatibility for consistency. There is also a "emacs" skin
  which is the official skin derived from trunk.

- a "skin" might contain a number of settings, based on customize, such
  as keymaps for different modes, color themes, etc.

- The newly included package system will can be used to distribute
skins. 
  
The technical facilities are mostly already there. 

The "skin" facility will help to make it easier to adapt Emacs to
different hardware. I personaly would like
- a "tablet skin",
- a "chorded keyboard" skin,
- a "midi controler skin",
- a "swedish keyboard skin", etc...

At least I myself would find it very pleasing to come to a new computer,
download the Emacs suitable for that machine, do m-x set-skin jockeskin
RET, and have a number of for me pleasing settings downloaded and put in
place immediately, such as a consitent keymap, ido-mode, white text on
black background, and so on.

There, I think I said it much better this time. Do you agree?

>> > 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.
-- 
Joakim Verona

RE: Differences between ibuffer and dired

[Drew Adams]

> There, I think I said it much better this time. Do you agree?

Do I agree you said it much better this time? You said something different. You
said what you said clearly each time.

Do I agree with a suggestion to provide different downloadable versions/skins of
Emacs for people to experiment with?  I have no comment on it, other than to
repeat that such experimenting would be no substitute for discussion about
whether and how to actually change Emacs.  It seems that you agree about that:

> The trunk will develop exactly like it always did, with healthy
> discussions for each change.

That was my only point.  I thought this thread was leading to a discussion about
a proposed change.  My bad if not.  If your point was only about providing some
code for people to try then I have no special comment on it.

Whether you put experimental code for people to try on a GNU site or on Emacs
Wiki or some other place, I have no objection, personally.  It's fine for people
to try different prototypes etc.  It's not unusual for someone to post a link
here to code that people can try, to get an idea about some suggestion.  You can
go try Aquamacs, for instance, and see whether some aspects of its UI (or
whatever) inspire good ideas for adoption by Emacs.  But any such ideas should
still be discussed here in order to be adopted.

Whether experimental code to try out takes the form of a snippet, a library, an
entire Emacs source tree, or an Emacs executable for some platform, the general
idea is the same.

As for myself, I will not be downloading a source tree or branch and building
Emacs from C, whether to test a "real" pretest or to try out someone's idea of a
nifty new look and feel.  I might try loading a Lisp library or two to try
something that is being proposed and discussed, but I will not be building Emacs
to see whether I think your key bindings or whatever are a good idea.

Just speaking for myself about that, and I'm not typical in that respect.
Perhaps most people discussing here will build your skinned versions and play
with them.

Re: Differences between ibuffer and dired

[Juri Linkov]

> Thats why I suggested a separate branch.  All the changes could then be
> tried in the branch withouth inconveniencing users.

I think no separate branch is necessary.  You can write a set of functions
that defines a "theme" with keybindings and send it to the emacs-devel
or distribute with the help of the package system, so everyone could
easily try new keybindings.

> In the end it would be neat with some skinning facility, and keymaps
> could be part of that. I dont think you could please all users. The kind
> of skin to use could then be chosen on install.
>
> I also dont like the argument that a specific keymap should be kept
> because its been like that forever. I've been using Emacs since 1988 and
> I would still much prefer good consistent keymaps to inconsistent ones.

I agree.  I've been using Emacs since 1989 and I don't mind relearning
some keybindings for consistency.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Differences between ibuffer and dired

[Juri Linkov]

> While we are looking at this: Wasn't there a discussion before about
> putting ibuffer on C-x C-b? I don't remember, someone had something to
> say about this. Was it Juri?

Do you mean this thread?
http://thread.gmane.org/gmane.emacs.devel/91359/focus=91388

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Differences between ibuffer and dired

[Lennart Borgman]

On Fri, Jul 2, 2010 at 10:57 PM, Juri Linkov <juri@jurta.org> wrote:
>> While we are looking at this: Wasn't there a discussion before about
>> putting ibuffer on C-x C-b? I don't remember, someone had something to
>> say about this. Was it Juri?
>
> Do you mean this thread?
> http://thread.gmane.org/gmane.emacs.devel/91359/focus=91388


Yes, thanks. It was a very long thread. I think Stefan and others said
that ibuffer.el and buffer-menu.el should be merged.

Re: Differences between ibuffer and dired

[Stefan Monnier]

> In my opinion the modes are so similar in their use cases that users
> should expect the keybindings to be much more similar than they are
> today, at least for such basic things such as unmarking items. So why
> are there so many differences between them?

We should create a new parent major mode for such things which can then
be used by vc-dir, dired, ibuffer, gnus-summary, ...


        Stefan "Not volunteering"