Re: basic question: going back to dired

[Michael Ekstrand]

Xah <xahlee@gmail.com> writes:
> In this thread, i suggest that the term “buffer” could be changed to
> “tab”, “file”, “workspace” or something similar, and “keybinding” can
> be changed to “keyboard shortcut” in any context that's not about
> assiging a keyboard shortcut.

I should probably know better than to dip my oar in the water here, but
I think that the term "buffer" cannot and should not be changed to any
of "tab", "file", or "workspace", largely by virtue of the fact that it
is not equivalent to any of the above.

It is not a tab.  If you have "tabs" going in Emacs (which XEmacs seems
to support in some fashion), or are in some other editor with tabs, they
are equivalent Emacs' "windows", not buffers.  You could view the same
buffer in multiple tabs.  What then?

It is not a file.  Sure, many buffers are backed by files.  But a large
number of the buffers I use (SVN/CVS/HG status buffers, dired buffers,
Gnus mail summary/group list buffers, the buffer in which I'm writing
this e-mail if it weren't for the fact that I'm using nnml, so each
message is a file, and I could go on) are not directly corresponding to
files.  So to use the term "file" instead of "buffer" would also be
incorrect.  Think of Info buffers for another example -- one buffer
views, in turn, pieces of many different files.

Finally, it is not a workspace.  Etymologically, workspace is the most
viable alternative presented, but the term workspace as commonly used by
other editing systems does not apply.  In Eclipse, for example,
"workspace" is a collection of projects, views, and settings -- one
working context.  In my limited and dated experience with Visual Studio,
it uses the term similarly.  This would be somewhat equivalent to an
Emacs session, but definitely not a buffer.

A  "buffer" is  a useful  term  referring to  a text  chunk, or  perhaps
alternatively an entity manipulable via a window.  If we replace it with
any of the  suggested replacement terms, we have a  term which ceases to
accurately describe  the item referred to.   Yes, it's a  new term.  But
Emacs  is a  complex, technical  tool, and  expecting users  to  do some
learning  (even of  terminology) is  a reasonable  thing.  I  would also
argue  that introducing (and  defining!) a  new term  for a  new concept
facilitates better and easier  understanding of the editor than applying
a  familiar  term to  something  that  it  doesn't accurately  describe.

Remember as  well, though, that most  other editors don't  even have the
concept that Emacs  calls a "buffer" -- they let you  edit files in tabs
and/or  windows  ("frames")  possibly  collected into  workspaces.   Why
should we apply  one of their terms inaccurately to  a concept that they
don't even possess?

If we want to banter about confusing terminology, there are some
reasonable targets ("window" and "frame" vs. "pane" and "window", for
example), but even there, the costs involved in changing are
significant.

- Michael

-- 
mouse, n: A device for pointing at the xterm in which you want to type.