Few things I'd add here, using this command rather extensively.

Add support for multibyte values of multiple encodings, such that the user need only specify the unicode codepoint and mirc does the work to find/replace encoded values according to -switch.

So /breplace -u might support all multibyte unicode forms such as UTF8, UTF16, and Windows DBCS (double byte). When a match is discovered to any of the supported encoodings, a replacement is made of the same encoding type. This may mean a necessary shrink/grow of the variable. If -u8 or -u16 or -ud are specified, then only that single encoding is used. -u would default to encoding to UTF8 when the replace value is >127 AND the find is only ASCII, and -un would never encode replacement values between 128 and 255, leaving them as bytes (like with the /raw command).

I like your idea using commas. If no commas present, treat each space-delimited value as alternating find/replace as before. If a comma is present, then treat the whole command as comma-delimited substrings alternating find/replace. This also permits insertions and deletions, where a find match is deleted if paired with ab empty replacement value, or multiple bytes are inserted at the match. A find value could also be a whole series of bytes or unicode codepoints as you describe above.

If possible, also add support for plain text substrings. Automatic detection or -t switch. Plain text strings could also utilize the -u switches and comma delemitation. $chr(44) for literal commas in text strings.

These suggestions shouldnt deviate far from the purpose of /breplace, and would go far for supporting intl language, unicode doublebyte file/memory strings, and allow greater editing of file format headers, TCP protocols, etc.

It's no regex, but valuable none the less.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!