Innehållsförteckning RecentChanges News ElispArea HowTo Problems Suggestions

2010-10-02

Xah Lee mentioned Emacs Wiki in a recent blog post. He talked about Emacs Wiki Problems before, back in 2008. Both posts had their origins in newsgroups. [1] [2]

What do you think? What changes would you make, if you were in charge? Would you switch to Mediawiki? Why? How would you find editors to improve the wiki all across the board? How would you reorganize the wiki?

Back in 2008 I wrote a lot of articles on the newsgroup defending the current state of Emacs Wiki. But perhaps I was wrong, perhaps times have changed. Let me know.

Thanks.

I read Xahs blog post, and there are probably some things, that are worth thinking about. However, there is one thing he is certainly right about: "Emacswiki has its own agenda." And I FWIW think it is a good one.

Strongly regulated Wikis like the Wikipedia have merits of their own, but I really like the less rigid ways of emacswiki; in a way, its organisation cures exactly some of the problems Xah mentions: Drew Adams Icicles is an excellent addition to emacs, I don’t know if he ever tried to get it in, but such a complex addition would certainly take loooong anyways. But the emacswiki offers it a home, and a very prominent one as it is. Diversity is a good thing, as long as there are some fixed points people can turn to. Emacswiki is such a fixed point in the emacs universe, just like the info manuals are. Probably because of this, he proposed emacswiki to change to his idea of a "coherent and comprehensive" resource: But this totally misses the point and value of what emacswiki is today. I would certainly miss the old wiki.

Regarding the ‘links tend to prefer sister sites and not wikipedia’: Well, if that is what the authors link to, thats the way it is! I never saw anyone correcting a link to wikipedia in favor of another site.

On the wikisoftware used, I really have no oppinion on that. The site works fine for me, but I hardly ever used those "more powerfull" other wikisoftware. The blog post touches some relevant points, but those targeting the emacswiki really do not seem compelling to me. Keep up the good work, and thanks for emhe acswiki.

– Memnon

I don’t read Xah, but want to bring up instead that I pine for the days when Emacs development was more measured. It was painfully slower, but I think there was a closer following of new features and changes by the community and especially this Wiki. Emacs blogs for posting tricks generates a lot of excitement, but is not necessarily ideal. Introducing an Emacs packaging system and repository system will likely prove similarly to be a mistake. Emacs’s value is its monolithic nature. Contributed packages should be reviewed and made consistent with the Emacs whole.

There’s a lot of glory to be had in building some new fangled Emacs Web 2.0 site or moving the wiki to Media Wiki, but the real value is in documenting and making Emacs more useful. There’s also a lot of great material at Emacs Wiki, it just needs constant organizing, updating and tending too. Perhaps, we could develop a strategy to get more of this done and recruit others. The Emacs Wiki staying the same will not work forever, but installing a different Wiki is not a solution, either.

PS. Icicles has been proposed for Emacs before.[3][4]AaronHawley

‘there was a closer following of new features and changes by the community and especially this Wiki’
A well edited blog which regularly summarizes developments (interesting threads on the devel list, interesting changes in the wiki) would be great for this, because it could be a central point of news of Emacs and it could link to the interesting stuff, so people could go there as a main source of new information and find the intersting stuff. -anon

Please not Mediawiki. To me it is more important what wiki markup is used than what wiki software is used. Of course these often correlates and probably my focus is for “strategic” reasons :-) I for one would like to see the markup move into the direction of markdown or even better org-mode. Using markdown would have the benefit that many wiki systems could be tried out independently - either org-mode or something standard. If markdown were used everybody who thinks that the Emacswiki should move to myfavoredwiki could just setup a mirror and demonstrate it’s superiority, or forever hold their peace. Of course someone would have to convert existing pages…

If it was one me to decide what engine the Emacswiki should use it would be org-mode. See http://orgmode.org/worg for such a wiki. But it should be possible to edit the wiki on the web also (web edits could still be anonymous).

JonasBernoulli

Dunno what the supposed problems are, but I for one prefer that we keep things the way they are. A selfish reason no doubt, but non-trivial for me: I might have to spend hours reformatting things if the markup or its rendering were to change. For me, what we have now works, and works quite well. Why change? “If it aint broke don’t fix it.” Count me against changing, at least until I see some great upside to the change.

