Which is a crying shame.
I agree with the author: while the goal is noble, the implementation is terrible. Discussions and content are mixed up, for example look at the cscope page . Which is the latest and best package for integrating the tool?
It's 2012. Unix has had package management for decades. It's the age of app stores, why am I still downloading elisp files from a wiki? I want the equivalent of vimscripts! I want something better!
Emacs is an incredibly powerful tool, which has had many features decades before those newfangled IDEs. Unfortunately that also means that there's incredible inertia in the community. Here's hoping that the OP's article can trigger something.
It's, thankfully, been bundled in the default Emacs 24. And, thank the ghosts of the ancient lispers, that savagery of having a million-zillion different autocompletion interfaces for every damned thing may finally be put to an end with the new standardized autocompletion thingy.
The big problem may be that I tried to use el-get, based on some dangerously optimistic blog posts which turned out to be obsolete because the author of el-get changed the semantics of his commands slightly at some point in the last six months. (It is vitally important to read the very bottom of the el-get web page.) But it was nothing that I couldn't figure out in two hours of tinkering and reading el-get's source code. (Good luck, beginners!)
Then I still had various packages that needed to be manually deleted, or manually have their status reset. And then I'd randomly call various el-get functions, restart emacs, and wave rubber chickens until the packages magically installed. Which, amazingly, did finally happen.
My conclusion, though, is that emacs packaging is a waste of time for me and I'm sorry I tried using it. Emacs is not Ubuntu, where every package install spreads critical binary files all over your system, has an average of ten dependencies, and is compiled against specific versions of C shared libraries on specific architectures. In Ubuntu, your packaging system is a matter of life and death. But Emacs packages tend to have few dependencies, their assets are made mostly of text files full of nice universal Lisp source, said assets all live nicely together in one directory in the filesystem where they are easy to manage via a single personal Git repository, and they get updated much more rarely than, say, the typical Ruby gem. So for me the bottleneck in adopting an Emacs package is never the time required to locate its source code and type "wget" or "git clone"; it's the time required to figure out how it works, integrate it into my workflow, define keybindings for it in .emacs, et cetera. Packaging systems solve a problem that I don't really have.
If the packaging scripts were rock solid and I could trust that, having now spent hours setting them up, I'll be able to rely on them to reinstall or update packages automatically over the next five years, that would be one thing. But I have no such confidence. I'm legitimately afraid that I will spend more time shaving yaks in the packaging system than I would have spent manually locating and downloading the packages in the first place.
I know very little about Emacs in general, but what made you want to use el-get?
(It also includes emacswiki as a source, but tptacek has just reminded me that this is the world's scariest feature and I'm going to disable it posthaste.)
It also lets you declare all your packages in your setup file, and will install them from that declaration. That means you can stick your setup file on a brand-new machine, start emacs, and all your packages auto-install themselves and start working.
I've concluded, however, that I should have just done what you did. ;) Use package-install where it's handy, then commit everything that package-install pulls down to Git, along with any packages that I manually install from Github or other sources. (I could use Git submodules or subtree-merge for the latter… if I liked hairy complications.) This process is tedious, but it's conceptually simple, reliable, and results in a Git-controlled .emacs.d that I can just clone onto new machines so long as Github is up.
This is easy to do with package.el:
(defvar my-packages '(starter-kit scpaste paredit))
(dolist (p my-packages)
(when (not (package-installed-p p))
I think el-get made sense before community package sources like Marmalade and MELPA existed, but I don't see the point these days.
The original wiki has questions, back-and-forth-discussion and loosely structured content on many pages. Maybe some pages need to be maintained/wikified/deprecated, but the EmacsWiki itself is fine. Also, it was never intended to be the authoritative GNU Emacs wiki. GNU Emacs is self-documenting. The non-standard stuff needs the wiki more.
Sure, if you're extremely comfortable reading emacs lisp spread across many files.
Just like Spanish doesn't need a dictionary, since it's self-defining once you move to Spain, and spend three months learning it via the total immersion method.
That said, the other 2/3 of the time Emacs does relatively well at self-documenting.
(Actually, my friends told me.)
I have always been frustrated by "traditional" wikis that intersperse random bits of discussion with the article. No one really seems to know where to discuss something. The threading is horrible.
I am very glad that Wikipedia realized that you need to separate discussion about an article from a single, authoritative, neutral article. They are two very different needs, and trying to mix them into one just doesn't work.
And for things like c2, I'd consider the lack of threading an advantage. For lots of technical discussions, this leads to clarifications that are hidden somewhere deep in that thread pile and would require an editor to factor those out in the main article. Which works fine with something that has a huge user base or paid people to work on it (i.e. Wikipedia or corp "wikis"), but not for everything.
However, I don't think it is constructive to wish that EmacsWiki would die in order for something better to come up. We are all free to start another wiki, built on any cms we prefer, and if MediaWiki is your choice, go for it. Assemble your moderators, make it better than anything EmacsWiki has provided to date, and you'll be the darling of the Emacs community. That would be constructive. :)
Anyone can install mediawiki. Not many people will be able to put the time and effort that the emacswiki community has to keep a site going.
About the only part of the article that I agree with is that it's time to start moving code off the wiki. Though this isn't a "deadline" type problem, it should simply be discouraged going forward and packages of interest should start migrating.
Indeed. I smell some personal bias/agenda here.
You can not kill off an existing , actively used system (however crufty it may be) without a fully functional alternate in place.
On a more practical level, the post points out some flaws in EmacsWiki, asserts that some arbitrary alternatives would be better (MediaWiki vs. OddMuse), but does not propose a path to get there from here or explain how the switch would be worth the work.
Personally, I think it would be kind of neat to convert the EmacsWiki into OrgMode, push it to a Git repo and publish it the way Worg is published.
There are already other mechanisms in place to distribute Emacs code, like any of the Emacs package managers and Git, and yet EmacsWiki continues to be a place where code is collected and discussed.
I don't think moving to another wiki system would change that, since any other wiki system would have the same shortcomings as OddMuse in this respect. There is a straight trade-off between maintaining security on wiki pages and their utility. OddMuse does a good job, like all wikis, of keeping a page history that allows all edits to be audited. A new wiki might prevent editing of the code, or only allow editing by "verified" users, but that still provides no real improvement to security, since anyone can sign up and post code. Neither, incidentally, does a Git repository like GitHub or Gitorious; if you're unwilling to read and understand the code you download, you still have to put your faith in folks you don't know. Even if you do read and understand the code, you still can't be sure.
More importantly, however, is your implied assertion that security is a problem in practice. Have there been any cases where malicious code was posted on EmacsWiki? Did it cause harm?
I'm getting the feeling like "publicly editable code" is a manufactured issue to be divisive, but I could just be unaware of a security problem that has been pervading the Emacs community.
He's right; community code is a model that works on Github and absolutely does not work on an unauthenticated Wiki.
At least I'm pretty sure I don't have many emacs packages that originally came from a file on Emacswiki...
I'm still giving you an upvote because you bring up Worg.
Your writing isn't as polished as, say, Paul Graham's writing, but then very few people can write at that standard.
But please answer this question: how does using Github make you "less free"? All parts of Github (even parts of the web interface, like the wiki) can be used stand-alone. All your data can be easily dumped, most of them in a ready-to-reuse form (the git repositories, the wiki and github pages). So, from lock-in perspective, gitorious and github are quite alike. What exactly is it that makes you, as an individual, less free then using gitorious? Sure, the software is less free, but your data: not so much.
What does that mean? Github is not some function/feature that you support?
Yes. It's not difficult and means you can accept pull requests from both Mercurial and Git users.
I tried emacs for a week , gave up, went back to textmate, and have since switched to vim.
So you can grab all the emacswiki website (based on Oddmuse) and convert it to your favorite markup/wiki relying on a git repository.