File: re-builder.el.html

When I have to come up with regular expressions that are more complex than simple string matchers, especially if they contain sub expressions, I find myself spending quite some time in the development cycle. re-builder aims to shorten this time span so I can get on with the more interesting bits.

With it you can have immediate visual feedback about how well the regexp behaves to your expectations on the intended data.

When called up re-builder attaches itself to the current buffer which becomes its target buffer, where all the matching is done. The active window is split so you have a view on the data while authoring the RE. If the edited expression is valid the matches in the target buffer are marked automatically with colored overlays
(for non-color displays see below) giving you feedback over the
extents of the matched (sub) expressions. The (non-)validity is shown only in the mode line without throwing the errors at you. If you want to know the reason why RE Builder considers it as invalid call reb-force-update ("\\C-c\\C-u") which should reveal the error.

The target buffer can be changed with reb-change-target-buffer
("\\C-c\\C-b"). Changing the target buffer automatically removes
the overlays from the old buffer and displays the new one in the target window.

The re-builder keeps the focus while updating the matches in the target buffer so corrections are easy to incorporate. If you are satisfied with the result you can paste the RE to the kill-ring with reb-copy ("\\C-c\\C-w"), quit the re-builder ("\\C-c\\C-q") and use it wherever you need it.

As the automatic updates can take some time on large buffers, they can be limited by reb-auto-match-limit so that they should not have a negative impact on the editing. Setting it to nil makes even the auto updates go all the way. Forcing an update overrides this limit allowing an easy way to see all matches.

Currently re-builder understands three different forms of input, namely read, string, and rx syntax. Read syntax and string syntax are both delimited by "s and behave according to their name. With the string syntax there's no need to escape the backslashes and double quotes simplifying the editing somewhat. The rx syntax allows editing of symbolic regular expressions supported by the package of the same name.

Editing symbolic expressions is done through a major mode derived from emacs-lisp-mode so you'll get all the good stuff like automatic indentation and font-locking etc.

When editing a symbolic regular expression, only the first expression in the RE Builder buffer is considered, which helps limiting the extent of the expression like the "s do for the text modes. For the rx syntax the function rx-to-string is applied to the evaluated expression read. So you can use quoted arguments with something like '("findme") or you can construct arguments to your hearts delight with a valid Elisp expression. (The compiled
string form will be copied by reb-copy) If you want to take
a glance at the corresponding string you can temporarily change the input syntax.

Changing the input syntax is transparent (for the obvious exception non-symbolic -> symbolic) so you can change your mind as often as you like.

There is also a shortcut function for toggling the case-fold-search variable in the target buffer with an immediate update.

Q: But what if my display cannot show colored overlays? A: Then the cursor will flash around the matched text making it stand
   out.

Q: But how can I then make out the sub-expressions? A: That's where the sub-expression mode comes in. In it only the
   digit keys are assigned to perform an update that will flash the
   corresponding subexp only.

Defined variables (25)

Defined functions (41)

Defined faces (6)