Before that i used to write scripts or even full programs (in Free Pascal which has some simple string handling) to do similar processing and i did find it much more cumbersome to go through that route.
Of course this only works for editing/generated/transforming text pieces (and i pretty much always use it via clipboard), for processing files i still end up writing full scripts or programs (depending on the case, if i need to preprocess stuff i use another LIL-based tool, lip[4]).
[0] http://runtimeterror.com/tools/liteproc/
[1] http://runtimeterror.com/tech/lil/
[2] http://runtimeterror.com/tools/liteproc/shot.png
Never got around to making it properly interactive, because I stopped needing it when I switched to Emacs and had both its native capabilities and C-u M-| available.
And no, regexps get a bad rep but they are for the easy 99% and insanely quick to come up with. Learn basic syntax and you'll be thankful for decades to come.
Some allow "|", some allow backrefs, some allow "()", or require them escaped with \, or allow them but not with * after. Some are case insensitive, some not. Some allow "{0-5}", some allow "[0-9]", some have handy things like "\w".
It's just the guessing game of exactly what they want. It should be required that each regex box has an example next to it using as many allowed features as possible.
But that's _not_ regexp, it's glob; a totally different pattern matching system. I mean, you can call a duck a horse, but that doesn't mean you're right... or that there's anything confusing about horses.
What kind of scary tool is that?
> Some [people] by "regex" mean "globs"
>The Lua WAF uses PCRE internally and it uses backtracking for matching and has no mechanism to protect against a runaway expression.
https://blog.cloudflare.com/making-the-waf-40-faster/
>Back in July 2019, the WAF transitioned from using a regular expression engine based on PCRE to one inspired by RE2, which is based around using a deterministic finite automaton (DFA) instead of backtracking algorithms. This change came as a result of an outage where an update added a regular expression which backtracked enormously on certain HTTP requests, resulting in exponential execution time.
>After the migration was finished, we saw no measurable difference in CPU consumption at the edge, but noticed execution time outliers in the 95th and 99th percentiles decreased, something we expected given RE2's guarantees of a linear time execution with the size of the input.
He meant “syntax” in the sense that different regex engines have different syntax and capabilities - can I do a negative look ahead assertion in engines Z, how do I do a zero width lookaround in pcre, gnu, python, posix, etc.
Depending how far down the rabbit hole you want to go, start here:
I’d find it hard to ignore the specifics. I mean if you only ever use one tool and were never exposed to other regex engines I guess.
My own editor is written in Ruby, and so all extension is done by loading Ruby code into the running process, and I can drop into the Pry debugger with a keypress, or another keypress gives me a prompt to enter a single-line expression instead. The latter is literally a one-line method. Adding a binding to eval() a whole buffer would be equally trivial... Being able to extend everything trivially in a language I'm comfortable with (so not Emacs lisp) makes such a difference to usability.
Incidentally, the ability to interact with the open buffers using a script also from outside the editor is another thing I love as an extension mechanism for editors - an idea I first saw in FrexxEd (co-written by the founder of Curl) for the Amiga, which exposed the open buffers in the filesystem (think the Amiga equivalent of a FUSE filesystem), which would have the added benefit of not being language specific. It doesn't need to involve any FUSE-like stuff either - just a command line utility to "cat" an open buffer and to replace the open buffer from stdin would be sufficient.
E.g. I have functions in there to insert headers in my journal for example.
In terms of executing code "actually" live, it's ~80% for debugging when I work on the editor itself. Pry provides all of the plumbing so all the code needed to add that is just to suspend the editors own input handling and call pry, coupled with an exception handler that calls pry as well, so there was no reason not to, basically.
But once I'd added it, the 20% left felt worthwhile as a means of e.g. do complex searches, or generate tables or otherwise do search and replace of content that requires more (e.g. parsing timestamps and replacing them with another format....) and any number of things I don't do very often but that feels very comfortable when you do need it. To be clear it's not like it does much you can't do easily without it. E.g. after all I could just dump the buffer to a file, load it in my repl of choice, manipulate it and write it out again and reload it in my editor. It's one of those small things that feels unimportant when you don't have it there, that doesn't save you a huge amount of time, but that just makes things feel nicer when you get used to them.
The generic variant would be to make it modular and replaceable, but that would be a mistake, I would much rather have a tool good at a specific subset of jobs than a config heavy tool which is medicore at all. Perhaps advanced search and replace fits that, but I think its a fundamental aspect of editing.
Thats a good idea!