Re: basic question: going back to dired

[Nikolaj Schumacher]

Xah <xahlee@gmail.com> wrote:

> However, i'm thinking
> that some terms used in emacs can use improvement by adapting more
> modern terms that has for one reason or another become standard among
> Windows, Mac, Linux, which together accounts for perhaps 99% of
> computer use.

I think many here actually agree.  It would be nice if windows and
frames were named the other way around.  Unfortunately they aren't.
What most people are refuting is the cost and benefit you claim.

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

Tab makes only sense when you have a tab bar.
File is misleading, because there are many non-file buffers.
Workspace is a bad metaphor, because it implies a whole, not not parts.
I have one workspace at home, not a desk full of workspaces.

Buffer might not be the most intuitive term, but its the only one I know
that makes sense.  Maybe sheet would be appropriate, but I think that's
ambiguous, as well.

> If we adapt the term keyboard shortcut instead of keybinding, it will
> reduce one learning step. As for “assigning a keyboard shortcut”, the
> act is more programing oriented or for advanced users, so i think
> “creating a keybinding” or “bind a key” is still appropriate in emacs
> and elisp doc.
>
> The point is about reducing learning steps by using terms that most
> people already understand.
>
> Today, “keyboard shortcut” for good or bad has become the dominant,
> universally understood term. Adopting it wouldn't hurt emacs's power
> in anyway, nor i think cause any confusion.

I disagree that shortcut is the only term all people will understand.
Keybinding is quite frequently used outside of Emacs.  Even Microsoft
uses it occasionally[1].  I can't imagine anyone reading the word and not
knowing what it means out of context.  Some editors (e.g. Eclipse) don't
give it a name at all, they just say "keys" and give a list of bindings.
If people are smart enough to figure that out, keybinding should be even
easier.

If they can't find how to configure their keys (I believe I had the same
problem), it's because there is no place to do it.  You have to find out
what command (global-set-key) to use, where to put it (.emacs) and what
notation to use.  That's a much bigger hurdle.
(Although it teaches you quite a bit, as well.)

Either way, I think complete standardization is not necessary in
software.  Firefox uses File -> Quit, Eclipse uses File -> Exit.  Both
do their job and both are understandable.  I don't know which one is
dominant, because it doesn't matter.

> About the term “buffer”, it's more complex to explain. We can look at
> it in another way. Almost all other text editing and IDE apps, they
> don't use that term. MS VisualStudio, Apple's XCode, BBEdit, Eclipse,
> TextMate, Microsoft Word...
>
> If you look at these software, actually they are buffer too. How can
> they not be buffers? However, they don't use that term, because the
> term really is more forceful if you think of the app in terms of
> implementation.

If they don't use that term, maybe it's because they don't have the
concept.  Looking at Eclipse, I don't see a way to create an empty
"buffer", or to open a non-file buffer in the editing window.  I think
this "unified" representation of things is quite unique to Emacs.

> copy/cut/ paste is kill-ring-save/kill-region/yank (huh??) etc.

Kill and yank are outdated terms, I agree.  But they actually helped me
remember the keybindings.  That's worth something, too.

> If you look at detail, one may argue some are more technically
> correct. But the point is that for whatever reasons, certain choice of
> terms becomes the dominant, standard, ones. English itself and its
> lexicon are largely inconsistent and down right weird.

Exactly.  But that's no reason to go through all books and replace the
obscure terms with the dominant ones so that they're easier to read. :)

> What's the logic in double negatives like “I aint't no gonna do it”?

The logic behind a double negative is that it becomes a positive.  That
logic doesn't apply to this sentence, because it isn't English. :)


regards,
Nikolaj Schumacher

[1]: 
http://www.microsoft.com/downloads/details.aspx?familyid=e5f902a8-5bb5-4cc6-907e-472809749973&displaylang=en