reddit / emacs
Is there a minor mode to highlight regular expressions in a buffer?
MitchellMarquez42 · 2022-03-20 03:11
Example of desired behavior:
#!/bin/sh
sed 's/^[1-9]*\.\s(.*)$/\1/g' file.txt
Where the `[1-9]` is one color, the `(.*)` is another color, and the `\1` is the same color. Or something similar.
Web searches seem to inevitably assume we're talking about _finding matches_ for the regex.
Is this a thing, or am I crazy for even wanting it?
EDIT: Apparently I am. Thanks for the suggestions anyway, folks.
KonpakuYoumu · 2022-03-20 03:53
M-s h r `highlight-regexp`
You will write a regular expression to highlight regular expressions. :-)
7890yuiop · 2022-03-20 04:09
> Is this a thing
I don't think so.
> am I crazy for even wanting it?
Maybe :)
Is this just for `sed` commands in shell scripts?
If not, what is it for (specifically), and what is your method for identifying regular expressions in each case?
(Your example is already complicated -- you want Emacs, while editing a shell script, to recognise that part of the shell script represents (in shell syntax) a sed script, and then to know how to add syntax highlighting (for the sed dialect of regular expressions) to the portion of that shell-escaped sed-script string which happens to be a regexp.)
holgerschurig · 2022-03-20 09:42
Beside highlight-regexp mentioned by /u/KonpakuYoumu there is also a package "symbol overlay" that can highlight symbols: https://github.com/wolray/symbol-overlay. It doesn't use font-lock, but overlay-put, so it coexists with normal font locking.
I use it for a subfeature: moving from symbol to an identical named symbols, even when I don't have eglot on. This is an excerpt from my keyboard mapping:
"M-<up>" #'symbol-overlay-jump-prev
"M-<down>" #'symbol-overlay-jump-next
kaushalmodi · 2022-03-20 13:07
I set the `hi-lock-file-patterns` to highlight different strings with different colors in a file by setting that as file local variable or in a .dir-locals.el. I set that variable as safe [in my emacs config][1] so that I don't get the "is it safe?" prompt each time I tweak the regexp for highlighting.
---
Seems like you are trying to highlight regexp strings in a file. So it might be a tough one to robustly write a regexp that correctly highlights the regexp groups consistently.
[1]: https://github.com/kaushalmodi/.emacs.d/blob/c643684ad675753c69df602d7298241d05173255/setup-files/setup-highlight.el#L47-L49
asymptotically508 · 2022-03-20 14:52
It's not exactly what you're asking for, but you could create an indirect buffer (`clone-indirect-buffer`, `C-x 4 c` by default), narrow it to the regexp, and then switch to a mode for editing regex.
MitchellMarquez42 · 2022-03-20 16:10
> Is this just for `sed` commands in shell scripts?
Ideally no. The idea is it would be possible to enable for any `prog-mode` buffer or anything.
I use regular expressions a lot for sh scripts, interactively, and for tweaking the editor. Sadly, Emacs seems to just put anything in "quotes" as `font-lock-string-face` which is boring. It's not a big deal. It would just be nice to see a little more contextual color in the buffer. I was asking here because Google and co. absolutely refuse to interpret the question correctly.
[deleted] · 2022-03-20 20:07
I am not sure that this is what Mitchell means. What he seems to be looking for is a semantic highlighting that would highlight matching groups of regular expression _itself_, not a match of said expression.
7890yuiop · 2022-03-20 20:54
I'd be honestly surprised if anything out there does this. The highlighter has to not only parse multiple different regexp dialects and multiple different programming languages, but also understand *how* the code will be executed (e.g. *this* shell string (or sub-string) winds up being used in sed code as a sed regexp, *this* shell string winds up being used in perl code as a perl regexp. It's a huge woolly task involving lots of static analysis of multiple languages simultaneously, and I doubt that the benefits would justify the effort.
sunpasta · 2022-03-21 21:24
symbol-overlay: great find !