Would it be safe to say that it is difficult to make a tool like Emacs suitable for mass adoption because there are so many advanced users who have invested a great deal of time in mastering it in its current form? The emacs-devel mailing list sees frequent debates about integrating Emacs into the conventions of the modern desktop (e.g., turning on cua-mode by default). But usually emacs conventions win out because so many seasoned Emacs users are used to C-w, C-y, etc. instead of copy and paste. In addition, Emacs users as a group take some pride (perhaps unwarranted) in using a tool whose conventions predate the modern desktop.
Would it be an exaggeration to Emacs is not an efficient tool unless one is willing to master the steep learning curve? But it is precisely the ability to customize Emacs in every respect--to mold it into whatever one wants--that makes it such a wonderful tool for power users. I would argue that gedit is a better editor for users who prefer GUI tools that work out of the box than Emacs could ever be. Emacs, by contrast, is a tool for users who want highly individualized (even eccentric) work-flows.
-- madalu
I think you present the conventional view, here. And largely, I don't disagree: emacs developers largely serve the needs of (and are themselves) the core users of the software. These users should be served by the software, and I think it's everyone's hope that all users of emacs eventually become "power users" of the software.
But there's no reason that emacs can't be usable by everyone. The
modifications are mostly minor: create a build-distribution function
that lets folks setup and configure emacs, and use that to dump a core
image and create an emacs system that other people can easily
install. That would, solve most of these issues.
I think the problem with saying that "emacs is only for people who want something that they can customize fully," is that I don't think people realize that this is something that they need or want. We're so used to editing technology that doesn't have these features that we don't know to ask for it.
While emacs (and vim too, let's be honest) are still light years ahead of everything else, there are a bunch of tools that aren't, effectively, that bad. Gmail does email pretty well. Eclipse/NetBeans are open source IDEs that people know pretty well. Things like Scrivener provides non-word processor structured writing tools. Piece by piece, the world is catching up. Emacs should continue to play ball too, that's all.
-- tychoish
Thanks for this thoughtful response. My experience of emacs is a bit different. If I were to choose an editor as an editor, I would choose vim. It is easier to learn and has a saner set of defaults. What keeps me with Emacs is elisp --- i.e., its usefulness as a fully programmable editor. In fact, I find emacs to be a fully programmable computing environment, in which I can use the same keyboard shortcuts and same scripting language for hacking at code, writing books and articles (via AUCTeX), reading email and news, chatting on irc, planning my day, etc.
Now vim folks will respond that vim has vim-script (and python and ruby extensions) or that elisp is an ancient, inadequate lisp. Which would not be false. But it is the ecosystem---the organic context in which elisp is embedded---that makes all the difference. For all its warts as a language, elisp has evolved to do one thing very well: to make every behavior of emacs malleable. Its singleness of purpose is what makes it so useful. Other languages may process text better; elisp, however, excels at allowing users to interact with plain text in every conceivable way.
So, for me, emacs would not be emacs without some knowledge of elisp. This is why I am not entirely convinced that an opaque, user-friendly distribution of emacs would be more useful than gedit or vim.
-- madalu
I mean to be fair, emacs is an editing paradigm (stackable control key navigation, modeline, M-x prompt, etc.) the emacs-lisp extensible is just an MIT AI lab/rms variant, that has happened to really catch on.
Elisp, is a fine language, as many programming languages are, but I think that it's strength in the context of emacs has less to do with the fact that the language has any particular capability and more that it's been used to write so much existing code. The fact that emacs itself is largely implemented in elisp along with, is really the selling point for emacs lisp and the drive to write more elisp code.
-- tychoish
Commenting on this wiki isn't all that intuitive, so forgive me if I'm doing it wrong...
Emacs, by contrast, is a tool for users who want highly individualized (even eccentric) work-flows.
I'm relatively new to Emacs (I'm a writer, not a programmer), so while it's a useful tool, it's also been a steep climb, much of which has to do with making sense of even simple customizations.
On my writer's blog I champion powerful text editors (notably Emacs) as the rightful heirs to paper-metaphor-based word processors in the online age. They're fast, automated (snippets, macros and a wad of other programming functions), and they don't clutter your text with troublesome codes or saddle you with proprietary file formats.
Since 90% of paid writing ends up online (I made that up), there are a lot of reasons for writers to use Emacs (project management, Org-Mode, Magit, language modes, keyboard shortcuts that keep your hands away from productivity-sapping arrow keys, syntax highlighting, etc).
Sadly, while it's powerful, making it dance is not easy, and it's far from useful right out of the box. Customization? I invested several hours just figuring out visual line wrap (v.23), and installing Identica.el mode chewed up two more. Buffers? Really?
I really like the suggestion of custom-built distributions; a writer-ready distribution offers at least a faint shot at converting writers--most of whom take one look at "Buffers" and "Enter debugger on error" menus and walk away.
Even better is how it might function in the "eccentric" workflow sense; Emacs could be the linchpin of a complete writer's system (compose in Markdown or ReStructuredText; manage versions with Git; fire copy right onto a blog; output .rtf files (for import into LibreOffice or MS Word when clients demand it or the situation warrants formatting); and use Latex to create formatted .pdf documents to print.
All this can be assembled now on a piecemeal basis, but not by mortal writers.
I'd suggest highly leveraged workflows--"individualized" to meet the needs of an entirely new class of Emacs users--might actually be the key to further Emacs adoption, not a reason to see it relegated solely to power users.
-- TC/Writer Underground
You're doing a great job at commenting on the wiki. This is the exactly right way to do it. Thanks for jumping in and offering this contribution.
The enevitable problem is that everyone has a different
strategy. Visual line mode is probably the way to go, but I'm a big
fan of auto-fill-mode (M-q twitch and all,) because it means that
git diff has more to chew through. There are probably a thousand
other little decision that could give rise to specific packages of
emacs, and that could be as confusing to potential users as anything.
Maybe what we need is ELPA+shell script that will install an emacs configuration. Doesn't work for Windows and it isn't very seamless (probably.) An idea, though, for a start.
-- tychoish
I think writers are--as a group--more homogeneous in their needs than programmers, and a "standard" writer's distribution could be created that would at least get folks off the ground.
I like your idea for an Emacs configuration install that would allow customization yet install easily; Kieran Healy offers an Emacs starter kit for sociology students, yet the directions for getting it running are not insubstantial.
I have to admit a couple writers have tumbled for my rants about text editors and asked me to point them towards an editor, and while Emacs is mentioned, something like Komodo Edit or Gedit (which needs a fair amount of hot-rodding to make it truly productive) are safer--yet still fairly versatile--bets.
In a less-specialized vein, I understand a package manager is in the works for v.24, which should ease customization. My own success rate adding new ".el" files is only 50% or so, despite being one of those people who reads directions.
Thanks for the chance to comment. I would like to see Emacs continue moving forward, especially as it offers the only realistic chance of becoming a truly all-around writer's platform (as a working writer, I write in 5-6 different editors over the course of the week, and I'd like to cut that number down a bit).
--TC/Writer Underground
Thought it sometimes earns me a little bit of ire, I'm pretty keen to suggest that TextMate for Mac is probably the second best text editing software around. It's very customizeable, powerful, and easy to extend, but not overwhelmingly confusing, and the transition from TextMate to emacs is pretty seamless. I really only use 2-3 text-editing interfaces (Word, Emacs, Outlook) and four if you count web-based editing forms. I'm curious about the kind of work you're doing that requires so much editing software.
I wouldn't necessarily assume that writers were homogeneous. Though there are probably fewer modes needed (LaTeX, OrgMode, Mardown, ReStructured Text,) there is no real lack of diversity in usage patterns and preferences. Not that I think we should avoid making an emacs distro, but that it's not going to be a simple matter
I'm totally willing to help you with your loading extra emacs lisp code issue, as I think I know what you're doing, and there are some really full proof ways of structuring your emacs configuration that would make this a less crucial issue.
ELPA (the package manager that's being included in v24) is a useful piece of infrastructure, but I don't think it solves this problem outright for a few technical issues. First, ELPA doesn't easily support multiple repositories in the way that most Linux distribution package managers do. Second, the default package repository only includes software with copyright assigned to the FSF, which is probably the right strategy, but given the first limitation is very limiting. So we could probably make something work, but it's not as straightforward as it could be.
Be in touch!
-- tychoish
I've heard good things about TextMate, but I'm a Linux guy, and if I had to pick an editor (for writers) that wasn't Emacs, it would be Komodo Edit, which is cross-platform and wholly customizable in a way that even a writer can understand.
Gedit's nice, but requires some hot-rodding to really boost productivity, and lacks the top-end editing commands that can really save your day.
In terms of homogeneity, my point is that most writers are used to a fairly standard CUA interface, and where it gets messy is on the output end. I think Emacs could serve as a brilliant editor for writers generating words primarily for online use (and perhaps simply formatted printed documents like manuscripts, scripts, etc), but most will keep their word processors for heavily formatted documents.
Of course, this is whole thread wasn't about just writers, and suggesting a heavily altered version of Emacs -- with much of the programming stuff hidden, built-in sign-up-and-save version control via Github, with LaTex installed and ready to go... it feels like a lot, especially when you consider the whole thing would have to offer a sizable improvement in functionality to even get a sniff from the writing world, most of whom are comfortable with the paper-based metaphor for writing.
Thanks for the chance to air out some of this stuff. Once of these days I'm going to create a screencast or two demonstrating the benefits of text editors for online writers (featuring Emacs); I think Emacs and Vim have never been so far from the mainstream, but given how words are being published nowadays, they've never been so badly needed either...
--TC/Writer Underground
I'm a Linux guy too, so it's a bit of contrived situation for me to be recommending TextMate, but even if it's been a long time since it was update, and even if it's OS X-only, it's been able to do something better than the others, and it has a community, and like the best software there's not a lot of functionality there except some open and plain interfaces for people to build the functionality they want ontop of an existing framework. It's a proven model for good software, and it's kind of shame that we don't see more of it. Anyway, to each their own.
I think it's generally a bad idea to build too much dependency on hosted services, particularly in free software projects (i.e. github.) I don't quite think that people should avoid using services, but I think it's bad form to tie services to something like github without an easy escape plan. Also, the commercial relationships we make for ourselves shouldn't be foisted upon other users without at least giving them options.
I'm interested in working on projects that help people write and work better. That was the original intention behind the cyborg institute project, at least. Anyway, if you need resources or want to collaborate on stuff, I'm game to contribute if not actually manage the project.
-- tychoish
I'm a weird mix in that I fiercely love Emacs, and see it as the single most influential tool in my productivity, but constantly find myself breaking things that cost me valuable time and create frustration.
For me, half of what I love about Emacs is what it doesn't do. It doesn't sit around indexing when I want to type. It doesn't (by default) look ahead and suggest what it thinks I want to type. It doesn't auto-complete things for me (forcing me to delete and fight with the auto-complete when I do something non-standard. It doesn't save my files in weird binary formats. Honestly most of the time I want something that just lets me type text really really quickly.
What makes emacs useful for me is that I'm always finding ways to have Emacs make me type and navigate faster. Things like M-/, yasnippets, bincremental search, rectangle editing, find-name-dired replaces, these are the things that make me faster than my NetBeans/TextMate/RubyMine/Vim compatriots. I've personally introduced about 10 people to emacs, but only maybe 4 of them have stuck with it.
I think for me, what made me stick with it was that I treated it as a game. I still don't really understand lisp. I can program in python, ruby, javascript, and even C and C++ to some extent, but there's something about lisp that doesn't click with me. Still, about once every week I go on a hunt to make Emacs do something that I want it to do.
I guess what I'm trying to say is that I'd like to make an Emacs game. The idea would be to distribute an emacs that has very very minimal keybindings and configuration. You have basic navigation, cut and yank, syntax highlighting and customizing colors. Then we make different classes for learning (writer, programmer, student, manager, accountant, etc.). Each one of the classes has a skill tree where they learn useful things and earn points for doing them. Maybe we distribute it with a set of fixtures that show how the emacs tools are useful.
I remember the thing that prevented me learning databases was not having data. Once you have data, SQL is a breeze to learn. Once you have a chunk of text that requires a macro to edit efficiently, macros become fun. Once you have a chunk of HTML that is all left flush, indent-region is impressively magical. As you gain new skills we make part of the game customizing the emacs.d directory, and they gradually learn about keybindings, settings, functions, etc,.
Maybe too extreme, but I think it would be fun.
-- Peter
Thanks for commenting Peter! I'm interested to learn how you learned about the site, and how I might find more about your work and your site. Perhaps consider making a folk page, or just dropping me an email garen@tychoish.com.
The overriding goal here is not to actually change the way emacs works, but to provide a framework to make the first 3-5 days of emacs usage better. There are a number of things about emacs that are just hard when you're new. The installation (potentially,) the lack of initial mode and configuration (fundamental mode, really?) and so much that I think everyone changes. Oh, and the font is universally bad. What's so hard about bundling Iconsolata?
I think phrasing emacs customization as a game is both an accurate characterization for many, and probably something that might make the process more understandable for the uninitiated. Having said that, I think would-be emacs users need to know that it's worth it and know where to start. Beyond that, we can assume that they're sold and then it becomes a game. Having said that, I think providing too much structure will for "the emacs development process" will only make things more confusing. Get people started, give them the tools and every chance to succeed, and then get back to work.
I really like the point that you need to be able to have a use for a tool before being able to effectively use that tool. The problem, perhaps with emacs is that they already have a need for a text editor, because most people do. So it's not something that they can walk into slowly (or would be prone to walking into slowly.) And really, while I think that people inevitably learn a little lisp by using emacs, I'm not sure that learning a lot of lisp is the right way to approach "learning emacs."
-- tychoish
I agree with sentiment of Tycho's point (2). I understand the need for the customize interface, helping novice users choose options from a menu, and even experienced ones who just want a quick change, but find it just plain user hostile. I often end up spending twice as long saying screw it, then reading the elisp docs and adding a few paragraphs of elisp instead of dealing with customize. I think part of it is the kludgey text based window/menu environment. Some suggestions for a friendlier replacement:
A simple question/answer menu driven perl/shell script that read/wrote the user's .emacs and .emacs.d files would be easier than what we have.
Like above but a question/answer mode inside emacs. No funny menu business, just answer questions.
I could also see a brand new full emacs widget implementation. This would probably be the nicest but would abandon text-only users.
Any ideas?
-- mitch
Thanks for commenting! Make a folk page, tell me how you found out about the site (Planet Emacsen, I presume?) and all that.
I always do the "C-h v" test and then insert a setq statement into a file in my config somewhere because that's so much easier. I think, probably, that customize is the best that it can be, while still keeping emacs "lisp from top to bottom." I think the initial installer or "distro-builder" would probably be best served by some sort of question and answer interface: e.g. "Do you want to build an installable emacs distribution?" "Do you want to dump your configuration into a script that others can install?" "Do you want to check all of your emacs lisp to ensure that it's distributable?"
I think the "emacs for beginners," package should probably stick to a lot of very well commented lisp files for configuration, which would give people the ability to create and customize their own files. Or at least a start!
-- tychoish
Just a quick note, but there is a good starter kit that a lot of programmers have found to be a good base for Emacs customization. It is aptly named Emacs Starter Kit, and does a good job of giving first-time users a head start on using Emacs efficiently.
-- PCMatz
I was vaguely familiar with this project when I wrote the post, but I don't think that I have seen it since it moved to github. Or maybe I saw a similar project a few years ago. In any case I like the idea, though the "all your emacs configuration" in weird org-babel files isn't exactly intuitive. I'm not sure, it's probably a good starting place to start.
-- tychoish
This puts me in mind of the Lazy Newb Pack for Dwarf Fortress. And maybe an initial starting point could follow similar lines. Make one distribution which includes most frequently used/most universally useful packages.
While I agree that one of the great strengths of Emacs is its customisability (which involves a certain learning curve), I still think a "starter Emacs" would be a great idea - to show people what Emacs can do and at the same time break the learning curve into smaller, more manageable increments (sort of like training wheels for a bicycle).
I stumbled upon Emacs by accident (my main work doesn't involve programming) probably about a year ago, and persisted in using it partly from sheer pigheadness. But I'm immensely glad that I did. In the end Emacs has saved me more time than its cost me, and in the long haul that will be exponentially true. At this point I can't imagine not using Emacs.
I would suppose there are other people like me for whom Emacs would be incredibly useful. But not all of those people may be as stubborn as I, especially in a world where people increasingly expect everything to work "out of the box" (or, at least to appear to work "out of the box", in the case of Windows, iPhone etc.). A preconfigured starter Emacs would be great for showing people the usefulness of Emacs. Once they're convinced of that, presumably they may well be willing to invest time in tweaking, configuring, and even learning bits of elisp. But before they know how useful Emacs might be, many people may be unwilling to invest the initial time commitment.
There are certain packages which I think may be incredibly useful for all/most users, like "undo-tree" (in that context - it would be great to compile a list of cool features of Emacs uncommon elsewhere, like the "undo-within-a-region" command...). Maybe "CUA-mode" - just for the visible rectangular selection (I still use standard Emacs keybindings). "Flyspell" for anyone using Emacs to edit natural language text. And of course "orgmode" allows for all sorts of cool things.
Binding "dynamic abbreviation expansion" (dabbrev-expand) to some reasonable keys is desirable too, I think.
About 80% of my Emacs usage involves AUCTeX, simply because Emacs+AUCTeX(/RefTeX/Outline-mode) really is by far and away the most powerful (La)TeX editing environment. Setting up (La)TeX of course involves its own set of complexities, especially since it's best used in conjunction with an output viewer. And setting up Emacs/AUCTeX to allow for forward and inverse search between input TeX and output (pdf, dvi etc.) has probably accounted for the majority of my "time lost" using Emacs. And this is additionally complicated given that it will vary from OS to OS (under Linux, Okular seems to be supported best, though some people have managed to get Evince to work too). So a TeX-centric distribution of Emacs would be complicated (though, I think, worthwhile).
More random musing: the shell script could involve options like "Do you want standard Emacs keybindings or CUA keybindings?"
-- BeSlayed
I think we're nearing the point where this discussion is better served by a number of pages rather than just the one. In any case, BeSlayed, stay a while and make a folk page for your self ;).
I'll say a couple of things things: I didn't know about undo-tree, but I read the emacswiki page about it and when I'm in the tinkering mood I'll surely start looking for it. After a while, I finally figured out how emacs' native undo works, and the truth is that not only do I no longer screw things up with impossible to undo chains of events, but I'm disappointed when other applications don't mimic emacs. If nothing else let this be an example of how everyone's default configuration is wildly different and how needs vary. And then there are things like CUA which will never ever ever be in any release of emacs.
I guess my hope isn't to coddle people or fundamentally change anything about the way emacs works or is developed. I just want to be able to tell people: "you want to learn emacs, here's a sane configuration/installation to get started, learn from it." There's room for a TeX centric emacs version and latex-system would depend on such a thing, but I haven't a clue where to start, and how to get that into an installer that wasn't utterly massive to download.
By in touch!
-- tychoish