The interval 2013-2017 for the Free Software Foundation is valid
because in those years there were releases with changes by either
Chris or David, and the GNU maintainers guide advises to mention
a new year in all files of a package, not just in the ones that
actually changed, and be done with it for the rest of the year.
The platform's default char type might be signed, which could cause
problems in 8-bit locales.
This addresses https://savannah.gnu.org/bugs/?50289.
Reported-by: Hans-Bernhard Broeker <HBBroeker@T-Online.de>
In path names and file names, 0x0A means an embedded newline and
should be shown as ^J, but in anything related to the file's data,
0x0A is an encoded NUL and should be displayed as ^@.
So... switch mode at the two main entry points into the "file system"
(reading in a file, and writing out a file), and also when drawing the
titlebar. Switch back to the default mode in the main loop.
This fixes https://savannah.gnu.org/bugs/?49893.
The byte 0x0A means 0x00 *only* when it is found in nano's internal
representation of a file's data, not when it occurs in a file name.
This fixes the second part of https://savannah.gnu.org/bugs/?49867.
That is: elide a second test from the most travelled path: a valid
character. This adds a second call of mblen() when parse_mbchar()
is called on a terminating zero, but that should never happen.
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 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.
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.
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.
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
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
but only as far back as such a character can possibly be.
Speedup suggested by Mark Majeres.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5147 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/chars.c (addstrings): Needs to be available even on
non-utf-8 sustems.
* nano-regress: Added --disable-utf8 to regression check
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4933 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and handling multibyte characters correctly.
*Patch by Mark Majeres.*
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4908 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Fix some more severe warnings from 'g++ -pedantic', from patch originally
by Eitan Adler <lists@eitanadler.com>
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4534 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* Update documentation for 2.2 features including sample nanorc file, texinfo
file, man pages, UPGRADE file, and update copyright noticed for the current year.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4453 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* chars.c, file.c - Better handle unused results for things like mbtowc(), new
macro IGNORE_CALL_RESULT.
2009-12-01 Chris Allegretta <chrisa@asty.org>
* global.c (shortcut_init) - Remove redundant entries for ^Y/^V reported by
Christian Weisgerber.
* doc/man/nanorc.5 - Fix typo in Meta documentation, reported by gibboris@gmail.com.
2009-11-29 David Lawrence Ramsey <pooka109@gmail.com>
* global.c (shortcut_init) - Add support for ^P and ^N in the help menu.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4452 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* prompt.c (get_prompt_string) - Universally handle help key when is disabled. Fixes Savannah
bug 28117 by David Lawrence Ramsey <pooka109@gmail.com>.
* chars.c, files.c: Add junk vars to silence the compiler. Sigh.
2009-11-29 David Lawrence Ramsey <pooka109@gmail.com>
* Change several *chars to const char, additional cleanups and casts to make compilers happier.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4448 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
assigned to the Free Software Foundation; also, make copyright notices
consistent in style
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4173 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
mbrevstrcasestr(), simplify and rewrite to use strncasecmp()
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4131 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
simplify by using for loops instead of while loops where possible, to
match the single-byte versions of these functions
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4127 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
mbrevstrcasestr(), for efficiency, return haystack immediately if needle
is blank
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4122 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
allocate space for multibyte characters until we've asserted that the
parameters we're using aren't NULL
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@3803 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
it on the statusbar when we get an unhandled shortcut or toggle, as Pico
does
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@3554 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
-D/--boldtext command line option and the "boldtext" rcfile option, and
reduce USE_UTF8 to a static bool in chars.c
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@3368 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Benno Schulenberg