[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: basic question: going back to dired

From: Evans Winner
Subject: Re: basic question: going back to dired
Date: Tue, 22 Jul 2008 10:13:19 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

"Juanma Barranquero" <address@hidden> writes:

    I'm not for or against changing Emacs' terminology. I
    think it would be a huge amount of work. But I don't
    understand why some people reacts as if the very idea is
    flawed. There's nothing sacred in "buffer" and
    "keybinding" and "minibuffer", just history. The change
    should be susceptible to rational (if perhaps a bit
    pointless) discussion, because it is not hard to find
    good arguments for it; "frame/window" vs "window/pane"
    is a good example.
The issue is not history or short-term convenience for new
users but precision.  Emacs does not use workspaces or
panes, but buffers.  A user who wants to write a little code
to do something useful needs to know that essentially the
same function that is used to open a file and write text in
it manually is what is used to create any buffer, even one
that never displays anything, has some processing go on in
it and then vanishes--that the display of data in a buffer
is a separate thing from the data structure itself; or why
some buffers are associated with files and others, like
completion buffers have no file associated with them, and
how to write programs that take advantage of the same

A person who has been told that he is working with
``windows'' (meaning buffers in Emacs) is thus conceptually
crippled if he wants to do something that could be done with
buffers other than using them as windows.  Xah Lee has
written about the danger of excessive use of jargon in
computer work and I generally agree with him, but even more
dangerous is the use of metaphor.  A metaphor, like
``workspace'' only tells you as much about a thing as the
inventor of the metaphor wanted you to know, but makes it
impossible to extend your understanding past that.

If the term keybinding ought to be changed to anything it
should be rather something like input-binding (since
function execution can be triggered by any form of input,
not just keyboard presses) than ``shortcut'' or whatever
such woozy nonsense.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]