From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: basic question: going back to dired Date: Sat, 26 Jul 2008 11:59:14 +1000 Organization: Rapt Technologies Message-ID: <87ljzpqubx.fsf@lion.rapttech.com.au> References: <4884DC7F.6060406@gmail.com> <87mykaw8sb.fsf@nonospaz.fatphil.org> <87myk828zm.fsf@lion.rapttech.com.au> <873alz1no7.fsf@lion.rapttech.com.au> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217040087 22046 80.91.229.12 (26 Jul 2008 02:41:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 26 Jul 2008 02:41:27 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Jul 26 04:42:16 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KMZjb-0001JR-7B for geh-help-gnu-emacs@m.gmane.org; Sat, 26 Jul 2008 04:42:15 +0200 Original-Received: from localhost ([127.0.0.1]:57555 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KMZih-0000E5-F6 for geh-help-gnu-emacs@m.gmane.org; Fri, 25 Jul 2008 22:41:19 -0400 Original-Path: news.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!news.astraweb.com!border1.newsrouter.astraweb.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) Cancel-Lock: sha1:+cWJzTZyA5tS6tNZ8S83oOkSawg= Original-Lines: 120 Original-NNTP-Posting-Host: 01b075fe.news.astraweb.com Original-X-Trace: DXC=N4UhilIJ>Hc:PIc[8_6SKeL?0kYOcDh@jIGb]mONgOij^FQoa5AIR:cRTFYYW29Y\j06ZiLRIO9Ia Original-Xref: news.stanford.edu gnu.emacs.help:160597 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:55944 Archived-At: "Juanma Barranquero" writes: > On Thu, Jul 24, 2008 at 14:17, Tim X 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