Forums Feature Suggestions HOTLINK: Allow passing parameters to /hotline

When creating a context menu using /hotlink -m, it would be great to be able to pass parameters, to be used as $1, $2... inside the menu:

Example: Let's assume the following:

I want a menu entry, that displays something like:
"Found 1"


This is not possible. The result is:

because $1 in the menu is always the hotlink-word.


Also $hotlink(...), $hotline, $hotlinepos are not available inside the menu, so I can't move the $regex part in the menu definition.

The only workaround I can think of is something like


and in the menu add something like


But this is rather ugly

I find the whole event structure rather strange. Here's how mine goes:

First I need to decide if I want the word hotlinked. For this, I check if it's a mouse event. I do some parsing, and then return.

Now when it's double clicked, I want to take action. But I want to take action on what I've already parsed. To avoid reparsing, I needed to set global variables in the mouse check because local variables are not available in this new event call.

Then, if it's right clicked I want to use those same parsed variables for a menu. Good thing they're global already, because you can't pass them to the menu and the menu has no knowledge of the context in which it was created (the hotlink identifiers).

So I need to have a mess of global variables floating around, or use arbitrary timeouts to somewhat alleviate the issue.

This retriggering of the event bares a resemblance to retriggering of a sockread, where local variables and such are lost as well. Sockets I feel are a larger entity, and so maintaining a data structure through all the various events is the way to go. Having to maintain a similar structure in this event however seems out of place.

AFAIK this won't (can't) be supported. There are technical reasons why you can't pass parameters to menus if you require menus to co-exist with each other. For instance, if script A adds "menu @test" to the popup with param "FOO", and script B, which also matches the hotlink, tries to add "menu @test2" with param "BAR", what should $1 be? It also means scripts have to run synchronously, which means /hotlink would *immediately* invoke the popup, which is again problematic when you have to collect popup definitions from multiple events. The design is a product of a compromise on functionality vs elegance.

If you need to pass a parameter to a menu, you should be doing it through a global variable. This is not a workaround, it is the expected solution. "Ugliness" isn't really a significant issue here. In fact, this is how you would otherwise communicate with any other popup, so it's no less elegant than how scripts were previously written.