ddfreyne edited this page May 14, 2012 · 30 revisions
Clone this wiki locally

Welcome to the Fast Aleck wiki!

Excluded elements

A handful of elements (code, kbd, pre, script) are currently excluded. Do you think any other elements needs to be excluded?

  • samp Implemented
    • +1 @ddfreyne
  • var Implemented
    • +1 @ddfreyne
  • math Implemented
    • +1 @ddfreyne
    • +1 @bobthecow
  • head Rejected -- only <title> is excluded
    • -1 @ddfreyne (that would eliminate title)
    • -1 @bobthecow
    • +1 @telemachus (see <title>CAPS Cause We Are Excited!</title>)
  • textarea Implemented
    • +1 @bobthecow

Tags that should cause quote wrapping and Widon’t

A start tag such a <p> will let the first following quote be wrapped inside <span class="quo"> or <span class="dquo">. A close tag such as </p> will cause the last whitespace character to be transformed into a &nbsp; (Widon’t).

Which tags should qualify?

  • address
  • article ~@bobthecow
  • aside ~@bobthecow
  • blockquote
  • caption ~@bobthecow
  • dd
  • div
  • dt
  • figure ~@bobthecow
  • footer ~@bobthecow
  • h1 to h6
  • header ~@bobthecow
  • legend ~ @bobthecow
  • li
  • nav ~@bobthecow
  • p
  • section ~@bobthecow
  • td ~@bobthecow
  • th ~@bobthecow


  • Enhance text inside alt="" and title=""
    • +1 @ddfreyne
    • +1 @bobthecow
  • Split enhancements into strict character enhancements, and "html" enhancements — this allows "enhance inside alt/title attrs" and "enhance inside <title>" without borking html.
    • +1 @bobthecow
    • +1 @ddfreyne
  • Add an enhancement for runs of digits and seperators, allowing users to substitute lower case (old-style) numerals: 867-5309<span class="number-caps">867-5309</span>
    • +1 @bobthecow
  • Add a hairspace typographic enhancement. See this issue for more detail.
    • +1 @bobthecow
  • Allow -- to become an en dash instead of an em dash; em dash stays as ---
    • +1 @auxbuss

Better Architecture

At its current state, Fast Aleck is quickly becoming unmaintainable. Its main function is several hundred lines long and contains duplicated code. Fixing bugs is becoming challenging, and I expect to end up in a situation where fixing one bug will almost certainly introduce new ones.

There is need for an architecture that makes maintaining Fast Aleck (by fixing bugs or adding new features) a lot easier. A naïve solution would be to use a multi-pass translator, but this will result in a slowdown due to cache locality and the fact that the same comparisons/tests will need to be performed more than once.

I propose an architecture in which separate mini-translators are chained right after another in a directed graph with one entry and one exit point. When a character is added to the first mini-translator, it is propagated through the entire graph before the next character is processed.

An example of such a mini-translator would be one that converts three dots (...) into an ellipsis (…). This translator’s sole responsibility is to detect three consecutive dots and convert it into an ellipsis—nothing more, nothing less.

Another example of a mini-translator would be the tag handler. This translator would have more work than the ellipsis translator, because it will need to handle excluded elements (such as <pre>), in which case the translator’s output will directly go to the general output, and resetting elements (block elements such as <p>).

Mini-translators can have an internal buffer, so that the output of caps-wrapping will not appear on the main output unless it is completed. This is not always necessary; for instance, the ellipsis translator can keep track of the number of read dots instead of keeping the actual dots in a buffer.

Advantages of this approach are:

  1. More maintainable, since independent blocks are chained together
  2. Comparable speed (probably a tiny bit slower)
  3. Streamable, since both input and output are streamed

~ @ddfreyne