[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: basic question: going back to dired
From: |
Michael Ekstrand |
Subject: |
Re: basic question: going back to dired |
Date: |
Thu, 31 Jul 2008 07:28:09 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
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.
Re: basic question: going back to dired, Xah, 2008/07/22
Re: basic question: going back to dired, Xah, 2008/07/22
Message not available
Re: basic question: going back to dired, Miles Bader, 2008/07/22
Re: basic question: going back to dired, nakkaya, 2008/07/22
Re: basic question: going back to dired, Colin S. Miller, 2008/07/26
Re: basic question: going back to dired, Chris McMahan, 2008/07/31