Re: basic question: going back to dired

[Tim X]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On Thu, Jul 24, 2008 at 14:17, Tim X <timx@nospam.dev.null> wrote:
>
>
>> Is the
>> terminology so alien that one reading of the manual page wouldn't be
>> enough to explain it?
>
> Do you find difficult to use Windows (if you use it at all) because
> the directories are, from the desktop POV, called "folders"? I'd bet
> the answer is not, still you joked about because you think it is the
> wrong term.
>

Hehe. You see, I think you just proved my point. No, I have no problems
working with MS Windows, despite the fact they call directories
folders. The terminology is not hard to grasp. Likewise, Emacs' use of
the term frame or buffer or even key binding is not that hard to
grasp. Yes, it may be different to what new users have heard before, but
its not that different they won't be able to grasp it from a single read
of the manual pages or a quick run through the on-line tutorial. 


>> Agreed. So, what now? Do we have to try and cater for everyone? Do we
>> adopt terminology which may be proven wrong or which could likely become
>> outdated in the future anyway?
>
> As opposed to the terminology we use now, that has not become
> outdated, you mean?
>

has not become outdated yet!


to clarify and summarise my view on this ....

1. I would agree that emacs' terms in some contexts would seem alien to
new, particularly younger, users or users who have no real history with
computers. However, I don't agree this is necessarily an issue or even a
significant barrier to new users adopting emacs. In fact, I suspect
there are far more subtle conceptual shifts required that are not
related to terminology that are likely to be more difficult to grasp. 

2. Nobody has suggested changes which are not either a poor choice in
the sense that they lose some of the significant meaning of what the
object/action/function provides or are likely to increase confusion or
are likely to become outdated or out of vogue even faster.

3. Making such changes is not a trivial task despite what Xah argues. If
we only changed things at the interface level, users are going to get
confused when all the underlying lower-level functions that use the
existing terminology does'nt match. For example, we change the term
buffer to workspace - do we also change all the functions with the name
buffer in them to have the term workspace? If we don't, how confused are
these new users going to become when they go to start customizing their
system. If we do change them, what happens to the thousands of lines of
elisp out there that now won't work. For example, I have elisp code from
the early 90s that still works perfectly. 

4. If we start down the route of trying to keep emacs in synch with
modern terminology, where will it end? How far away is the next round of
trendy new terms? 

5. I'm still not convinced that emacs terminology is a barrier to
adoption. I suspect that many of the features found in modern IDEs that
are missing from emacs are actually a much bigger barrier to adoption -
for example, *smart* dynamic completion or fontification based on
semantics rather than syntax or improved font handling and antialiasing
or updating of modes that handle mail, web, etc to support evolving
technology better i.e. javascript support, extended interfaces better
able to handle working with "the cloud" etc. Work by the current
developers with respect to fonts and character sets are addressinig many
of these short-falls. Likewise, work by the CEDET team are addressing
others and work by people like T.V. Ramon in providinig interfaces to
Google apps are addressing others. This sort of work is going to
increase desire/motivation and I suspect will overcome any initial
difficulties with unfamiliar terms. 

6. It is important to recognise that despite the fact we find emacs
great, there are many out there who never will, regardless of the
terminology. Many people disagree with the whole philosophy of emacs -
they argue it is trying to be too much, is too much like an OS in itself
and it should just concentrate on being an editor. Some feel its overly
complex for what they want and some just don't want to put the effort
into learning. Choice of editor is a personal thing and the variation in
what people want is huge. Emacs already has a very active user base and
is used by a large number of users. It will never be the most popular
editor, but for those who like it, it can often become almost a
religion. For those people, I suspect either they like/accept the
terminology and have no issue with it or are willing to accept that this
is just the way it is. For those who cannot accept things like the key
bindings or the fact some functionality isn't there, if it is annoying
enough, will either customize the system to suit their needs or will
switch to something else they find less annoying. 

To me, a lot of the arguments about terminology are a bit like people
who meet someone they fall in love with and then start trying to change
them to something else. All to often, this just ends in tears. Either
they succeed in makinig the changes and then realise what they have is
different to what originally attracted them or the person they are
trying to change ends up no longer liking them either because they don't
want to change or as a result of the change, now want something
different. 

Perhaps a good middle ground to addressing the terminology issue could
be as simple as adding or updating documentation that explains the terms
better or with reference to what some would consider more modern
terminology in a very brief manner. All the terms are already adequately
explained in the on-liine documentation, but maybe the explinations are
too long for some peole who just want to start usiing emacs without
reading the manual. A brief page relating emacs terms to current
terminology may suffice and would be easy to maintain as terms evolve
over time. 

Tim

 
-- 
tcross (at) rapttech dot com dot au