Forums Feature Suggestions Avoid /timer parsing.

I've come across multiple situations in which it would be useful to have /timer avoid parsing { } and [ ] brackets and simply preserve all text in "<command>". I've been able to avoid single bracket sets parsing via $({ },0), but this does not work for multiple sets such as $({ { } },0). I can understand the need to, by default, parse timers' brackets upon its execution when a timer is executed within a script or via "//timer", but, on a side note, this feels incongruent with mIRC's normal behavior when using a single slash "/timer". Regardless, a "-n" switch (perhaps similar to the "n" parameter in $read) to avoid execution-time parsing would be very useful to avoid excessive escaping during high volumes of timers.

For example: /timer -n 1 1 echo -a { { hello } } would echo { { hello } } instead of simply hello as it does now. Note that I am not proposing to stop parsing when the timer is created, so //timer -n 1 1 echo -a Version: $version (or scripted execution) would still echo Version: 6.2 (for example).

Yes, I know a $regexsub or something of the like could probably take care of this fairly quickly, it just seems excessive and a bit advanced for the level of user for which I'm proposing this, who just wants all characters in <command> preserved.

This (and related usages) have been suggested before, use the Search and you will find for example this or this

As far as []'s do, use double to 'escape' them. I.e. instead of [, use [[. instead of ], use ]]. For a workaround with braces, set them to a variable:

var %lb = $chr(123), %rb = $chr(125)
.tiemr 1 5 %lb %lb Hello %rb %rb

I did use the search on multiple phrases, none of which contained those items, so please don't assume that I did not. It looks like Sat didn't find your initial post either. I likely found nothing because I searched for terms including "parsing," (since that's really what this post was regarding) and not "evaluation," they key word in your two references. I turned up a myriad of /timer items, but far too many to go through in a day.

Anyway, thank you for the references. Considering that it has been over a year since the post was active, it's probably about time that it was refreshed anyway, as there is still no easy workaround. It isn't a priority, no, but as you noted yourself, it would be handy.

To be specific, I'm discussing more along the lines of Sat's proposition for -n (avoid timer execution parsing) as opposed to yours (avoid timer setting evaluation [too?]), since it seems the hardcoding that is implied on yours can just as easily be done manually using $chr and $!, etc. (if I'm incorrect on this, let me know). Avoiding parsing execution, however, requires more than simple escape methods. Yes, $! can work for Sat's first example, but when you start involving arbitrary phrases from incoming IRC lines (especially brackets), this gets difficult/annoying to escape repeatedly. Hrung sums up my feelings best below:



In response to KingTomato: I appreciate the help, but the suggestion here (and on the other posts) revolves around avoiding excessive escaping. Both of those require a $regsubex to avoid replacing "attached" versions. The braces one also requires the external reference, which, if done within a script, I believe would evaluate already and we'd be back to square one. I'm sure we could figure out a way to escape everything, but that's a lot of excessive work to simply forward a text string. Thanks for offering those workarounds, though.

having an escape char would be great for use in the /timer command surely it would be the easiest thing to impliment anyway, perhaps starting the line with an \timer as opposed to normal / just thought.
and searching can be a pain in the facilities sometimes you might not know what exactly to search for and find little to nothing only to be told there are things. we all slowly learn though!

The difference between $({ { } },0) and $({ },0) isn't the number of bracket sets.. its the format. The first will fail because of mirc internal handling of '<space>?<space>' for certain brackets. Another way to avoid mircs internal handling of these, for now at least, is to use control charactors in front of them

Two ctrl+r's should do the trick, without affecting any other text formatting that is on or applied to the string. (dont need the $() then either)

It would be nice to see a better way to do this though, something similar in nature to the ! prefix, but to preserve all non vars/binvars/identifiers 'as is'.

/nod.

Sorry, I didn't mean to imply that it was the number of bracket sets. It's an issue of unattached brackets. If it were just all brackets, a simple $replace/$replacex would work. Like I said, the goal here is to get mIRC to stop that "internal handling" (parsing). The control code idea is a good one and would make for easy replacement of bracket/parsed characters, but it would also add significantly to the length of certain strings. Nevertheless, it seems like it might work as an easy temporary solution, so thank you for suggesting it.

I don't think an escape character is what we want here, since there are already methods (if annoying/excessive) to escape nearly everything. Rather, a switch to avoid parsing as previously proposed by Sat.