tests/yesno.sh, kinds of line (matching/non-matching, selected/rejected)

[Charles Levert]

I created a new test file, tests/yesno.sh.
(Test feature interaction of -C, -v, -o, and -m.)

Having more of these is never a bad thing, so
I went ahead and committed it to CVS right away.
It can always be modified to address the issues
it raises, or code and documentation can be.

On 2005-06-21, I committed a bunch of changes,
including a prline() cleanup and the GREP_COLORS
framework.  There is are problems with this,
although nothing that's hard to fix.
(And it did go unnoticed.)
It's more a matter of design choices.

Here is what I missed.  When -v is not specified, we have:

   selected lines =     matching lines = main printed lines
   rejected lines = non-matching lines = context lines (when within range)

When -v is specified, we have:

   selected lines = non-matching lines = main printed lines
   rejected lines =     matching lines = context lines (when within range)

Selected lines are printed using a ':' separator, if needed.
Rejected lines are printed using a '-' separator, if needed.

You can see by my design of the GREP_COLORS
framework that I just plain forgot about -v and
confused things:

   ml:  terminfo-like string capability for matching lines
   cx:  terminfo-like string capability for context lines

I also created the SEP_CHAR_MATCH,
SEP_CHAR_CONTEXT, and SEP_STR_CHUNK macros.
I will need to rename those SEP_CHAR_SELECTED,
SEP_CHAR_REJECTED, and SEP_STR_GROUP.  The last
one would just be to uniformize things with the
documentation.

But it goes further than this, since I introduced
some subtle bugs.  Again, nothing too complicated
to fix.  (I already fixed my private version.)

There is one remaining design issue.
Should I have created something like this:

   ml:  terminfo-like string capability for matching lines
   nl:  terminfo-like string capability for non-matching lines

Or, like this:

   sl:  terminfo-like string capability for selected lines
   rl:  terminfo-like string capability for rejected lines

The second color of either pair is usually
chosen to be more understated than the first,
assuming either of both is actually defined.
The difference would be felt with -v.

Is it too late to just incompatibly change this,
since there hasn't been an offical release
since the ill-designed version was introduced?
Note that the default for both ml and cx was
already an empty string (no colorizing).

Has anybody, including the grep.el people,
actually put these two specific capabilities
to use?  (The others being fine as they are.)



Note that I mentioned in another thread that
there was a bug with -v and printing of the
SEP_STR_GROUP ("--") separator line.
False alarm, forget about this one.  The new
test file revealed this to be correct.



Notice that after my private fixes, test #11,
#27, and #28 of tests/yesno.sh still fail.
(Sorry for the long test output lines.)

========================================
Test #11:  { ../src/grep -F -n -b -m 5 -C 1 yes; echo "?$?"; sed 's!^!X!'; }
  output:  "2-10-[B02 no ]/3:20:[C03 yes]/4:30:[D04 yes]/5:40:[E05 
yes]/6-50-[F06 no ]/7-60-[G07 no ]/8:70:[H08 yes]/9:80:[I09 yes]/10-90-[J10 no 
]/?0/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/"
  expect:  "2-10-[B02 no ]/3:20:[C03 yes]/4:30:[D04 yes]/5:40:[E05 
yes]/6-50-[F06 no ]/7-60-[G07 no ]/8:70:[H08 yes]/9:80:[I09 yes]/?0/X[J10 no 
]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/"
    FAIL
 Test #27:  { ../src/grep -F -n -b -m 2 -v -C 1 yes; echo "?$?"; sed 's!^!X!'; }
  output:  "1:0:[A01 no ]/2:10:[B02 no ]/3-20-[C03 yes]/?0/X[C03 yes]/X[D04 
yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no 
]/X[L12 no ]/X[M13 yes]/X[N14 yes]/"
  expect:  "1:0:[A01 no ]/2:10:[B02 no ]/?0/X[C03 yes]/X[D04 yes]/X[E05 
yes]/X[F06 no ]/X[G07 no ]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no 
]/X[M13 yes]/X[N14 yes]/"
    FAIL
 Test #28:  { ../src/grep -F -n -b -m 2 -v -C 1 -o yes; echo "?$?"; sed 
's!^!X!'; }
  output:  "3-25-yes/?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no 
]/X[H08 yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/"
  expect:  "?0/X[C03 yes]/X[D04 yes]/X[E05 yes]/X[F06 no ]/X[G07 no ]/X[H08 
yes]/X[I09 yes]/X[J10 no ]/X[K11 no ]/X[L12 no ]/X[M13 yes]/X[N14 yes]/"
    FAIL
========================================

They all seem to have this in common: with -m,
a rejected line from stdin (regular file) is
both printed as context and left as unread (or
seeked-back) input for the next process to read:

========================================
10-90-[J10 no ]/?0/X[J10 no ]/
3-20-[C03 yes]/?0/X[C03 yes]/
3-25-yes/?0/X[C03 yes]/
========================================

This opportunity for repeated processing appears
to go against the principles behind the design of
-m, as detailed in grep's TeXinfo documentation.



Compare this to the failing "4/..." tests in
tests/foad1.sh.

========================================
Testing:  ../src/grep ^4 -m1 -A99
  input:  "4/40/"
  output: "4/"
  expect: "4/40/"
FAIL
Testing:  ../src/grep ^4 -m1 -A99
  input:  "4/444/"
  output: "4/"
  expect: "4/444/"
FAIL
Testing:  ../src/grep 4$ -m1 -A99
  input:  "4/04/"
  output: "4/"
  expect: "4/04/"
FAIL
Testing:  ../src/grep 4$ -m1 -A99
  input:  "4/444/"
  output: "4/"
  expect: "4/444/"
FAIL
========================================

They deal with lines that would have
been selected but that are beyond the -m
specification.  The apparent expectation, by the
design of those tests, is that a selectable but
beyond -m line should be turned into a context
line because of a positive -A specification.
Is this desirable?  Should these tests be
redesigned to match the current output in this
case, which can be argued to be correct?