Die EmacsWiki, Die

I tried setting up package.el in Emacs 24 last week. "Shaky" is the word.

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.

And Wikipedia, with its talk pages separated but attached to its articles, was the first wiki that made me think "huh, maybe this Wiki thing is actually a good idea."

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.

I was going to counter this with "that's what 'M-x apropox <thing>' is for", then I remembered that around a third of the time that's the lead in to me diving into the source.

That said, the other 2/3 of the time Emacs does relatively well at self-documenting.

Self-documenting or not, I think the point stands, the standard stuff is very well documented via many means (a nice tutorial, a very comprehensive manual, an emacs lisp tutorial and an emacs lisp reference all ship with Emacs in addition to things like describe-function, describe-key, describe-variable etc.), so the role of the Wiki is to supplement those and not replace them.

Well, there goes my relaxing afternoon. ;)

At least I'm pretty sure I don't have many emacs packages that originally came from a file on Emacswiki...

I agree that unsecured editing of code is a problem, and I did not mean to imply otherwise. I recommend reading "On Trusting Trust" if you're interested in such issues.

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.

It certainly wasn't meant to be a low blow...I apologize if it came off that way. I meant it as part of a larger argument to support my impression that the post was not well thought out.

I wouldn't have called it poor English! I wouldn't have guessed from the text that you aren't a native English speaker - I had to check your About page to be sure.

Your writing isn't as polished as, say, Paul Graham's writing, but then very few people can write at that standard.

"wise to support github"?

What does that mean? Github is not some function/feature that you support?