7 ms·

Die EmacsWiki, Die

69 points by bozhidar 15y ago

Abomonog 15y ago
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 15y ago
  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 15y ago
    "wise to support github"? What does that mean? Github is not some function/feature that you support?
    - sirclueless 15y ago
      Basically, responding to Github issues and pull requests gives access to a whole wealth of people who use Github to communicate and collaborate.
      - dfc 15y ago
        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 15y ago
        > 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://bitbucket.org/sjl/gundo.vim/src https://github.com/sjl/gundo.vim https://github.com/sjl/gundo.vim
        dfc 15y ago
        And separate issue/ticket systems? Do you do it for the LOLZ?
    - apgwoz 15y ago
      The point that the article makes is that OddMuse makes a horrible project hosting system. It's easy enough to store a link to github, or bitbucket, or gitorious (and in all reality, they all speak git, so it's just another remote) as the official project location in whatever new wiki-system emerges.
- Argorak 15y ago
  I upvoted you, but mostly because I hate downvotes for unpopular stances. 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.
lkozma 15y ago
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.
- justinhj 15y ago
  Not only that, package developers are 'lazy' for not documenting or moving to github? I don't see the author volunteering to do anything. :)
- reddit_clone 15y ago
  > but the tone of this article seems a bit off 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.
- cag_ii 15y ago
  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.
- astine 15y ago
  You know, I didn't get that vibe. I felt that the author brought up a lot of legitimate complaints about EmacsWiki. Having used EmacsWiki, I agree with a lot of them, especially the stuff about the advice on the wiki usually being very dated and confusing. The choice of software might be the least of the complaints, but the author didn't seem to dwell on it.
rincewind 15y ago
> 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.
- mhd 15y ago
  I have to agree about the wiki-ness. Wikipedia is the "weird one", not EmacsWiki.
  - lambda 15y ago
    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.
    - mhd 15y ago
      In my opinion, it really depends on the subject matter. For an encyclopedia, inline arguments are surely the wrong thing. But in that case, you're really using a wiki-like system as a more user-friendly, accessible content management system. 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.
    - kensanata 15y ago
AceJohnny2 15y ago
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 http://emacswiki.org/emacs/CScopeAndEmacs
- whateverer 15y ago
  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/ http://batsov.com/articles/2011/08/19/a-peek-at-emacs24/
  - mechanical_fish 15y ago
    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.
kinleyd 15y ago
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. :)
- skeptical 15y ago
  I'm surprised that this is not the obvious reply. The author puts it a bit as if setting up a working documentation website is the difficult part. Building up good content is the real value here, not how is managed. He suggests that emacs related projects should move to github. Heck, he's free to to keep is own repository of branches there if the license allows it, which in almost every case does. Who's stopping him from starting an emacs related wiki on github, if he so likes it (not being sarcastic)?
samgranieri 15y ago
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.
rpdillon 15y ago
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 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.
- stroboskop 15y ago
  I don't agree with the post on many levels. But "The English is poor"? That complaint sounds like a low blow. Native speakers are a minority of total English speakers, and the majority may have something to say, too. I'm still giving you an upvote because you bring up Worg.
  - rpdillon 15y ago
    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.
- tptacek 15y ago
  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".
  - mechanical_fish 15y ago
    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...
    - 15y ago
adulau 15y ago
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 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 15y ago
Disagree, emacswiki is a great resource.

69 points by bozhidar 15y ago

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 15y ago
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 15y ago
  "wise to support github"? What does that mean? Github is not some function/feature that you support?
  - sirclueless 15y ago
    Basically, responding to Github issues and pull requests gives access to a whole wealth of people who use Github to communicate and collaborate.
    - dfc 15y ago
      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 15y ago
        > 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://bitbucket.org/sjl/gundo.vim/src https://github.com/sjl/gundo.vim https://github.com/sjl/gundo.vim
        dfc 15y ago
        And separate issue/ticket systems? Do you do it for the LOLZ?
  - apgwoz 15y ago
    The point that the article makes is that OddMuse makes a horrible project hosting system. It's easy enough to store a link to github, or bitbucket, or gitorious (and in all reality, they all speak git, so it's just another remote) as the official project location in whatever new wiki-system emerges.
Argorak 15y ago
I upvoted you, but mostly because I hate downvotes for unpopular stances. 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.

lkozma 15y ago

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.

justinhj 15y ago
Not only that, package developers are 'lazy' for not documenting or moving to github? I don't see the author volunteering to do anything. :)
reddit_clone 15y ago
> but the tone of this article seems a bit off 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.
cag_ii 15y ago
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.
astine 15y ago
You know, I didn't get that vibe. I felt that the author brought up a lot of legitimate complaints about EmacsWiki. Having used EmacsWiki, I agree with a lot of them, especially the stuff about the advice on the wiki usually being very dated and confusing. The choice of software might be the least of the complaints, but the author didn't seem to dwell on it.

rincewind 15y ago

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

mhd 15y ago
I have to agree about the wiki-ness. Wikipedia is the "weird one", not EmacsWiki.
- lambda 15y ago
  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.
  - mhd 15y ago
    In my opinion, it really depends on the subject matter. For an encyclopedia, inline arguments are surely the wrong thing. But in that case, you're really using a wiki-like system as a more user-friendly, accessible content management system. 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.
  - kensanata 15y ago

AceJohnny2 15y ago

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 http://emacswiki.org/emacs/CScopeAndEmacs

whateverer 15y ago
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/ http://batsov.com/articles/2011/08/19/a-peek-at-emacs24/
- mechanical_fish 15y ago
  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.

kinleyd 15y ago

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

skeptical 15y ago
I'm surprised that this is not the obvious reply. The author puts it a bit as if setting up a working documentation website is the difficult part. Building up good content is the real value here, not how is managed. He suggests that emacs related projects should move to github. Heck, he's free to to keep is own repository of branches there if the license allows it, which in almost every case does. Who's stopping him from starting an emacs related wiki on github, if he so likes it (not being sarcastic)?

samgranieri 15y ago

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.

rpdillon 15y ago

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

stroboskop 15y ago
I don't agree with the post on many levels. But "The English is poor"? That complaint sounds like a low blow. Native speakers are a minority of total English speakers, and the majority may have something to say, too. I'm still giving you an upvote because you bring up Worg.
- rpdillon 15y ago
  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.
tptacek 15y ago
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".
- mechanical_fish 15y ago
  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...
  - 15y ago

adulau 15y ago

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 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 15y ago

Disagree, emacswiki is a great resource.