Re: basic question: going back to dired

[Tim X]

Evans Winner <thorne@timbral.net> writes:

> "Juanma Barranquero" <lekktu@gmail.com> 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
> functionality.
>

This is a critical point and an example of Xah's simplistic 'broad but
shallow' understanding that is all too common with much of what he
writes. 

The point he (and some others) miss is that 'buffer' is NOT the same as
workspace. As you point out, buffers are central to how emacs operates
and are not synonymous with a workspace. There are a number of
situations where any number of the suggested replacements would It hink
be more confusing than the current use of the term buffer. 

I have nothing against updating the terminology, but only if the new
terminology is able to have the same level of accuracy as the existing
one. To date, I've not seen any suggestions which would make things more
accurate and precise. On the contrary, most of the suggestions are less
precise and more likely to cause confusion. 

I also disagree with classifying emacs as just a text editor. If
anything, it is primarily a programmers editor. At least it is far more
powerful and better suited in that task than as a text editor for just
plain text (as in word processing). I know that it can do both very
well, but lets face it, the focus is primarily for the sorts of tasks
programmers are more likely to do. As such, I find the claim that its
terminology is too programmer centric to be rediculous. 

I would have to admit I don't really care if the non-programmer user
finds it difficult. There are plenty of other editors out there that
would probably be better suited to their needs anyway. In fact, I think
its only when you have an interest in programming and related activities
that you will really benefit from the extensibility of emacs. If your
just editing basic text and not interested in learning a little elisp in
order to customize things to your specific needs, your likely not to
appreciate the possibilities available and less likely to care. Worse
yet, you likely to find emacs confusing and lacking in the functionality
of other systems that are probably better suited to your needs. 

I don't get why some people, after discovering emacs, feel they need to
modify it so that the rest of the world gets converted to the church of
emacs. Likewise, I don't have an issue with anyone who believes that the
only true editor is VI or textmate, or Crisp or whatever. The wonderful
thing about this whole area is therre is a huge amount of choice. Far
more important than pointless debates regarding terminology is the
benefits that groups like the FSF have given us - not cheap/free
software, but the free an open sharing of knowledge and the necessary
technical infrastructure that can allow any of us with the desire and
drive to develop what we feel is the best/better system. With things
like the GPL, you don't even have to start from scratch. You can take
the sources and build/modify/extend them how you want. 

Instead, what we seem to be getting morer of are often ill conceived and
rather shallow philosophical rants about what is wrong rather than
anything of real substance. Xah produces miles of poorly expressed ideas
that are usually very shallow. Sometimes, there is some glimmer of
original thought buried in there and although rare, sometimes there are
some half decent ideas. However, his unwillingness to participate in
genuine debate and his frequent tactic of reverting to personal insult
whenever anyone disagrees with his point of view and his obvious
insecurity at being criticised means that the good ideas remain under
developed and never hit maturity. Much of what he has done that does
have some real beneficial content seems a bit misguided as well. for
example, he appears to have put a lot of effort into re-formatting the
Emacs on-line manual. However, such manuals are livinig artifacts and
need to be kept up-=to-date with the developments of emacs itself. While
I personally don't see what his version of the manual has that the
built-in version hasn't, I suspect that in the long-term, he will find
keeping it in sync and up-to-date too labor intensive and his on-line
version will just become another repository of out-of-date emacs
information that is likely to be morer misleading than helpful in the
long-term.


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

Yep, I personally don't find any of the suggested alternatives to
key-binding as clear and accurate. for example, 'short cut' only tells
you that a certain key combination is a shorthand version of entering
the command in the mini-buffer (or is that mini-workspace!). It doesn't
really reinforce the point that binding an action to a key can be used
for many things and is not just for creating convenient 'short
cuts'. For me, the term key binding means that I can bind actions to a
key and that those actions are not restricted to simple convenience
short-cuts. I can use the concept to create a whole new interface
paradigm that is only limited by my imagination. If on the other hand, I
had only been told that you can associate a short-cut to a key, while I
wold have found it simple and straight-forward, I probably would only
have used the facility to create convenience short-cuts for common
commands to cut down on my typing. I could easily have misse the subtle
difference and the idea that what I can actually do is really a lot
more.

Tim

 
-- 
tcross (at) rapttech dot com dot au