[Nano-devel] patch status, answers to questions, etc.

[David Lawrence Ramsey]

After two simulated thesis proposals, I'm back, although I have exams
next week so I'll be busy again then.  I've been able to get some things
done, though.  Sorry for the delay.

As for the 1.3.1 release, I was thinking that, at a minimum, the
following need to be done before it:

* the input fixes in the patch mentioned below need to go in

* a FAQ entry should be added for the verbatim input mode (the Meta-V
[key] input may be familiar to those with some vi exposure, but the
Pico-compatible Meta-V [3-digit ASCII code] input may be less obvious)

* DB's refactored cutting code, along with the associated fixes to
write_file(), needs to go in, since it's undergone a lot of testing and
it removes more references to editbot

Of course, nothing can be committed until Savannah's fully up and
running again, but that leaves more time for testing.

As for the questions raised in several previous emails:

The character display problem on Sun machines
---------------------------------------------

Unfortunately, I can't reproduce this on a SunOS 5.7, 5.8, or 5.9 box
with their associated curses versions (none of which have version
numbers that I can find, unfortunately).  It could very well be a
curses/ncurses difference.  (As an aside, one curses/ncurses difference
I have noticed is that after the "Verbatim input" prompt, reset_cursor()
is called to move the cursor back to the edit window on ncurses, but it
seems to have no effect on curses, on which the cursor stays at the end
of the statusbar prompt.)  Have you tried to compile it with ncurses to
verify this?  What version of SunOS/Solaris are you using when this
happens, and what version of curses (if you can find out what it is)?

The keyboard input issues
-------------------------

The reason why I've been so reluctant to add support for more escape
sequences to nano is mainly because, until now, I was under the
impression that most terminals interpreted the keypad values properly. 
After testing this on an xterm on a Sun machine and having it generate
escape sequences, in addition to the problems with Eterm and the like
from before, I've concluded that to minimize breakage, there must be
enough escape sequence support to handle the most common extended keys,
although I'm still sticking with always having keypad() turned on.  To
this end, I've been tweaking the input code, and I've made the following
changes (available along with a few other minor tweaks at

http://pooka_regent.tripod.com/patches/nano/nanoinput2-patch.txt

in case anyone wants to test them):

* added enough escape sequences so that Insert, Delete, Home, End,
PageUp, PageDown, and Ctrl-[arrow key] are handled properly on the Linux
console, the FreeBSD console, the Hurd console, xterm, rxvt, and Eterm;
escape sequences for function keys are not supported because they
conflict with other sequences in at least one case (F9/F10 on the
FreeBSD console are the same as PageDown/PageUp on the Mach console) and
because keypad() should handle those as it handles the arrow keys
("should" being the operative term; the Sun machine from before reads
F5-F9 correctly, generates KEY_F0 for F10, and generates escape
sequences for F1-F4 and F11-F14; however, I don't have any better ideas
at the moment as to how to properly fix this, and all of the functions
assigned to the function keys have aliases in any case)

* made it so ASCII 127 is interpreted as Backspace (the current
behavior) if --rebinddelete is not used, and as Delete if it is; this
works around Eterm's generating ASCII 127 for Delete (just use -d), but
also requires a change in the description of --rebinddelete; I've
changed it to "Fix Backspace/Delete confusion problem" because "Fix
Backspace if it acts like Delete, or vice versa" is too long; is this
clear enough, or can anyone else think of a better description?

* extended get_verbatim_kbinput() so that its ASCII input mode can be
disabled by a parameter, and modified get_escape_seq_kbinput() to use
get_verbatim_kbinput() with that parameter set to read in escape
sequences, since it is well suited to that

* hooked up the last of the keyboard functions to the new input code;
now you can hit Esc Esc C at the Yes/No/All prompt, or Esc Esc U at the
"Can now UnJustify!" message, and it'll be properly interpreted as
Ctrl-C or Ctrl-U, respectively; this means that only the higher-level
input code needs to be done now

* in the file browser, made '?' start the help browser as it does in
Pico, and readded the 'G'/'g' alias for "Go to Directory" that I
erroneously removed before

The luit/UTF-8 problems
-----------------------

I've tried loading a binary file into nano using luit, and it appears
that, assuming that xterm is being used, the screen corruption is caused
by luit's UTF-8 sequence substitution, specifically the direct display
of control characters with their high bits set.  Under normal
circumstances, nano displays these as control characters to avoid the
problem, but luit's substitution circumvents that.  Adding UTF-8 support
to nano should probably fix this.

Adding search capability a la Pico to the file browser
------------------------------------------------------

I believe this can be done relatively easily, but for it to work, the
filenames need to be put into a filestruct*, since that is what the
searching routines work on, and that will take some work.  At the very
least, however, from what I've observed of Pico's version, its searches
never end on the same file they started on, so the new parameter I added
to findnextstr() to fix the regex bug that allows that behavior can be
reused here.


_____________________________________________________________
Sluggy.Net: The Sluggy Freelance Community!