Re: basic question: going back to dired

[Xah]

Hi Michael,

I think your post is well thought out.

I don't totally agree though. Most terminology issues is simply a
habituation. If you look at arbitrary software apps and terms, and
think about it detail, there are all sort of illogicalities.

For example, what's a Tab? What's a mouse? What the heck is a Desktop,
Folder? Of course they all work by analogy, but superior technical
terms exists for them.
(e.g. Tab can be buffer, mouse should be pointing device, desktop
should be file manager, folder should be dir)

However, you don't see people complain about the term Tabs in FireFox,
or mouse, or Folder in Apple circles, or Desktop in Mac/Windows/KDE/
Gnome.

The term buffer works great, but again consider from a outsider's
point of view. Apple's Xcode, Microsoft's VisualStudio, Eclispse and
JavaBeans IDE for java. These are major IDEs for programing. They
don't use “buffer”. BUT THEY ARE BUFFERS!!

The point is not about logical quality in the term, but more about
standard terminologies and universal adoption.

I think, that emacs's manual, can benefit by replacing the term buffer
in most places.

All right, i don't want to push this point. Let's drop it then. How
about we focuse on Keybinding vs Keyboard shortcut? Perhaps that is
more easier to accept among emacsers.

There are quite a lot technically questionable terms in emacs too. For
example, kill-ring-save, kill-region, yank, kill-buffer.

Why kill? death? Wouldn't delete or remove be better in some technical
sense? kill-buffer can be close-buffer or remove-buffer. kill-ring-
save could be kill-ring-append, kill-ring-push, kill-ring-add. And why
kill-ring? It's not really circular as in The Lord Of The Ring, nor is
it like mathematician's algebraic structure “ring”. How about text-
depository or data-depository instead of kill-ring?
Wait, better is buffer for kill-ring. After all, as so many emacsers
insists here, buffer is rather the correct technical term as it is a
temp storage!

Also, note the sense of kill in kill-region and kill-buffer are
incompatible. kill-region pushes text, while kill-buffer doesn't. So
there, there is a inconsistency!! Egadz, emacs is trying to dumb me
down.

There's no ends when we start to exam the logicality of terminologies,
may it in be computer software, or scientific jargons. A major force
in the shaping of terminology is just historical happenstance.

So, changing some criticial user-level terms in emacs manual so that
they are more universally recoginzed, would be beneficial because it
fixes one of the problem people complaints about emacs learning curve.
Yet, choose changes that are easy to do and doesn't hurt emacs in ANY
WAY. This is why, i think for example, switching the term keybinding
to keyboard shortcut in emacs manual would be a improvement. (not for
example, in elisp manual, because lots of lisp functions are tied to
old terms, and programing is one level deep then using emacs. Programs
understands things like obsolete functions and baggage in the
language. Again, some says this creates inconsistency, but i don't
think so in practice. If we nitpick we always will find inconsistency.
Hell, in Perl and unix, there's almost nothing that is consistent.)

  Xah
∑ http://xahlee.org/

☄

On Jul 31, 5:28 am, Michael Ekstrand <mich...@elehack.net> wrote:
> Xah<xah...@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.