Possible bug in finding CR's

[Harry Binswanger hb@xxxxxxxx]

    A while back we had an exchange on finding isolated line feeds
(lf's) in Xy files. And someone, I forget whom, publicized the alt-shift-f
sequence as the way to get the right character into a ci/// command. So
far, all to the good.
    There is also the sequence alt-shift-r to find a carriage return (cr)
    But I just got a html file which had line endings that consisted of
two cr's followed by a single lf. Naively, I tried to search and replace the
sequence:
alt-shift-r alt-shift-r alt-shift-f. Result: "not found." Then I tried to
search for just alt-shift-r alt-shift-r. Result "not found." Then I tried to
search for "alt-shift-f". Same result. On the other hand searching for a
single alt-shift-r found one of each pair.
    Finally, in a burst of creative inspiration, I searched for
alt-shift-r followed by the traditional cr-lf pair (the left arrow in red
that you get when you do control-Enter). It worked.
    So the problem can be solved if you realize that Xy treats the
two-byte sequence cr-lf as one entity whenever the two bytes appear next to
each other (probably requires that order, too--I haven't checked). But I
consider this a bug, and users should be advised of the solution above.
    Regards,


     Harry Binswanger
      hb@xxxxxxxx