IIUC, an argument was made for a different and better kind of Emacs wiki/blog site. Great – let a hundred flowers bloom. But why would that require EmacsWiki to change? What’s wrong with people setting up another site if they would like something different? Nothing wrong with that. There is nothing sacred or exclusive about EmacsWiki. It’s just one place where some people like to contribute and that some people find useful. Nothing says that it is or it should be the only such place.

[P.S. Is that blog page any indication of the formatting resulting from using different wiki software? I hope not. In IE 7.0, at least, it is rendered pretty poorly: the two title lines overlap (is it intentional, as artistry perhaps?), and that problem remains even at full screen. But at least at full screen the text lines are not truncated, as they are in my normal browser window (portrait layout). And when I clicked some seemingly plain text in the window, just to give it focus, the browser hung for several minutes – I think maybe it thought I was clicking a radio button near the text in order to “vote”. Sheesh. Not really my idea of Web UI progress. Anyway, I imagine this is unrelated to the potential wiki-engine changes for EmacsWiki. Just thought I’d mention it in case it is related.]

DrewAdams

I also fear the effort of converting pages over to the markup required by some other content management system.

As for markup, the “standard” for wikis would be WikiCreole – I have a plugin that implements it. These could be added to the current mix of rules. There’d be some uncertainty because I can’t be sure that this will not have unintended consequences for a few rare pages, but it’d be a lot less effort compared to switching to an entirely new wiki software. Or I could add a plugin that implements BB Code. It’s used on a lot of forums. But I don’t think that Xah was actually referring to markup.

I think Xah had something more Web 2.0 in mind. Something with more bling, less arcane, more AJAX and less HTML forms, something cool, something big, something neat, with quality text, and a process, and a workflow. Something hard to put into words. But I don’t see how we could do it. I don’t think I’d want to contribute to something like it.

Personally, that’s why I’m with Drew: Let other people try it. The Emacs Wiki pages have a generous license. Use it to seed the next big Emacs site. But I’m not going to spend time on it.

AlexSchroeder

I just came back to this page to add a note to by post saying something like: The Emacswiki is fine as it is. I do not expect you are anybody else to change anything. But since you asked moving to something less odd would be the first thing I would like to be done - if you decide to put any work into it.

Besides markdown I also had creole on my mind - but couldn’t think of it’s name when I wrote my last post. Supporting additional markups is the wrong way to go I think. Of course it is nice if one can use the preferred markup when creating a new page - but things get harder when you want to edit a page that is a mix off oddmuse, markdown, creole and bb…

Stick to the markup we have or move to something else completely. I say you not because I expect you to do it but because the “easiest” way to do it would probably be to use the existing oddmuse code which knows/defines how the existing markup has to be interpreted and make it output some other markup as a onetime conversion. I don’t do perl so I won’t even try to experiment with it.

As for the work that I have been doing related to Emacs resources.

(1) The webpage of the Emacsmirror is currently statically generated. I will convert it to something a bit more dynamic but this will progress very slowly and is not intended to replace the Emacswiki. Also I have not decided whether I will allow users to actually change contribute through the webpage at all. Currently the Emacsmirror webpage shows the library headers of all mirrored packages plus some more information from the header and about required features. I have no immediate plans to change that. So the Emacsmirror will not be web2.0 anytime soon. Actually even after the changes that I plan it will we less web2.0 than the wiki!

(2) Interest in the Git repository I have created is pretty much non-existent so I won’t put any more work into it than what is required for the Emacsmirror. (The work that has been done allows me to mirror packages hosted on the wiki and to determine a package’s page on the wiki so that I can link to it from the mirror.)

For more information about how I see the mirror in relation to other Emacs related pages see this. The text on that page is quite old and there is no updated version. Simply collecting the currently 2728 packages took more time than expected.

So maybe my opinion boils down to this: The Emacswiki is perfectly fine as it is. As a wiki that is - as a way to distribute packages there are better solutions nowadays, github being my favorite. So I would encourage (not force) users to not publish new packages on the wiki but use github (or launchpad etc.) instead, but still create a page about them on the wiki.

JonasBernoulli

I have only a simple opinion to that: Whatever you do, keep the content. Avoid the rewriting trap, the content is much too valuable to be lost or “deprecated till it fits into the new cathegories” or such.

ArneBab