| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
| |
If a page that looks like an email address exists, it can't be linked to.
But that's unlikely. Better to be consistent; before this change, a
wikilink with an email address in it could link to the email address or a
page, depending on when the page was created and when the page with the
link was updated.
|
| |
|
|
| |
brokenlinks list.
|
| |
|
|
|
|
| |
This way, an email-like link will be a mailto until a matching page
is created, then it will link to the page. And removing the page will
convert it back to a mailto.
|
| |
|
|
|
|
|
| |
At least two bugfixes in here. First, an old bug;
\[[foo#0]] was displayed as [[foo]], losing the anchor
as the anchor text was false. Secondly, a new bug;
an email like foo#bar@baz should not check bestlink("foo@baz").
|
| |
|
|
|
|
| |
Fully validating the email address is not necessary,
all that matters is not matching an url like http://foo@bar/
as an email address.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following ways to create a link are supported now:
[[url]]
[[text|url]]
url can be one of the following:
- an internal wikilink: will be handled as before
- any other kind of URL, including mailto: proper links will be created:
<a href="url">url</a>
<a href="url">text</a>
- an email address:
<a href="mailto:url">url</a>
<a href="mailto:url">text</a>
|
| |
|
|
| |
plugins from the setup file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is sorta an optimisation, and sorta a bug fix. In one
test case I have available, it can speed a page build up from 3
minutes to 3 seconds.
The root of the problem is that $links{$page} contains arrays of
links, rather than hashes of links. And when a link is found,
it is just pushed onto the array, without checking for dups.
Now, the array is emptied before scanning a page, so there
should not be a lot of opportunity for lots of duplicate links
to pile up in it. But, in some cases, they can, and if there
are hundreds of duplicate links in the array, then scanning it
for matching links, as match_link and some other code does,
becomes much more expensive than it needs to be.
Perhaps the real right fix would be to change the data structure
to a hash. But, the list of links is never accessed like that,
you always want to iterate through it.
I also looked at deduping the list in saveindex, but that does
a lot of unnecessary work, and doesn't completly solve the problem.
So, finally, I decided to add an add_link function that handles deduping,
and make ikiwiki-transition remove the old dup links.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
too many plugins.. brain exploding..
|
| |
|
|
|
|
| |
Have to convert link text to page name going in.
And on the way out, need to replace spaces with underscores in the link
text, which is not normally done with titles.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Implemented for regular wikilinks, with a test suite.
|
|
|
custom, first-class types of wikilinks.
* Move standard wikilink implementation to a new wikilink plugin, which
will of course be enabled by default.
|