This is a thread for feature requests for Instiki.

(I’m really just trying out the features of the forum, but may as well do so in a “useful” way.)

1. I’d like a span equivalent of the +-- {: .class attributes} ... =-- syntax. At the moment, I do something like *word*{: style="text: normal"} which seems a bit daft.

2. I’d like an easy way to add id (and other attributes) to individual list elements. So I could write 1.{: #firstitem} to get an id tag on that item.

That’s all for now!

Here’s another random idea: to make it easier for people to contribute to a wiki (thinking particularly of the nLab), howabout a javascript annotation system? Some people might find it a bit daunting to edit a whole page just to correct a minor spelling mistake, but could leave a quick note so that the next person who does edit the page can see what outstanding notes there are.

Just a random idea - I haven’t thought it through very much. (But I did a little search to see that it was, at least, technically possible via javascript.)

Hmmm.

1. I agree that *this*{: style="font-style: normal; color: red;"} is a little silly.
2. I thought you could already do that (see here). (It seems that you need a space between the ”2.” and the IAL, despite what I said there. I think this is a result of this commit.)
3. I’m not sure I understand your Javascript suggestion. Could you point to some software that implements something similar?

Ah, number 2 is fantastic. I hadn’t spotted that (I’ve been particularly bad at monitoring the RSS feeds since my feed reader blew up). I’ll try that.

Just tested adding IALs to lists. Definitely useful, but I’d add one minor modification: the ability to use \ref to refer back to list elements (at the very least, to enumerated list elements). So

1. {: #first} The first item

The first item was \ref{first}

would work. At the moment, I have a hack that uses the numbering system for theorems and so forth to get this to work, putting the class .num_enumX (X increments with the enumerate environment so that each is unique) on a +-- ... =-- div at the top of the list element. This seems to be enough to trigger the internal maruku counter and so make \ref{...} work. It’d be great if this were done automatically without that hack.

I’m not sure I understand. If an element has an explicit id, because you gave it a {: #foo} IAL, then you can refer to it a [fubar](#foo). \ref{...} is used for linking to things with generated numbers (like theorems, ‘n such).

I think your motivation is to have something that converts to LaTeX. \ref{foo} converts just fine. There are two issues, if I understand correctly.

1. The IAL on the list-item doesn’t get converted to a \label{foo} on the \item in the LaTeX output.
2. For the XHTML output to behave as you would like, you need to invoke Maruku’s internal counter, so that \ref{foo} is converted to a hyperlink, with anchor-text being the number of the list-item.

The latter is a bit awkward, as there can be several ordered-lists on a page. We’d need a separate counter for each one, no?

Actually, I’m going the other way. I’m going from LaTeX to Instiki. So the source file has \label{foo} and \ref{foo} in it already and in the LaTeX output then it gets converted to “In (2) we saw that …”. So there’s nothing in the source to put as the text in the anchor and something has to be put in its place. Thus my thinking was to subvert the maruku counter-counting to figure out what text should go there. Putting a class .num_enuma on each element of the list makes maruku think that there is a list to be counted there and so it converts the \ref{foo} to the correct hyperlinked text. If you’re using maruku here, this should work:

1. The first item.

2. The second item.

Now we should be able to refer to 1 and 2. I won’t know if that worked until I save the reply, though!

Anyway, it certainly does work on Instiki. I don’t need another list in the CSS because the counters are already produced by the browser working on the list. All I need is for maruku to count the entries in the list, and for that I just need the dummy num_X classes. You’re right that I need one per list, but that shouldn’t be that many on any given page.

(Okay, time to see if that list worked.)

Yes, it worked!

And to finish the thought, since I’m generating this from a LaTeX source, it can automatically handle adding the dummy CSS classes.

…dummy CSS classes.

I bridle, only at referring to these as “dummy.” I thought that the whole mechanism I invented with those classes was very clever. And even more versatile than I had originally envisioned.

Not “dummy” at all….

Ah, another UK/US distinction. Something that is a “dummy” is not necessarily “dumb”. A “dummy” simply means a fake (although it’s not as pejorative), a “stand in”. Had I meant to be rude, I would have said “dumb CSS classes”.

Something that is a “dummy” is not necessarily “dumb”. A “dummy” simply means a fake …

I am familiar with the usage (there’s not a UK/US distinction).

I was making a lame attempt at humour, whilst making the serious point that these CSS classes are used for styling (generated content), and as structural hooks (for converting the \ref{}s into hyperlinks), hence are not “dummy” in either sense.

Is the following possible? I tried a couple of things, but don’t know enough to know if what I tried was all that there was. Given that instiki can be installed as a gem, can I install a system-wide version of the code and then run it as a user, with each user having their own separate instiki process, but sharing the code?

Given that instiki can be installed as a gem …

Instiki cannot be installed as a Gem.

There’s an old (~0.10.x) version, which worked as a Gem, and which is probably still floating around (on the internets, nothing ever really disappears). But that was long before my time, and I have not even thought about packaging the current version as a Gem.

Of course, under Passenger, you can run multiple instances of a Rails application (including Instiki), under different subdirectories (or subdomains, if you have virtual hosts enabled).

(At least with Instiki, that would require separate copies of the code, as each instance would have to point to its own database (in config/database.yml). I suppose one could use soft-links astutely, so that there was really only one copy of the source code, shared by these different instances.)

Okay. So simpler just to have separate copies of the code.

I guess what I’m stumbling around with this is some way to make the update cycle a little simpler. At the moment, I update a live instiki installation from golem, and with the ruby bundle step as well, then the update can take a noticeable length of time. What would be better would be to pull the changes to an offline copy on that machine, then update the live versions from the offline copy.

I can easily do that with the bzr stuff, but how would it work with the gems? Perhaps if the live versions weren’t bzr repositories but were more simply synced with the offline version in some fashion (thinking a bit like how rsync works). Hmm, so the workflow would be:

1. Pull the latest instiki revisions to the “dead” code
2. Run ruby bundle on that
3. Copy any updated files from the “dead” version to the live versions, being sure not to clobber anything special
4. Restart instiki on the live versions

would that work, do you think?

Or is this another case of me thinking something is important which really isn’t.

As far as I can tell, updating the application files on a running Rails application (in production mode) has no effect, until the application is restarted. I, honestly, haven’t thought about the bundled Gems, but I expect the answer is the same.

In any case, ruby bundle is pretty fast (of course, that’s because it’s actually superfluous) if the Gemfile hasn’t changed. I suppose you can stat the Gemfile to see whether you actually need to run ruby bundle at all.

But I don’t think that’s your issue…

Here’s something I’d find useful: allowing for anchors in wikilinks. So that I could type [[homework+2011+2#question_three_5]]. Since missing anchors at least take one to the right page, I wouldn’t check that the anchor itself exists.

I feel that there is a qualitative difference between a wikilink and a hyperlink, and links to anchors on particular pages should be in the wikilink category.

I feel that there is a qualitative difference between a wikilink and a hyperlink

Indeed, there is. And that’s why there are no anchors allowed.

If page “Foo” has multiple WikiLinks to [[Bar]], there’s still only one corresponding entry in the database. That could no longer be true if “Foo” could link to [[Bar]] and to [[Bar#baz]].

What you want is a hyperlink, and Markdown provide a syntax for hyperlinks which permits anchors.

Update:

On reflection, I suppose that allowing the presence of anchors doesn’t strictly conflict with having just one entry in the database. I should think some more …

It would still just be one entry in the database. But it would mean that there actually was an entry in the database if “Foo” only links to an anchor on “Bar”. Having to do it via hyperlinks would mean that the pages weren’t officially linked.

My idea (no idea how practical) would be:

1. Strip off the anchor from [[Bar#baz]] and store it temporarily
2. Process [[Bar]] as before
3. Put back the anchor at the end of the resulting link

So then at the point of sorting out the database, instiki doesn’t care about the anchors and just registers the link to page “Bar”.

(Hopefully minor) feature request: this came up in a discussion on citing the nLab. It would be convenient to have the current revision number displayed on the page somewhere obvious. Perhaps the footer could read:

Version 144, revised on December 1, 2011 11:24:39 by …

I know it’s easy to deduce - take the number after “Back in time” and add 1 - which is why I said “convenient” rather than anything stronger.

As far as I can see, there’s a lot of discussion about notational conventions on nLab, e.g. in the article on comma categories. However, there’s a huge number of articles that would have to changed if some notation actually was to be consistently adopted. I haven’t made any scientific investigations, but it seems clear to me that this hinders improvement of notation. Good notation is essential for making mathematics intuitive and useable, so wouldn’t it make sense to add powerful features for expressing and experimenting with notations?

A first step would be separating data and presentation, e.g. writing “\commacategory{F}{G}” or similar (not necessarily itex) instead of “F \downarrow G”. The concrete notation would be specified at a separate stage. This could happen

• globally by the site operators to consistently change all occurences
• per-article by the authors e.g. to avoid notation clashes
• individually by the user based on his preferences.

If this was done in every article, changing notations would become a matter of seconds. This would of course mean that in the case of nLab, some thousands of articles have to be changed (maybe some heuristics could be used to speed this up), but that has to be done only once and then hopefully never again. Future search-and-replace style global “refactorings” for generalizing or normalizing notation would become possible, too.

The major technical challenge I see would be finding a good mechanism for specifying abstract notations. The rest should be pretty straightforward.

What do you think about this?

That sounds like a request for macro-support in itex. For a variety of reasons, that’s unlikely to happen.

On the other hand, perhaps you have something else in mind …

That sounds like a request for macro-support in itex. For a variety of reasons, that’s unlikely to happen.

I, for one, would be against this. It would actually hinder collaboration as everyone would have to learn the local conventions every time they wanted to edit a page, and stuff that worked on one wouldn’t work on another.

That sounds like a request for macro-support in itex. For a variety of reasons, that’s unlikely to happen.

What I mean is a research-friendly facility

• to define vocabularies for abstract mathematical languages (notations), and
• to render terms of that language in configurable ways. An implementation of this idea might use Turing-complete macros, but would be using a sledgehammer to crack a nut.

I, for one, would be against this. It would actually hinder collaboration as everyone would have to learn the local conventions every time they wanted to edit a page, and stuff that worked on one wouldn’t work on another.

I’m sure there’s a solution for that: A vocabulary could be modelled in a distributed fashion much like OWL ontologies or XML Schema Definitions, which allow for importing other “vocabularies” (ontologies/schemata). One could even imagine a versioning and migration scheme to implement the global refactorings I mentioned in my first post. I haven’t thought this through, but that might even be a practical application of basic category theory ;) BTW this also has the advantage that a user doesn’t have to learn the language again and again.

I’m sure there’s a solution for that: …

Is this a feature that is implemented somewhere?

Your short description is slightly … underspecified. So looking at an actual implementation would be helpful to me, in deciding whether this is something to implement in Instiki.

The issue of needing ids to keep theorem numbers in step has been raised (again). Mike came up with a suggestion which seems reasonable on first reading which is that instiki (or whichever part of it is appropriate) adds an automatic id if one isn’t present, much in the way that the table of contents part does.

So if I write

+-- {: .num_theorem}
###### Theorem
$X$ is nuclear and Banach if and only if it is finite dimensional
=--

then instiki adds an automatic id, say id="theorem1" where the 1 gets incremented according to the internal counter (which it has, if I remember right, since it uses that to figure out the ref number). Would this be feasible?

The issue of needing ids to keep theorem numbers in step has been raised (again).

I’m not quite sure what the issue is.

So if I write

+-- {: .num_theorem}
###### Theorem
$X$ is nuclear and Banach if and only if it is finite dimensional
=--

your theorems still get numbered (correctly, I hope).

Since there’s no label, there’s no easy way to refer to this theorem, but maybe you don’t care. And if you do care, wouldn’t you want to avoid the fragility associated to an automatically-generated id (which will change if someone re-orders the theorems, adds a new one, or whatever)?

I must be misunderstanding…

Take a look at http://ncatlab.org/nlab/show/Sandbox (feel free to ignore the request, I put that there to ensure that no-one messed with them before you’d seen it). Each theorem has .num_theorem style so the CSS counts them. However, the counting that is done by Instiki to find the theorem numbers for use in \ref{...} commands only counts those with ID tags. So the labels for the theorems that I do want to refer to are miscounted because I prefer to have all my theorems numbered rather than only number those that I explicitly refer to.

Does the same issue happen here. Let’s experiment:

Theorem 1 refers to A, Theorem 3 to C, and Theorem 6 to F.

Yes, so it’s the same here. Thus, no need to check the Sandbox. Here’s the source of what I just typed:

+-- {: .num_theorem #a}
###### Theorem

The first letter of the English alphabet is A.
=--

+-- {: .num_theorem}
###### Theorem

The second letter of the English alphabet is B.
=--

+-- {: .num_theorem #c}
###### Theorem

The third letter of the English alphabet is C.
=--

+-- {: .num_theorem}
###### Theorem

The fourth letter of the English alphabet is D.
=--

+-- {: .num_theorem}
###### Theorem

The fifth letter of the English alphabet is E.
=--

+-- {: .num_theorem #f}
###### Theorem

The sixth letter of the English alphabet is F.
=--

Theorem \ref{a} refers to A, Theorem \ref{c} to C, and Theorem \ref{f} to F.

Ah.

That is indeed a bug. Fixed (in Instiki and Heterotic Beast, too). Thanks.

Wrong thread, then!