Re: Feeling lost without tabs

[Emanuel Berg]

Robert Thorpe <rt@robertthorpeconsulting.com> writes:

> As I said, three of the buffer menus mentioned are
> really the same: buffer-menu,
> buffer-menu-other-window and list-buffers.  One,
> electric-buffer-list is a keymap variant that depends
> on the other.  That's not really much repetition.

Again, I didn't examine the code so this is more a
discussion of principles. I'm happy people are active
with Emacs but from the little we have heard of the
differences between those tools, and the nature of
those tools (the task they set out to solve), it is my
impression this is optimally something that should be
kept at configuration-basis within a single tool.

> Personally, I like that they've kept the old ones
> around because I'm used to them, as I expect a lot of
> users are.

Of course, the old one, whichever that is, should be
kept, only extended, not forked, preferably. If it
were extended too much for oldtimers, it could be
extended even more, with an --oldtimer option so it
would look just the same, the upstart stuff brought out
of action and made invisible.

> That said, ibuffer is separate.  In other areas of
> Emacs this problem is worse.  For example there are
> four code-folding systems and they're all separate (a
> simple one in simple.el, hide-show-mode,
> outline-minor-mode and allout-mode).

Probably unavoidable for a project of this scale, but
in the case of the buffer lists, it seems like a case
where it could have been avoided, and probably more
easily than many other cases that aren't as
straightforward in purpose and presentation...

> I don't like the profliteration of different browsers
> and email systems either.

Here, I'm ambivalent. Personally I would never want to
do such a project because it would take years and it
would be very uncertain if it would ever reach a level
where people would use it. For all that time, it would
be almost embarrassing to use/develop it as there would
be so many better alternatives around.

Still, in but a few of all those projects, a level of
some humpty-dumpty parity with the other such software
is reached. In the Linux world for example Emacs and
vim, tmux and screen, zsh and bash, Firefox and Opera,
Perl and Python... At that point I say it's healthy to
have such competition.

So in the few cases when you end up with a solid piece
of software, I don't mind there are other such solid
pieces at all. Here, it is rather that those cases are
very few and it is a waste of time for all that don't
get that and are totally unrealistic in their efforts.

But to make a variant of the buffer list is as we have
seen not unrealistic, so for that situation, the
question is rather: were do I put my efforts do the
best use? Here, I don't think having many alternatives
are healthy competition, it is just fragmentation. (But
it is not a cardinal sin. I'm happy whenever people are
active.)

> I'm not going to complain too much though, because
> I'm not doing anything about it.  In lots of these
> cases it happene because the features started off as
> independently developed libraries and were added into
> Emacs later.

Yes, as long as it is great stuff I don't mind anything
being added.

> Sometimes having a set of different functions that do
> things slightly differently is the way that Emacs
> provides for customization.  To give another example,
> C-j will make a newline and indent the next line.
> There's a function called
> reindent-then-newline-and-indent which can be used
> instead by remapping it to C-j.

...what?

> I like that, I think using different colours is
> useful.

Yes, that's something I miss from the default Emacs,
from dired not the least. It should be put to extensive
use but not as amateur configuration. Gnus also looked
very boring at first but was (contrary to dired)
configurable as there are so many gnus- and message-
faces.

-- 
underground experts united