Forums Instiki

Feature Requests

Subscribe to Feature Requests 38 posts, 4 voices

 
Andrew Stacey 118 posts

This is a thread for feature requests for Instiki.

 
Andrew Stacey 118 posts

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

 
Andrew Stacey 118 posts

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

 
admin Administator 57 posts

edited 3 years ago

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?
 
Andrew Stacey 118 posts

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.

 
Andrew Stacey 118 posts

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.

 
distler Moderator 81 posts

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?

 
Andrew Stacey 118 posts

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

 
Andrew Stacey 118 posts

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.

 
distler Moderator 81 posts

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

 
Andrew Stacey 118 posts

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

 
distler Moderator 81 posts

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.

 
Andrew Stacey 118 posts

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?

 
distler Moderator 81 posts

edited 3 years ago

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

 
Andrew Stacey 118 posts

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.

 
distler Moderator 81 posts

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…

 
Andrew Stacey 118 posts

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.

 
distler Moderator 81 posts

edited almost 3 years ago

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 …

 
Andrew Stacey 118 posts

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

 
Andrew Stacey 118 posts

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

 
Bernhard Sta... 4 posts

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?

 
admin Administator 57 posts

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 …

 
Andrew Stacey 118 posts

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.

 
Bernhard Sta... 4 posts

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.

 
distler Moderator 81 posts

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.

 
Andrew Stacey 118 posts

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?

 
admin Administator 57 posts

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…

 
Andrew Stacey 118 posts

edited 2 years ago

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

The first letter of the English alphabet is A.

Theorem

The second letter of the English alphabet is B.

Theorem

The third letter of the English alphabet is C.

Theorem

The fourth letter of the English alphabet is D.

Theorem

The fifth letter of the English alphabet is E.

Theorem

The sixth letter of the English alphabet is F.

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.
 
admin Administator 57 posts

edited 2 years ago

Ah.

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

 
Andrew Stacey 118 posts

Wrong thread, then!

Forums Instiki