cocoaforge

evands wrote:Pity. That's a pretty awkward change to get around a bug that only affects long links.

Here's a thought.

What if I check the innerHTML of the <a> to see if it starts with http:// if it does then we know that it's a link and not custom html that the user input. If it starts with http:// then it shows up as [link] and if it's not it shows up as whatever you put?

I don't truthfully care all that much about the URL problem it's just that the 'correct' fix is a long ways away and this is something I've gotten a lot of requests for from users.

Thoughts?

Links can be in the form of http://www.example.com as well. Unlike iChat, no http prefix is required.

Macskeeball wrote:Links can be in the form of http://www.example.com as well. Unlike iChat, no http prefix is required.

True but then again, problem links are usually ones that people copy and paste from the browser since they are very very long. Short links like http://www.adiumx.com aren't an issue.

hmm.. I dunno. Maybe I'll let this idea sit for a while.

The problem with trying to be 'smart' is that you'll never be 'smart' enough. There's already a lexical link parser in Adium that has dozens of cases (IIRC) of valid syntaxes for URL formats and you'd likely need to re-implement this in some accessible mechanism within the WebKit view [in JS or whatever] which may be easy [don't know], but replicating a chunk of application functionality to work around a framework display bug is like mashing a potato with an anvil IMO

Thanks for the reality check guys.
I'll just accept the problem and wait for the fix

I could expose the link parser to js... but it'd be in 1.0 and would shortly be obsoleted by a webkit update.

Catfish_Man wrote:I could expose the link parser to js... but it'd be in 1.0 and would shortly be obsoleted by a webkit update.

And three performance kittens might need to be sacrificed. Think of the kittens.

bgannin wrote:is like mashing a potato with an anvil IMO

they come out the best that way