[Feature request] Interactive / live-edit mode

[ronjouch]

Hi, I found your project on Reddit and it looks great. But I can't get it to work:

12:09:15 /opt/crex (master|✔) ./build.sh

Setting Environment Variables

Building crex in Debug mode

Compiling crex
ccache found
CMAKE_BUILD_TYPE is Debug
-- Configuring done
-- Generating done
-- Build files have been written to: /opt/crex/build/debug
[100%] Built target crex

real    0m0,022s
user    0m0,013s
sys     0m0,009s
12:09:20 /opt/crex (master|✔) env APP=crex /opt/crex/build/debug/crex
12:09:33 /opt/crex (master|✔) ✘ echo $status
1

This is on Ubuntu 18.04.1. Ideas?

[ronjouch]

Ah, I misunderstood the README & screenshot; I thought crex would be an interactive tool. It's not, and you need to pass minimally -s and -r flags. So, thoughts:

• An interactive mode would be neat, to iterate and have immediate feedback. Here I don't see much value compared to running a regex.test/search in perl or node.
  EDIT reading Reddit comments I'm echoing this comment:

  +1 for a live editing mode. One of the use-cases for sites like regexr is that you can see matches on your input text as you create the regex. Being able to incrementally build patterns is invaluable for me, as someone who builds a lot of text processing systems that utilize permanent regexs heavily. This seems great for cases where you have a one-time use pattern, but those cases are already pretty well served by the existing gnu and bsd toolchains, so you're fighting inertia.

• If no argument is passed, it's good to return 1, but crex should also echo its --help

Anyway, thanks for the work 🙂! Renaming the issue.

[octobanana]

Thanks for the feedback!

I agree it should be more clear about the required options to run. The following commits cf56a6d and 6844912 should fix that. It outputs the help when the required options are missing, and shows more descriptive errors.

If you are comfortable using perl or node to do something similar, then that's great! I'm all for using the right tool for the job. In my case, I have very limited experience with perl one liners, and I don't use node that often. I don't think the perl or node output would be coloured by default, so I would see that as a plus for crex.

An interactive mode would be neat. I made crex as a cli program instead of a tui because it allows one to use the terminal scroll back to view previous matches, and the shell history + fzf gives an easy way to search, alter, and run previous commands. My concern for an interactive mode is that I would want to avoid reinventing a sub par text editing experience for editing the regex and text when programs like vim and emacs already exist.

What about a semi interactive mode, where the text to search is passed in, the regex could be changed using a readline-like library, and on each change of the regex, dynamically change the text and matches below. Perhaps the text to be searched could be read from a file, and a keybinding would allow the file to be re-read, allowing a proper text editor to be used.

What are your thoughts?

[ronjouch]

@octobanana

"commits cf56a6d and 6844912 should fix that. It outputs the help when the required options are missing, and shows more descriptive errors."

Yay 🙂, thanks!

An interactive mode would be neat. [...] What are your thoughts?

I also ♥ my fzf+history, but in the end I think we just have different priorities: I prioritize being able to quickly play with regexes with live feedback more that having all my attempts in the history. And you seem to be more picky about editor experience than I am; I'm fine fiddling with arrow keys in a terminal.

But thinking of it, if as you mentioned, you provide some --regex-file flag, a pseudo interactive mode would be easy with the awesome entr tool:

echo 'myregex.txt' | entr crex --regex-file='myregex.txt' --string='my test string'

I'd like that: respects your original intent, minimal, documentable, and unix-y 🙂. Also, when reading the file, crex could only read the first line (or if multiline regexes are supported, stop reading at the regex end token), leaving users just hit enter a few times to keep the current regex "archived"; that would also cover your concern of keeping a history of previous regexes 🙂. The file would look like:

[a-z][A-Z]+        <-- the current regex, read by crex on `--read-file`

// Archives -----------------------------------------------------------

// Find everything
.*

// US phone number
\d{3}-\d{3}-\d{4}

// etc
...

Thoughts?

[octobanana]

The entr tool is great! After playing around with it for a bit, the following command seems to work well:

printf "regex.txt\ntext.txt\n" | entr -c -s 'cat text.txt | crex -oc -r "$(head -1 regex.txt)"'

Where:

• regex.txt - the first line contains the regex, other lines are not read, so they could be used to store other regexs
• text.txt - the file that the regex will act on
• entr -c -s - -c runs /usr/bin/clear before invoking the commands, -s sends the first argument to be evaluated by the SHELL environment variable allowing expansions to take place

It could be written as a shell script for easier usage.

#!/usr/bin/env bash
set -e

# name: crexi
# info: crex interactive mode using entr

if [[ $# == 2 ]]; then
  printf "$1\n$2\n" | entr -c -s "cat ${2} | crex -r \"\$(head -1 ${1})\""
elif [[ $# == 3 ]]; then
  printf "$2\n$3\n" | entr -c -s "cat ${3} | crex ${1} -r \"\$(head -1 ${2})\""
else
  printf "crexi: crex interactive mode using entr\n\n"
  printf "usage: crexi <file_regex> <file_text>\n"
  printf "       crexi <crex_flags> <file_regex> <file_text>\n\n"
  printf "ex:    crexi regex.txt text.txt\n"
  printf "       crexi -oc regex.txt text.txt\n"
  exit 1
fi

Whenever the files are saved, the output gets updated making for a pretty decent interactive mode.

I think it could be made better by having flags that allow toggling what information is shown on output, the information being the regex, text, matches, and groups.
Also, the -i case-insensitive flag might be better suited if it was moved to be a part of the regex with the form /<regex>/<flags>. This would allow toggling within the regex file while using this semi-interactive mode.

If you try this out, let me know how it works!