43 lines
1.4 KiB
Plaintext
43 lines
1.4 KiB
Plaintext
Write Texinfo documentation for grep. The manual page would be a good
|
|
place to start, but Info documents are also supposed to contain a
|
|
tutorial and examples.
|
|
|
|
Fix the DFA matcher to never use exponential space. (Fortunately, these
|
|
cases are rare.)
|
|
|
|
Improve the performance of the regex backtracking matcher. This matcher
|
|
is agonizingly slow, and is responsible for grep sometimes being slower
|
|
than Unix grep when backreferences are used.
|
|
|
|
Provide support for the Posix [= =] and [. .] constructs. This is
|
|
difficult because it requires locale-dependent details of the character
|
|
set and collating sequence, but Posix does not standardize any method
|
|
for accessing this information!
|
|
|
|
##
|
|
|
|
Some test in tests/spencer2.tests should have failed !!!
|
|
Need to filter out some bugs in dfa.[ch]/regex.[ch].
|
|
|
|
Threads for grep ?
|
|
|
|
Grep does 32 bits arithmetic, it needs to move to 64.
|
|
|
|
Clean up, to many #ifdef's !!
|
|
|
|
Check some new Algorithms for matching, talk to Karl Berry and Nelson.
|
|
Sunday's "Quick Search" Algorithm (CACM 33, 8 August 1990 pp. 132-142)
|
|
claim that his algo. is faster then Boyer-More ????
|
|
Worth Checking.
|
|
|
|
Take a look at cgrep (Context grep) seems like nice work.
|
|
Take a look at sgrep (Struct grep).
|
|
Take a look at agrep (Approximate grep), from glimpse.
|
|
Can we merge ?
|
|
|
|
POSIX Compliance see p10003.x
|
|
|
|
Moving away from GNU regex API for POSIX regex API.
|
|
|
|
Better and faster !!
|