Forum: Instiki – Topic: Feature Requests

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

Forum: Instiki – Topic: Feature Requests

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 …

Forum: Instiki – Topic: Feature Requests

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.

Forum: Instiki – Topic: Bugs

Because of that last, my guess is that the pre-upload version is still in the cache, but that the page shown when the file is uploaded doesn’t read the cache version.

You’re probably correct. The rule is that pages with Flash messages on them (like the one that tells you that the file was successfully-uploaded) are not cached. So you get to see the correct page once, but if the incorrect one wasn’t deleted from the cache, that’s what you’ll see the second time.

Fixed in Revision 756 Revision 757.

Forum: Instiki – Topic: Bugs

New bug! I think that the page view is not getting “expired” (is that the right term?) when a file is uploaded. Here’s the “steps to reproduce”:

1. Edit a page to include a file upload whatsit.
2. Upload the file. Upon upload, the page looks fine and the question-mark link has been replaced by a link to the file.
3. Reload the page. Then it reverts to the previous view and the question-mark link is back again.
4. Next time the page is edited, it looks correct.

Because of that last, my guess is that the pre-upload version is still in the cache, but that the page shown when the file is uploaded doesn’t read the cache version.

So long as the cache hasn’t been expired, you can see this at http://ncatlab.org/doriath/show/uploads+and+caches. If you click on the question mark, you should get a copy of the Snake Lemma.

Forum: Heterotic Beast – Topic: Rails 3.1.0

I upgraded Heterotic Beast to Rails 3.1.0. Despite all my prior testing, the process didn’t go as smoothly as I would have liked, and this forum was pretty disrupted for most of Friday.

Should be back to normal now. But leave a comment here, if something’s still broken for you.

The main new feature is the Asset pipeline, which supposedly speeds the delivery of static files (CSS, javascript, and images). Unfortunately, the result seems buggy.

• The reference

  "#{asset_path('something.png')}"

  sometimes turns into (the correct)

  "/forum/assets/something-5c4374aa4b1911ebbabb73883b3cd5c0.png"

  and sometimes it turns into (the incorrect)

  "/assets/something-5c4374aa4b1911ebbabb73883b3cd5c0.png"

  I’m using some Apache-fu to redirect the latter, but that shouldn’t be necessary.

• I had to switch to Sass (from .css.erb) to get URLs for background images to include the fingerprint. I.e., within a .css.erb file, the above generates

  "/assets/something.png"

Other minor bugs include:

• The acts_as_state_machine gem uses some deprecated methods, which generate a warning in the User model. There’s a Rails 3.1 fork which fixes the problem. But it’s unclear when, if ever, that will be released as a gem.

• Prototype 1.7.0 generates a Javascript error

   Error: mismatched tag. Expected </link>.
   Source File:
   <div xmlns="http://www.w3.org/1999/xhtml"><link></div>

  The problem is in the LINK_ELEMENT_INNERHTML_BUGGY function, where you could replace <link> with <link/> to silence the error. This was not a problem in Prototype 1.6.x.

Forum: Instiki – Topic: Bugs

Of course they are different.

I reserve the right to be stupid!

Forum: Instiki – Topic: Bugs

Of course they are different.

• ”<a> </a>” is an ”a” element with a single child node, which is a text node, containing ” “.
• ”<a></a>” is an ”a” element with no children.

In X(HT)ML, the latter is equivalent to ”<a/>”.

The short-tag construction does not exist in HTML and all browsers interpret the latter as the opening tag, ”<a>”, of an ”a” element (which is not what you want).

Forum: Instiki – Topic: Bugs

