URLs become plain inactive text after buffer length reaches ~30000. I checked this using (point). All URLs can't be opened with C-c RET after that, they aren't highlighted. It's a pain for active conferences. Ugly workaround: C-x C-k RET and then wait for message in that conference, a new buffer will be created with working URLs.
Turns out this is a feature:
goto-address-fontify-maximum-size is a variable defined in `goto-addr.el'.
Its value is 30000
Maybe goto-address should have an option to look at the _last_ 30000 characters instead...
I had a closer look at this, and I realised that I'm calling
goto-address
in a less than optimal way. By default, it looks at the entire buffer, but actually I'd just need to call it for the chat message being printed right now.So how would the function
jabber-chat-goto-address
know the extent of the message being printed? It knows the end already - that's(point)
. But to know the beginning, the only way I could think of is to search backwards for property changes that indicate the presence of the prompt. That would be theface
property being set to eitherjabber-chat-prompt-local
orjabber-chat-prompt-foreign
– except if you're using MUC nick colouring, in which case it's set to(:foreground SOME-COLOUR)
. Currently there isn't any other function which might want to set such a face attribute, but this still feels suboptimal to me. Perhaps there should be another attribute that explicitly indicates the presence of the prompt, and thus the start of the message – or perhaps some other mechanism for the same purpose.The attached patch seems to work well enough for now. I'll try to figure out the best, cleanest, way to solve this...
I have sort of convinced myself that the right thing to do is to mark the chat prompt as a field, and use that to figure out where to start URL highlighting. I pushed this change; let's see how that works.