

Die EmacsWiki, Die - bozhidar
http://batsov.com/articles/2012/03/20/die-emacswiki/

======
AceJohnny2
I've started using Emacs a few years ago (we have a youngun' here!), and
EmacsWiki is the best concentrated source of information around Emacs.

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 [1]. 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.

[1] <http://emacswiki.org/emacs/CScopeAndEmacs>

~~~
whateverer
To be fair, Emacs has had a package manager package, package.el (heh), for
quite some time now. It can download and install packages from a repository,
like Marmalade, though I've found it to be a bit shaky in the past; I've had
to manually delete the files of a botched package, and then who-knows-what to
get it to fully disappear.

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.

Source: <http://batsov.com/articles/2011/08/19/a-peek-at-emacs24/>

~~~
mechanical_fish
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.

~~~
weavejester
I have had no problems whatsoever with packages in Emacs 24. I installed Emacs
24 via brew, used "package-install" to grab the packages I wanted, and that
was it.

I know very little about Emacs in general, but what made you want to use el-
get?

~~~
mechanical_fish
el-get can install packages from non-ELPA sources, the most important of which
is Github.

(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.

~~~
technomancy
> 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.

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)) (package-install
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.

------
rincewind
> _The articles are littered with crappy advice confusing beginners, have
> little structure and are filled with ridiculous questions (questions in an
> wiki???)_

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.

~~~
pavel_lishin
> GNU Emacs is self-documenting.

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.

~~~
stiff
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.

~~~
pavel_lishin
The catch-22 is that I had no idea that any of those things existed until I
checked the wiki.

(Actually, my friends told me.)

~~~
__david__
Really? The splash screen (literally the first thing that appears when you
first run Emacs) has links to 3 key pieces of documentation: 2 tutorials and
the reference manual, which is surprisingly comprehensive. It would be really
hard for them to be more upfront about the documentation.

------
kinleyd
Having experienced it myself, I tend to agree with the general point that
getting started with Emacs is not helped by the online resources available.

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. :)

------
lkozma
I've never used EmacsWiki, but the tone of this article seems a bit off,
mocking the author of EmacsWiki for using his own software, etc.

~~~
cag_ii
It also overlooks one of the hardest parts of building a community site like
emacswiki, which is, well, building the community!

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.

------
rpdillon
Poorly written post on several fronts. The English is poor (forgivable), but
the points made about the structure and security of wikis are not well taken,
and reflect of misunderstanding of WikiNature
(<http://c2.com/cgi/wiki?WikiNature>).

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.

~~~
tptacek
I disagree that you can handwave around public editing of executable code that
is by convention copied and pasted to hundreds of machines by invoking
"WikiNature".

~~~
rpdillon
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.

~~~
tptacek
I have no idea why 5 paragraphs of message board comment is supposed to get me
to ignore the fact that anyone on the Internet could backdoor my Emacs by
editing a wiki page.

He's right; community code is a model that works on Github and absolutely does
not work on an unauthenticated Wiki.

------
Abomonog
I won't thank you for suggesting GitHub, because after I've taken your
suggestion, I will be less free! Gitorious is the superior solution :)

~~~
apgwoz
Totally agree about Gitorious, but I think it'd be wise to support GitHub (and
Bitbucket) as they are used by a large chunk of people.

~~~
dfc
_"wise to support github"_?

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

~~~
sirclueless
Basically, responding to Github issues and pull requests gives access to a
whole wealth of people who use Github to communicate and collaborate.

~~~
dfc
So in order to _"support github and bitbucket"_ you have to keep copies of
your project at both sites? That makes less sense than the original post. The
OP uses _and_ when including bitbucket the only way your explanation of
"support github" makes sense is with _"or bitbucket."_

~~~
stevelosh
> So in order to "support github and bitbucket" you have to keep copies of
> your project at both sites?

Yes. It's not difficult and means you can accept pull requests from both
Mercurial and Git users.

<https://bitbucket.org/sjl/gundo.vim/src>

<https://github.com/sjl/gundo.vim>

~~~
dfc
And separate issue/ticket systems? Do you do it for the LOLZ?

------
samgranieri
The peepcode on emacs helped me immensely when I tried emacs a few years ago.
Emacs is really really daunting for a beginner.

I tried emacs for a week , gave up, went back to textmate, and have since
switched to vim.

------
adulau
Internet is a nice place ranting... Some years ago, I did an Oddmuse wiki
to/from git:

<http://www.foo.be/cgi-bin/wiki.pl/OddmuseGit>

So you can grab all the emacswiki website (based on Oddmuse) and convert it to
your favorite markup/wiki relying on a git repository.

s/rant/do/g

------
pnathan
Disagree, emacswiki is a great resource.

