It is quicker to do a handful of superfluous compares at the end of
each line than it is to compute and keep track of and compare the
remaining line length the whole time.

The typical line is some sixty characters long, the typical search
string ten characters -- with a shorter search string the speedup is
even higher: some fifteen percent.  Only when the string is longer
than half the average line length does searching become slower with
this new method.

All this for a UTF-8 locale.  For a C locale it makes no difference.

Now that mbstrncasecmp() does the right thing, there is no need any
more to verify that only a valid multibyte sequence was matched.

(See https://savannah.gnu.org/bugs/?45579 for a test case.)

Also, this will make it possible to search for invalid sequences.

(Currently it isn't possible to enter a search string with invalid
characters, but... a user might edit the search history file.  And
if pasting at the prompt is implemented, it will be trivial to enter
invalid sequences if you have a file that contains them.)

Persisting might lead to count 'n' reaching zero, which would mean that
the needle has matched, which is wrong when one of the strings contains
an invalid or incomplete multibyte sequence.

That is: don't run towlower() on the two differing bytes when having
reached the end of one of the strings.

This fixes https://savannah.gnu.org/bugs/?48700.

In the bargain, don't do the conversion to lowercase twice.

Furthermore, persist when encountering invalid byte sequences --
until finding bytes that differ.

The needle is never part of the hay -- it is always a separate string.

(And even if needle and haystack were identical, the routine works fine,
the case does not need special treatment.)

This fixes https://savannah.gnu.org/bugs/?48660.

This fixes https://savannah.gnu.org/bugs/?48578.

This allows the user to specify which other characters, besides the
default alphanumeric ones, should be considered as part of a word, so
that word operations like Ctrl+Left and Ctrl+Right will pass them by.

Using this option overrides the option --wordbounds.

This fulfills https://savannah.gnu.org/bugs/?47283.

So, slightly speed up the functions that check for those.

Invalid multibyte sequences get depicted with the Replacement Character,
and unassigned codepoints are shown as if they were a space.  Both have
a width of one.

Use knowledge of UTF-8 instead of converting to wide characters first.

Any control character is represented by a ^ plus an ASCII character.

Instead of showing the upper control codes like this:

   ^À ^Á ^Â ^Ã ^Ä ^Å ^Æ ^Ç ^È ^É ^Ê ^Ë ^Ì ^Í ^Î ^Ï
   ^Ð ^Ñ ^Ò ^Ó ^Ô ^Õ ^Ö ^× ^Ø ^Ù ^Ú ^Û ^Ü ^Ý ^Þ ^ß

show them like this:

   ^` ^a ^b ^c ^d ^e ^f ^g ^h ^i ^j ^k ^l ^m ^n ^o
   ^p ^q ^r ^s ^t ^u ^v ^w ^x ^y ^z ^{ ^| ^} ^~ ^=

The lower control codes continue to be shown like this:

   ^@ ^A ^B ^C ^D ^E ^F ^G ^H ^I ^J ^K ^L ^M ^N ^O
   ^P ^Q ^R ^S ^T ^U ^V ^W ^X ^Y ^Z ^[ ^\ ^] ^^ ^_

The representation of DEL (0x7F) continues as ^?.

Further, use knowledge of UTF-8 to avoid a roundtrip through
wide characters.

By removing from their main loops a condition that occurs just once.

When running in a non-UTF locale, and when strncasecmp() suffers from
the same defect as strncmp(), make sure not to pass a length with the
high bit set.

The function is_cntrl_mbchar() has always been called successfully before
calling control_mbrep(), so the passed character *is* a valid sequence.

Instead of parsing every multibyte character twice, first with
parse_mbchar() and then with mbtowc(), just let mbtowc() do all
the work.  This makes searching for a fixed string twice as fast.

This also gets rid of four variables and lots of memory allocations.
(And, more importantly: it stops nano messing up the internal state
of the multibyte-to-wide character conversion, and thus would make
the calls to mbtowc_reset() superfluous.)

(The measurable effect (during long searches, for example) is zero, though.)


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5773 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

and two other minute tweaks.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5649 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

Apparently there is /some/ state somewhere after all.  Don't have time
now to figure out where exactly.


git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5369 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5354 35c25a1d-7b9e-4130-9fde-d3aeb78583b8

git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5316 35c25a1d-7b9e-4130-9fde-d3aeb78583b8