Cloudef
commented
7 months ago The decoupling of displayed text and returned text seems useful to me. I would put the regex filtering to common.c instead though so that bit wouldn't be part of libbemenu thus only bemenu and bemenu-run executables would link against pcre
I've been maintaining this patch for a while, which I use a lot:
https://github.com/Cloudef/bemenu/compare/master...diegov:bemenu:pcre_formatting_rebase_202308
The use case is to send some sort of structured item strings to bemenu, have it display part of each item, but use the rest of it for the subsequent action on the selected item. Eg. I might use
bemenu --df '(^[^\x1f]*)'and pass it lines consisting of a Bluetooth device address, the separator, and the device name, with only the device name being displayed by Bemenu.I haven't really considered a PR until now, because it would add an extra dependency to Bemenu, and it didn't seem to fit the philosophy of the project. Also adding a conditional feature and selecting the libpcre version in a plain Makefile would introduce a level of complexity into the build process that I assume has been intentionally avoided until now.
Is this kind of optional feature worth adding to Bemenu?
On top of the Makefile work, there's testing, documentation and some TODOs at the very least that I would need to address to make this PR-ready, but I'd be glad to work on that if there's a chance we can merge it. Also I can make any other requested changes or even take a different approach to it if the current implementation is not suitable.