Re: basic question: going back to dired

[Xah]

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

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

• Note that in commercial orgs, major change that's a few order of
magnitude more difficult has done in response to the changing
industry. A good example is Apple computer, in its Motorola chip to
PPC in ~1995, Mac OS 9 to OSX in ~2001, and PPC to Intel chip in
~2006. (in the first couple of years of these changes, there are huge
resistance from mac communities, organized “Open Letters” opposition
sites to apple, huge number of online complaints, criticisms from Mac
magazines etc.)

• note that emacs's user base has eroded from perhaps more than 50%
market share among all editors/IDEs, to today maybe 10%, or perhaps
even less than 1% among all professional programers. (professional
programer here is defined as those who makes a living by coding; which
what we might call “inexperienced” programers such as those coding in
HTML/CSS, PHP, the millions of game scripters, CAD scripters and other
niches, scientists and engineers who write code as part of their work.
It's a bit hard to define but i think these people may actually be
more than 50% of professional programers. Most of these people, if
they post to newsgroup (if they knew what's a newsgroup at all), would
probably be flamed to death.)

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

The Close command doesn't have a default shortuct. In practice, i
think it induced a 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

(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)

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

  Xah
∑ http://xahlee.org/

☄