Wincent Colaiuta [Fri, 8 May 2009 12:50:31 +0000 (14:50 +0200)]
Improve efficiency of _Wikitext_pop_all_from_stack
Use a for-loop instead of repeatedly calling ary_entry inside
a while-loop. The simple integer comparison will be faster
than the function call. (And in any case, the
_Wikitext_pop_from_stack function which is called here will
do an ary_entry call anyway; so what's really happening here
with this change is that we call ary_entry once for each item
instead of twice.)
Wincent Colaiuta [Fri, 8 May 2009 12:10:54 +0000 (14:10 +0200)]
Reuse link_target if link_text is Qnil in _Wikitext_append_hyperlink
This cleans up a few call sites of _Wikitext_append_hyperlink. The
majority of these sites pass in the same text for the link target
and link text parameters, so teach the function to automatically
reuse the link target as the link text if no link text is explicitly
provided.
Wincent Colaiuta [Fri, 8 May 2009 12:00:31 +0000 (14:00 +0200)]
Minor clean-up in _Wikitext_rollback_failed_external_link
Minor reorganization to make _Wikitext_rollback_failed_external_link a
little cleaner. Avoid the almost identical calls to
_Wikitext_append_hyperlink and instead set up a link_class local
variable.
Wincent Colaiuta [Fri, 8 May 2009 11:31:01 +0000 (13:31 +0200)]
Refactor _Wikitext_rollback_failed_link function and friends
The _Wikitext_rollback_failed_link function now encapsulates the
common pattern of trying to roll back failed internal and external
links in a single function call.
On those occasions when we want to roll back only one type of link
we must instead use the _Wikitext_rollback_failed_internal_link or
_Wikitext_rollback_failed_external_link functions.
Wincent Colaiuta [Thu, 7 May 2009 23:03:44 +0000 (01:03 +0200)]
Teach _Wikitext_append_hyperlink to check the autolink setting
Rather than checking the autolink setting in the numerous sites
where _Wikitext_append_hyperlink is called, move the check into
the function itself, and pass a flag in specifying whether to
perform the check.
The overall saving here is about 8 lines thanks to the eliminated
repetition.
Wincent Colaiuta [Thu, 7 May 2009 22:52:05 +0000 (00:52 +0200)]
Remove temporary string variable from _Wikitext_hyperlink
Now that _Wikitext_hyperlink returns void there is no longer any
need to use a temporary String instance. Instead, we append
directly to the parser->output buffer, thus saving an allocation.
Wincent Colaiuta [Thu, 7 May 2009 22:30:54 +0000 (00:30 +0200)]
Add comment justifying the scope_includes_space variable
This comment serves as a reminder for why this variable exists
(to remember what was on the stack prior to popping); without
it the reader might ask "why do we have a temporary variable
here which is only used once?".
Wincent Colaiuta [Thu, 7 May 2009 15:57:32 +0000 (17:57 +0200)]
Remove stale comment
This comment is a left-over from the distant past when many of
these functions were explicitly marked as inline functions,
rather than letting the compiler decided when to inline.
Wincent Colaiuta [Thu, 7 May 2009 09:35:57 +0000 (11:35 +0200)]
Use absolute paths in internal "requires"
Ensure that when locally testing or otherwise using a specific
version of the extension that the files included using "require"
come from the same version and not from some other version in the
load path.
For example, prior to this commit, doing an:
irb -r ext/wikitext lib/wikitext/string
Would not produce the desired result. First the local copy of the
extension would be loaded, then the local "lib/wikitext/string",
but then the latter would do a "require 'wikitext/parser'", which
would load the first corresponding file in the load path (usually
the latest installed gem), which would in turn do a "require
'wikitext'" and end up loading the first corresponding file in
the load path.
Wincent Colaiuta [Wed, 6 May 2009 23:03:58 +0000 (01:03 +0200)]
Specify ":indent => false" default in wikitext/string extension
Seeing as the String extension is primarily for use in Rails
applications, where setting up Haml to run with "ugly" mode turned
on is a good idea, it makes sense to make the "w" and "to_wikitext"
methods on the String class pass in ":indent => false" by default.
This can be overridden if desired by passing in an explicit indent
such as ":indent => 0".
Wincent Colaiuta [Wed, 6 May 2009 22:02:46 +0000 (00:02 +0200)]
Add support for "absolute" image "src" attributes
Under the default settings input like "{{foo.png}}" will be translated
to an "img" tag with "src" attribute of "/images/foo.png".
With this commit, we provide a shortcut for breaking out of the "prefix"
directory: any target beginning with a slash will be interpreted as
"absolute". So input like "{{/foo.png}}" will yield a "src" of
"/foo.png".
This is a somewhat prettier mechanism than using inputs like
"{{../foo.png}}", which already worked under the current translator.
Previously we accepted buggy input like "[[ ]]", "[[ ]]"
and "[[ |foo]]" and dutifully turned it into empty links
like:
<a href="/wiki/"></a>
And:
<a href="/wiki/">foo</a>
It clearly makes no sense for a bad link like "[[ ]]" to
take the user back to the wiki index, so now we spit out
these bad links verbatim to provide feedback to the user
that there's something wrong with their input.
Wincent Colaiuta [Fri, 27 Mar 2009 12:42:49 +0000 (13:42 +0100)]
Fix PRE_START and BLOCKQUOTE_START following shorthand
This adds a special case for PRE_START and
BLOCKQUOTE_START tokens which immediately follow
PRE and BLOCKQUOTE shorthand lines.
Basically, if they appear in the first column
then they are valid, because they close the old
(shorthand) blocks and open a new block. Anywhere
other than the first column they are considered
illegal.
Wincent Colaiuta [Fri, 27 Mar 2009 11:03:35 +0000 (12:03 +0100)]
Consistently apply "mailto" class to mailto URIs
Implement more consistent CSS styling given mailto URIs.
The following inputs previously received "external" CSS
styling because mailto URIs are tokenized as URIs rather
than MAIL tokens:
Wincent Colaiuta [Mon, 23 Feb 2009 21:39:01 +0000 (22:39 +0100)]
Accept options hash in "to_wikitext" and "w" methods
Seeing as "w" is the most frequently-used means of translating
wikitext in the context of a web application, it makes sense to
provide a means of passing in an optional options hash so that
overrides can be conveniently fed into the parser on demand.
Wincent Colaiuta [Mon, 23 Feb 2009 11:28:52 +0000 (12:28 +0100)]
Add "base_heading_level" option
An integer between 0 and 6 denoting the current "heading level".
This can be used to inform the parser of the "context" in which
it is translating markup.
For example, the parser might be translating blog post excerpts
on a page where there is an "h1" title element for the page itself
and an "h2" title element for each excerpt. In this context it is
useful to set base_heading_level to 2, so that any "top level"
headings in the markup (that is "h1" elements) can be automatically
transformed into "h3" elements so that they appear to be
appropriately "nested" inside the containing page elements.
In this way, markup authors can be freed from thinking about
which header size they should use and just always start from "h1"
for their most general content and work their way down.
An additional benefit is that markup can be used in different
contexts at different levels of nesting and the headings will be
adjusted to suit automatically with no intervention from the
markup author.
Finally, it's worth noting that in contexts where the user input
is not necessarily trusted, this setting can be used to prevent
users from inappropriately employing "h1" tags in deeply-nested
contexts where they would otherwise disturb the visual harmony of
the page.
Wincent Colaiuta [Fri, 13 Feb 2009 17:28:33 +0000 (18:28 +0100)]
Ruby 1.9: add magic comments to indicate source file encoding
Lots of these spec files are actually in UTF-8. Ruby 1.8.6
just slurped them in as byte streams so they just worked, but
1.9.1 expects them all to be ASCII and complains when they are
not.
We add these "magic" comments so that Ruby 1.9 knows that the
files are UTF-8-encoded and won't complain.
Wincent Colaiuta [Tue, 3 Feb 2009 22:48:00 +0000 (23:48 +0100)]
Fix subtle Rakefile breakage
As mentioned in b12cb25, the 1.4.0 release was broken due to a misfire
during "rake package".
The diagnosis was as follows; before each of the following tests, a
"rake clobber" was executed to start with a clean slate:
- "rake gem": "make" does appear to be executed,
but produced gem is incomplete
- "rake make; rake gem": produced gem is complete
- "rake package": "make" does appear to be executed,
but produced gem is incomplete
- "rake make; rake package": you can see "clobber"
task getting executed, then "make"; you would
expect this automated "make" not to work seeing
as it is broken in two other cases above, but
the built gem is complete and it works!
Specifically, in the incomplete gems, the generated
extension Makefile has these lines:
Note that the Makefile in the sourcetree in all of these tests
was correct; it was only the file generated from the gems that
was incorrect.
Further inspection showed that the wikitext_ragel.c file was not
included in the gem. This was the key; the file was missing
from inside the gem even though it was correctly generated outside
while building the gem. Naturally, the Makefile was also missing the
file ("mkmf" generates the SRCS and OBJS lines based on what it
finds in the directory).
The reason the file was missing was that the "files" entry in the
Gem specification was evaluated too early, before the dependencies
in the tasks had been executed, and before the "wikitext_ragel.c"
file even existed.
Running "rake make" manually beforehand was enough to make
everything work because it ensured that the "wikitext_ragel.c"
file was present at the time the Gem specification was evaluated;
even though the file was later clobbered and rebuilt it didn't
matter because the "files" entry was correct.
It would have been nice for the gem build to fail due to the
missing file. I would have been alerted then to the fact that
1.4.0 was broken; I'm going to see if I can make the build process
barf in the face of a missing file like that.
Wincent Colaiuta [Tue, 3 Feb 2009 21:49:34 +0000 (22:49 +0100)]
Bump version number prior to 1.4.1 release
This version is basically identical to 1.4.0 but the 1.4.0 gem that was
published on RubyForge was faulty due to an as-yet unexplained bug in
Rake or the Rakefile.
The gem was made using "rake package", which produces a gem which
passes all the specs but which is missing the required object file,
wikitext_ragel.o. "rake clobber; rake package" also suffers from the
missing object file.
"rake clobber; rake make; rake package", on the other hand, does
include the required file.
So for now I want to get a new release out to replace the broken gem
on RubyForge; will investigate the Rake/Rakefile bug subsequently.
Wincent Colaiuta [Sun, 1 Feb 2009 21:28:29 +0000 (22:28 +0100)]
Bump version number prior to 1.4.0 release
As this release involves a compatiblity-breaking change
(the replacement of "special" links in internal link spans
with "path" links in external link spans) bumping the release
number up to 1.4.0.
Wincent Colaiuta [Sun, 1 Feb 2009 21:03:47 +0000 (22:03 +0100)]
Create "special links" from external rather than internal links
It was a clumsy design decision to offer detection of "special links"
inside internal links:
[[/issues/20 | ticket #20]]
A much nicer syntax is to use external links instead:
[/issues/20 ticket #20]
In this commit I rip out the old implementation as well as a
supporting instance variable (treat_slash_as_special), and a
couple of related low-level struct members used at the C
level (treat_slash_as_special and special_link) which were
themselves all probably evidence of "design smell".
In place of the old feature we move handling of "path"-style
links to inside of external links. Specs and docs are updated
accordingly.
Wincent Colaiuta [Tue, 6 Jan 2009 00:55:58 +0000 (01:55 +0100)]
Toggle default value of space_to_underscore
I think the original choice for this was overly conservative, despite
the reasoning mentioned in the documentation:
Converting spaces to underscores makes most URLs prettier, but it
comes at a cost: when this mode is true the articles "foo bar" and
"foo_bar" can no longer be disambiguated, and a link to "foo_bar"
will actually resolve to "foo bar"; it is therefore recommended
that you explicitly disallow underscores in titles at the
application level so as to avoid this kind of confusion.
In reality, basically everyone using the wikitext module to power an
online wiki (that is, all of the users?) will want neat underscores
in their URLs rather than ugly "%20" escapes.
Wincent Colaiuta [Mon, 5 Jan 2009 17:37:56 +0000 (18:37 +0100)]
Bump version number for 1.3.1 release
This is a bugfix release, and includes new specs against current
Rails (2.2.2 and edge) to catch possible breakage which might occur
in the future if the Rails API keeps changing.
Wincent Colaiuta [Mon, 5 Jan 2009 17:35:47 +0000 (18:35 +0100)]
Add tests against Edge Rails
Note that these tests will fail if a pre-0.4.0 version of the rack gem
is installed, because Edge Rails itself current borks under those
circumstances (rake refuses to run with older versions).
Wincent Colaiuta [Mon, 5 Jan 2009 17:01:38 +0000 (18:01 +0100)]
Spew diagnostic text to console in the event of an error
We want the Rails tests to be totally silent, but only when things
actually work. In the contrary case we spew everything to the console
for diagnostic purposes.
Wincent Colaiuta [Mon, 5 Jan 2009 16:43:09 +0000 (17:43 +0100)]
Add low-level "run" method to Rails specs
First step in allowing us to run these specs silently; the run method
is a low-level method that runs a command with the given arguments,
silently recording the stdout, stderr, and exit status for later
retrieval.
Wincent Colaiuta [Mon, 5 Jan 2009 11:26:32 +0000 (12:26 +0100)]
Initial set-up for tests against Rails
This isn't actually the final form in which I am likely to run these
tests but it lays down the basic prerequisites for actually being
able to test the extension against different versions of Rails.
Here we actually fire up a server to test the full stack; I suspect
that I nicer way of doing this will be to use Rails' built-in
integration tests instead.
Wincent Colaiuta [Sun, 4 Jan 2009 18:23:19 +0000 (19:23 +0100)]
Prepend "lib" path to load paths for specs
Previously we only prepended the "ext" directory to ensure that the
just-built version of the extension would be tested by the specs, but
soon will be making use of files in the "lib" directory as well from
inside the specs, so prepend that as well.
Wincent Colaiuta [Sun, 4 Jan 2009 05:24:26 +0000 (06:24 +0100)]
Fix breakage caused by recent Rails API changes
The API has now changed so many times in unfathomable (uncommented) ways
that I'm no longer going to support older versions of Rails. The runtime
checks for all the myriad variations are just getting too complicated
and I can't justify maintaining them, especially seeing as I have no
intention of keeping old Rails installations on hand for the purposes of
testing.
The present version is tested and works with Rails 2.2.2. I actually had
a couple of intermediate, but uncommitted, unreleased changes, that I
needed to keep other versions of Rails working (2.1.0RC1, for example).
In the end those changes were short-lived because the API was changed
repeatedly afterwards.
In the latest rounds of changes, the "compilable?" method is no longer
checked, "call" is now invoked anyway, and Rails then proceeds to
evaluate the returned string as Ruby code in some unknown context where
"template" is a local variable! The "render" method is no longer called.
spec: prepend to load path to ensure development version gets tested
We were appending to the load path so we could conceivably end up with
a previously installed version of the extension getting tested instead
of the just-built version, so prepend instead.
In the hope that a fix for Rails bug #324 will be landed soon this
commit adds a rails/init.rb file to make using the wikitext gem in a
Rails application even easier.
Like the methods added to String, these are only added if the user
explicitly requires 'wikitext/nil_class'. They add a "w" and a
"to_wikitext" method to the NilClass.
This in turn enables code which might look like this:
git.wincent.com / wikitext.git / log
