Re: basic question: going back to dired

[Alan Mackenzie <acm@muc.de>]

Hi, ???Xah!

On Tue, Jul 22, 2008 at 01:44:27PM -0700, Xah wrote:
> Hi all, instead of responding to each message in this thread, i
> thought i just write one post.

> ??? among the alternative terms for buffer: tabs, panel, window, work
> space..., i think tabs is a good candidate.

I think you mean "tab", the singular.  Why is "???tab" good.  Look up the
word in a dictionary, and you'll find it's a bit of material or paper
which sticks out so that you can hold of it easily.  Or it can mean a
cigarette.  Do we really want to be manipulating sticky-out bits or
cigarettes?

"Buffer" means something which separates and smoothes interactions
between things which would otherwise damage eachother; for example, the
spring loaded pads on railway waggons which stop them jossling eachother
too badly, or the "buffer zone" between two hostile countries which stop
them killing eachother too much.  In Emacs, a buffer stops your changes
being written directly onto hard disk sectors, so the name isn't too bad.

> Originally i was thinking where emacs used the term ???buffer??? in its
> manual, it could be replaced by one of the term above depending on
> context.

??? So you'd have several names for one thing ???.  I don't think that'd
be helpful.

> But i think ???tabs??? would work for most. This can be coupled with
> incorporating the tabbar mode into emacs by default. (done last month
> in Aquamacs)

Ah right.  You want to introduce arcane terminology so as to spread your
idea of user interaces.  For what its worth, lots of people don't use
tabbars (rows of sticky out bits) and don't want to.  So the name would
be silly.

> ??? It doesn't take much work to make these changes. For the ones i
> suggested in the modernization article, it would take just one single
> elisp programer few hours to make all the suggested changes.

Hahahaha!!!!  Xah, it would would take hundreds of hours.

> Consider all the little problems here and there that might turn up when
> actually working into a final product, it might be a total of say, a
> week's work.

Not forgetting, of course, that Emacs wouldn't work afterwards.  You'd
have to add compatibility features by the hundred.  Otherwise, people's
elisp would stop working.  How many elisp libraries are there which don't
use variables/functions such as `current-buffer' or
`mode-line-buffer-identification', or ..... ?

[ .... ]

> ??? Emacs has kill-buffer, which asks users a buffer to kill, with a
> default suggestion for the current buffer. The Close menu command runs
> kill-this-buffer, which is what Close menu command is for in almost
> every application in Mac, Windows, Linux. The kill-this-buffer command
> closes the current buffer without asking (unless it is not saved, of
> course). The kill-this-buffer does not have a shortcut by default.

You mean a key binding, of course.  Except that it's bound to a menu item
in GUI systems.

The thing about the word "shortcut" is that it typically carries
disparaging overtones.  Also a "shortcut" is _never_ the canonical way to
do something.  Both of these facts make the term unsuitable for Emacs.

> The Close command doesn't have a default shortcut. In practice, i
> think it induced an operation habit to have hundreds of past buffers
> left open. The problem with leaving buffers is that it makes buffer
> listing/switching facilities much less useful. This is rather common
> complaint even among emacs old timers

Well, I'm not sure it is, but even so, anybody can customize their Emacs
if they find C-x k <ret> too tedious, as you have done.  I find C-x o too
tedious, so I've bound f12 to `other-buffer'.  What you've described is
your own problem, and how you've fixed it.  This it what Emacs's is all
about.  I had a problem moving easily between frames, so I've set up f1,
f2, ...., f11 to do frame-switching.  I don't have a problem with lots of
buffers being open.

> (i myself, being somewhat a classic nerd, adopted wholly emacs's ways
> and terms in the very beginning, using emacs in pure text terminal
> only for the first 5 years. However, i do have a habit to always close
> buffers once i've finished working with it. So, i always did C-k
> Return and find it too many keystrokes. Only in recent years of elisp
> study i had workaround with somewhat extensive self-made
> customization)

That's fine!  I do C-k <ret> seldom enough that having kill-buffer on a
single key would be a waste of a good key binding for me.

> ??? i do wish to keep gun.emacs.help to be very focused on technical Q&A
> and avoid opinions oriented discussions. I enjoy reading
> gnu.emacs.help that way, and i think comp.emacs can be more open to
> discussions and opinion oriented posts. What made me reply here was
> that posts that seems to want to emphasize the emacs ways as better
> way, which in my opinion, prevents the modernization of emacs.

??? I think you've got that the wrong way round.  Emacs strives to do
things the best way, not the most modern way.  "Modern" ways of doing
things are often far from optimal.  Also Emacs emphasises ease of use
over ease of learning, unlike many other products.  ???

>   Xah

-- 
Alan Mackenzie (Nuremberg, Germany).