I’m afraid I’m not very well informed on the differences between XHTML and HTML. I probably ought to be (I found the w3c page on it which was useful). So <a> </a> is actually different to <a></a>, then. But it seems as though when rendered then the extra space has no actual effect. (Let’s try: a a and aa. Though my actual use case has them on lines by themselves:

Text

Forum: Instiki – Topic: Bugs

<a id="anchor"> </a>

Here's a [[wikilink]

would not have triggered the bug. Only empty elements (which get converted to short-tag syntax, <a id="anchor"/>, in the output) triggered this bug. Since you probably don’t want empty a or code elements (they are perfectly correct in XHTML, but wreak havoc, when the same document is parsed as HTML), you probably didn’t want the problematic (if you prefer that to uselesss) empty elements in the first place.

Forum: Instiki – Topic: Bugs

Yet again: thanks!

Though I dispute the “equally useless”. I was using the empty anchor tag to put an anchor at a particular place on the page when there wasn’t an obvious thing to “hang” it on. Of course, I could always find something to put it with, but it was coming from my automatic LaTeX-to-iTeX package and it’s much easier to have an empty anchor than try to figure out automatically where it can be put.

Forum: Instiki – Topic: Bugs

Same thing happen(ed) when you typed (the equally useless)

<code></code>


Here's a [[wikilink]].

Fixed in Revision 744.

Forum: Instiki – Topic: Bugs

Next bug. For some strange reason, empty anchors mess up wikilinks:

<a id="anchor"></a>

Here's a [[wikilink]]

means that Instiki does not process the wikilink. If I put text in the anchor, then it’s fine. If I replace the a tag by p or div then it’s fine (didn’t test other tags). The problem persists for a bit, and then starts working again (not quite figured out the rule for when it does, sometimes it seems to be in the middle of a paragraph).

This does feel a bit like a “when I bang my head on the wall then it hurts” bug, but still it is strange behaviour particularly given the tag-dependence.

(See http://ncatlab.org/nlab/show/Sandbox for some experiments.)

Forum: Instiki – Topic: nlab

If you can’t remember, then I’ll experiment with taking it out and see who complains, and about what.

Forum: Instiki – Topic: nlab

Ah. I see. I was deceived by your example

+-- {: .num_theorem}
###### Theorem ######
This is italic text.  But [this is not](#top){: style="font-style: normal;"}.
=--

In general, the more specific CSS selector wins, and there was some circumstance where inheritance from .num_theorem was not sufficient. I needed the more specific .num_theorem *. But, for the life of me, I can’t recall the details.

Forum: Instiki – Topic: Bugs

Great! I’ll apply those tomorrow morning.

(And I learnt a new word. Doubt I’ll be able to get it in to Boggle, though.)

Forum: Instiki – Topic: nlab

It’s about inheritance. Let me do my example again.

+-- {: .num_theorem}
###### Theorem ######
This is italic text.  *This is normal, but [this is not](#top).*{: style="font-style: normal;"}.
=--

The link should inherit the font-style: normal; from the span but it doesn’t because it matches the CSS rule .num_theorem *.

Forum: Instiki – Topic: nlab

Works for me.

was generated by

+-- {: .num_theorem}
###### Theorem ######
This is in italics. *This is normal.*{: style="font-style: normal;"} And this is italic, again.

This whole paragraph is normal.
{: style="font-style: normal"}

This paragraph is in italics.
=--

Aside from the kludgy bit about applying styles to spans, I have no idea what your issue is.

Forum: Instiki – Topic: Bugs

Thanks for the report. Fixed in Revision 742.

I think this bug was a long-standing one. The other, fixed in that Revision, was completely iatrogenic.

Oh, and your double-escaping bug is fixed in Revision 743.

Forum: Instiki – Topic: nlab

(Not so much a bug, but also not a feature request, so gets put here.)

Is there a reason why the italic style in theorems is done via:

.num_theorem * {
   font-style: italic;
}

rather than:

.num_theorem {
   font-style: italic;
}

The * makes it very hard to override the italic selection. For example, something like:

<p style="font-style: normal;"><a href="somewhere">link</a></p>

will come up as italic, I think. Actually, I can test it here:

Yes, it did. So the normal CSS inheritance is effectively bypassed by the * selector. To override it, I need to put another * selector in place but I can only do that in the web CSS and not in the style on a div.

I’m generally reluctant to modify stuff that you’ve put in place! Is there a reason for the *, or can it be dropped?

Forum: Instiki – Topic: Bugs

Okay, next one. I’m recording the error message first. It’ll take me a few minutes to track down exactly what is causing it.

#<ActionView::TemplateError: 
ActionView::TemplateError (undefined method `children' for nil:NilClass) on line #15 of
app/views/wiki/page.rhtml:
12:     </p>
13:     <%= @renderer.display_diff %>
14:   <%- else -%>
15:     <%= @renderer.display_content %>
16:   <%- end -%>
17: </div>
18: 

Actually, didn’t take long at all. The last line of the document was * (the previous line had been a list item as well) so presumably maruku was looking for the rest of the item, couldn’t find it, and gave up in disgust.

I guess that getting a more sensible error (this causes smoke) would involve hacking maruku more than you’d like.

Forum: Instiki – Topic: Bugs

I originally thought that this one was due to old browsers, but I’m now using FF6.0 so it can’t be that. Anyway, when I create a new page, the “Page X does not exist” is getting escaped once too often and I see:

Page &quot;Proper Homotopy Theory&quot; does not exist.<br/>
Please create it now, or hit the &quot;back&quot; button in your browser.

Forum: Instiki – Topic: Bugs

Thanks! I’ve updated the nLab and Azimuth Project. That’s great.

Forum: Instiki – Topic: Bugs

Fixed in Revision 736.

Forum: Heterotic Beast – Topic: Bugs

Long lines (of code?) make the posts a bit wide. Currently, my view on http://golem.ph.utexas.edu/forum/forums/instiki/topics/bugs#post_77 has all the posts reaching in to the grey region on the right-hand side.

Forum: Instiki – Topic: Bugs

Maruku doesn’t like starting bold text with bizarre unicode symbols, or named entities (presumably these are converted to unicode symbols). Example **∞-gerbe**.

This causes a crash in instiki:

#<ActionView::TemplateError: 
ActionView::TemplateError (invalid byte sequence in UTF-8) on line #15 of
app/views/wiki/page.rhtml:
12:     </p>
13:     <%= @renderer.display_diff %>
14:   <%- else -%>
15:     <%= @renderer.display_content %>
16:   <%- end -%>
17: </div>
18: 

PS: This showed up after I installed the latest version of instiki.

Forum: itex2MML – Topic: Feature Requests

What should itex2MML do, that it doesn’t, currently?

Forum: itex2MML – Topic: Bugs

Discuss bugs in itex2MML.

Forum: Heterotic Beast – Topic: Bugs

No it doesn’t.

Deleting the only post in a topic, also deletes the topic. Possibly, the redirect (which normally goes to topic#show but, in this case, should go to the forum#show because the topic no longer exists) is incorrect.

Fixed.

Forum: Instiki – Topic: nlab

Thinking about Recently Revised and All Pages, you suggested (somewhere) taking them out of the sweeper as a way of stopping them being regenerated every time a page is edited (I don’t know if this was one of you “If you’re going to do something crazy, here’s a way of limiting how crazy you’re going to be” suggestions or if you thought this was actually a good idea).

The former. You’re trading off workload on the server for stale data. Since computers are supposed to serve humans, rather than the other way around, the question is: does this improve the user experience?

Say you implement the above suggestion. On the one hand, the user always (or almost always, depending on implementation) receives the cached page, i.e. gets a quick response. On the other hand, the data is invariably stale.

Leaving these alone, the user is guaranteed to receive fresh data, but there could be a significant delay, if the page has to be regenerated. What percentage of requests for these pages hit the cache?

A better solution is to pull in the will_paginate gem, and paginate the data returned. That makes the request $O(1)$, again, instead of $O(N)$. So the user gets both a quick response AND up-to-date data.

As to moving away from Maruku, to some peg-markdown-based clone, note that

1. This will benefit Heterotic Beast as well.
2. The task I’m asking of your guys is not “programming,” per se. It involves writing a formal PEG grammar for Maruku’s extended Markdown syntax (starting with the existing PEG grammar, already in peg-markdown).
3. On the other hand, if there were someone handy in C, that would be most appreciated, too, because I am crappy at C. Hooking in itex2MML would take mere minutes for a competent C-programmer.
4. I imagine that a such a fork of peg-markdown (as it’s written in C), would be useful in your other projects, as well.