just some short answers, let me list some advantages in comparison to your method:
Furthermore, from a emacs perspective, the elisp-code is _very_ short and simple, facilitating personal changes in just this module.
(For instance I would like to run a command to take a snapshot of the three windows, and to append it persistently to my tests. And vice versa I would like to select just one of these tests again to continue interactive testing. One doesn't need deep knowledge of elisp to do this, since one can simply pipe any window's text in and out a perl-script to transform it.)
Did you ever think (or try) to change the code in cperl-mode.el? It's a huge monolithic block of over 4000 lines, unfortunately it's not broken up into smaller modules... it's very hard to realize changes which will survive the next update.
Of course your technique or the other mentioned in Composing regular expressions at runtime give experienced coders deeper testing possibilities for complicated code ... but if one is either new or in "brainless-mode" and doesn't want to code a loop it's a very good start. Talking about shell-support, you might wanna give sepia a try, it's full perl REPL integrated into emacs, of course with history functions.
Furthermore it should be possible to tweak the perldebugger into a regex-tester with history cache, one can add aliases for personal commands and the docs mention pre and post commands to run with each prompt. (anyway I couldn't make the latter work using commands like <,> and { ...???)
Cheers Rolf
UPDATE: just found a note that it doesn't work with Xemacs :-( Sadly these incompatibilities are the main reason why I switched to Gnu Emacs a year ago, while I still recommend xemacs for newbies.
In reply to Re^2: [emacs] short review of regex-tool.el
by LanX
in thread [emacs] short review of regex-tool.el
by LanX
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |