add more types of links to be ignored (like mailto)

Arg. It's tough, because colons are legit characters in Drupal paths; "foo:bar?baz", however unlikely, could easily be a legit Drupal path.

Maybe just ignoring paths with colons like this would be the best way, and let that break whatever it breaks…

Isn't it very strange that links to other applications do not use their own protocol prefix? It would have been a lot easier if email links looked like "mailto://me@example.com" and so on. Isn't there an RFC document on this which we can obey?

Well, the colon is the standard. In fact, The problem is that the bits after that can define whether they can have a colon in them. HTTP is actually sort of the odd one out for doing the double-slash thing (FTP is another exception, though it works if you think of FTP as a giant filesystem). In fact, Sir Tim Berners-Lee has said he regrets adding the slashes to the HTTP URL scheme…

Wow, thats very interesting. Since colon is more often used to specify protocol, then I think that paths that look like ~^\w+:~ should be treated like protocols and ignored by Pathologic. If it is absolutely necessary to make a link to a Drupal path which contains the colon, it could always be added using an absolute URI instead.

i would add the following (for 6.0 versions of pathologic as well):
javascript:Drupal.FieldsetHelper.expandFieldsets();

6.x-3.x-dev still doesn't support collapsible fields in a node. Below is sample code.

<a href="javascript:Drupal.FieldsetHelper.expandFieldsets('#1571-1 fieldset.collapsible');">Expand all</a> | <a href="javascript:Drupal.FieldsetHelper.collapseFieldsets('#1571-1 fieldset.collapsible');">Collapse all</a><fieldset class="collapsible collapsed"><legend title="Click here to expand/collapse this topic">Legend Text</legend>Fieldset Text</fieldset>

Yeah, I… it's… I mean, 2011, and you're using "javascript:", and uh…

Sorry Dr. Albright, but I'm not a programmer and your humor has escaped me.

We use Pathologic 6.x-2.0-beta23 and it works just fine. We get "no longer supported" error messages whenever an update is run, for which I thought it would be prudent to upgrade to a later version of Pathologic. If you're saying javascript: is no longer compatible with Pathologic then I can get my guys working on an alternate solution. You should change the status of this issue to closed.

Great module for the time being though ... quite helpful in migrating between the hosted version and localhost.

K

Sorry Dr. Albright, but I'm not a programmer and your humor has escaped me.

Way back in 1995 or so, when web browsers first started being able to use JavaScript, using "javascript:" URLs to run scripts was the norm, but nowadays there are far better ways to do so and doing this these days is very bad form for various reasons, not the least of which being that it makes the link completely useless to someone with JavaScript disabled in their browser. So you're basically complaining that my code doesn't work when you try to use it in a way which became blissfully obsolete about ten years ago.

All that being said… Have you tried adding "javascript:" to the "Paths considered local" field?

adding javascript: to the 'paths consider local' configuration field did not help.
I have redirected this issue over to the author of the Fieldset Helper module from whence the javascript: code originated.
The issue in that module is found here: http://drupal.org/node/1316186

Hello!
I just wanted to add to the javascript: problem:
I too experienced problems on a simple print icon block with a javascript:window.print(); command.
Though handling this via theme scripts will work, it's not an uncommon usecase and a hassle of mixing up theme and site, so thumbs up for any „ignore paths beginning with“ parameter.

Adding „javascript:“ to the local paths removed it from the link completely, btw.

I think anything inside a <code> block should be ignored as well.

Edit: you can disregard the above. I was misunderstanding the problem we had. I think fixing the above is just a matter of ordering your filters properly, so that pathologic runs after <code> blocks are processed.

Closing for now.