Emacs And Normal People
Emacs And Normal PeopleEmacsEditor is a wonderful program for programmers, but what about NormalPeople? I like the idea of teaching people to using TextEditors instead of WordProcessors and other specialized editors, but undeniably, emacs is too hard for normal people to use, and that isn't likely to change.
Funny you should pick emacs as an editor especially for programmers. In my work, normal people use UnixOs for much everything and I think emacs is one of the most normal people oriented programs around. Unless you count recent "slick" projects like KDE (KayDesktopEnvironment) editors etc.
I think it's time for a new editor. What might such an editor have? (contribute here everyone please) <trollmode>[Note: CodeWright is the answer]</trollmode>
Most of the tasks above would be better served with dedicated applications (possibly sharing common functionality through common classes). You're never going to please all the world with one editor; the best you can do is to please half the world, and then you have Emacs ;-). Rather:
I think if you look at how tightly all the various "applications" which run under emacs interoperate, at a level far more intimate than the clunky pipes of unix, you might revise that opinion and wonder if Unix hasn't learned anything from emacs (or the LispMachine environments). VM/W3/GNUS/Dired/ange-ftp/etc etc all play with each other much more friendly than awk/grep/sed/pipes/bin/sh. (See UnixShellPatterns.)
Given MicrosoftWord, WebBrowsers/mail clients/news readers/stock quoters/auction viewers, the popularity of, say, VimTextEditor, the gradual expansion in shell capabilities and the general tendency toward do-everything software, I would have to say "no". It may be that these big monolithic applications have real advantages.
The examples given for that kind of distributed software is usually the Unix CommandLine; one might also propose the AcmeProgrammingEnvironment. Unix heavily promotes tool creation, makes the new tools work just like everything else, and is sharply limited--the shell thinks everything is at best loosely formatted text. Acme is no different. When I wanted to write a grep that was restricted to certain columns of a CommaSeparatedValues file, I had to write my own in CeeLanguage.
Now, if we look at Emacs, we find something interesting. The smarts required to take typical nroff output (which uses backspace characters to simulate bold and underlining) get rewritten a lot--col is the standard utility, but it just strips the codes out. You can't grep the raw output; the formatting codes are sequenced in with the text. The code to translate these into terminal sequences for bold and underline and whatnot is in among other things less. Emacs has a function to do this: Man-fontify-manpage. It is, as the name suggests, most appropriate for viewing man pages, but it served perfectly when I wanted to take my nroff output and make it look sane. Further, I can search through the formatted output, call up a dictionary on bold-faced words, and do various other things and it all just works. Partly this is because Emacs has a much saner model of text than the Unix pipeline, but that I could just grab that function and use it is a real benefit of the environment.
This is only one data point, but I found it illustrative because nroff-view-as-text didn't exist in my Emacs until I wrote it, and I wouldn't have even attempted to get the fonts right if Man-fontify-manpage didn't exist already. It may be that environments integrated on the level that Emacs is are the way to go, in the end.
-- GrahamHughes
As a practical matter, I don't see how you can "make it easy for programmers to use what ever language they like for programming it".
First, Emacs is largely written in LispLanguage, and so EmacsLisp ties together customized modules with the basic Emacs code. If you want to make an editor that can be programmed in any language, and I want to write some customization module in Lisp, while you want to write a module in CeePlusPlus that calls some function in my module, how will the two interoperate? You'll end up with one of the following: (a) one language that is, for all practical purposes, the privileged language for extending the editor, in the way that CeeLanguage is the privileged language for UnixOs; (b) a nightmarish confusion of cross-language calling conventions; (c) every module restricted to using a lowest-common-denominator subset of its language when calling external functions.
Second, if you have minimal programming skill and you want to write extensions to Emacs, your main challenges will be understanding how Emacs "views the world" (e.g., what "mark" and "point" are, and which DataStructures and functions within Emacs allow you to manipulate them), and then deciding how to map this view onto the task you want to accomplish. Compared with these challenges, the challenge of learning Lisp syntax (and such cryptic primitives as "car" and "cdr") is trivial. Giving the programmer a choice of extension languages will deal with the trivial challenge without touching the big ones. -- SethGordon
(See... You just need to use MicroSoft's DotNet architecture: DotNet has a common runtime, and all languages are interoperable. Use ActiveX scripting for access to all available scripting languages. ;-)
First, this isn't about updating emacs, but rather replacing it with something that not only programmers would like, but that normal people would like also.
I know what you mean about learning lisp. I already knew a fair share of lisp, but I have a terrible time trying to update emacs to work the way I want.
Anyway, accomplish the above goals, a more comprehensive API than what emacs provides would be needed. See that ObjectOriented API is on the list. Hopefully that would help clean up confusion as to how things work, and what relates to what at least a little. I agree that changing languages doesn't solve everything, but it would be nice.
Perhaps someone could say something about why "NormalPeople" need something like emacs. I'm not saying they don't, but I'm not clear on why they do either.
First, this isn't about updating emacs, but rather replacing it with something that not only programmers would like, but that normal people would like also.
The two sets of people have markedly different psychologies and radically different needs. I think it would be a mistake to try to make one tool to fit both types of brain.
Normal users keep expecting us to be experts at their damn tools to help them.
"Help me with Word!" "I'm sorry, I haven't used Word in over a year because I do my word processing in Emacs." "What the hell is Emacs, and I thought you were supposed to be good with computers?"
Is it too much to ask that their tools be good enough for us to use so that we will actually have a reason to be familiar with them?
And are they really that different anyway? Anyone who knows the PicoEditor is OK in emacs with the help of a cheat sheet at first, and anyone who can use NotePad can figure out how to use pico. And Notepad is actually easier than MicrosoftWord. That said, the average user can't seem to wrap their brains around typing \emp{} in their documents. Hence the need for a rich text option. We don't want users to have WYSIWYG (WhatYouSeeIsWhatYouGet) though, since that leads to ugly documents. And we do want strongly enforced styles that can be hotkey between.
Is that what users want, or what we wish they wanted? From what I've seen, users want exactly the "ugly" documents they're making.
Depends who you mean by "users". I suspect that most institutions end up requiring the use of the company stylesheet or whatever, at least for stuff circulated externally (I know we do). For personal use, of course people want the freedom to personalise their documents, and since mainstream use of computers is now entirely fixated upon presentation rather than content, that means picking their own fonts and colours, even though it looks awful.
Emacs is a good tool for writing new editors in. You don't have to present all of Emacs to a user. You can just present a tiny editor, or a tiny editor and a simple mail and news reader. (Except the executable will be big! Room to grow. Or maybe you just want to do prototypes in Emacs.)
Emacs provides facilities to do everything you are asking for, except you have to do it in Lisp. However, Lisp is powerful enough to write an interpreter for another language. Therefore: write an interpreter for a "normal"-user-friendly language (let's call it EBasic for arguments sake) in elisp (EmacsLisp), allow EBasic to make calls to elisp functions, and only expose "normal" users to EBasic.
Sounds like quite a challenge - writing a basic interpreter in Lisp without deciding to abandon BASIC in favour of Lisp in the process.. :-)
Hehe... I was being somewhat ironic. However, it's probably a lot easier than attempting to rewrite Emacs without deciding to abandon the task in the process in favour of Emacs!
For those of you interested in extending Emacs without using EmacsLisp, PerlLanguage is now an option. -- JohnBeppu
I don't know a whole lot about Emacs::EPL, though. I'm normally a VimTextEditor user who happens to really like perl.
Same for PythonLanguage with PyMacs?. I wish someone would write HaMacs? for HaskellLanguage. -- ShaeErisson
The EmacsWiki has a page devoted to alternative extension languages for Emacs (http://www.emacswiki.org/cgi-bin/wiki.pl?CategoryExtensionLanguage). Also see EmacsInFooLanguage.
EditText of this page
(last edited August 11, 2006)
or FindPage with title or text search