[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nano-devel] more on Home/End not working atstatusbarw/ALT_KEYPAD

From: David Lawrence Ramsey
Subject: Re: [Nano-devel] more on Home/End not working atstatusbarw/ALT_KEYPAD on xterm
Date: Sat, 5 Jul 2003 16:02:03 -0700 (PDT)

Jordi Mallach:
On Sat, Jul 05, 2003 at 12:29:36PM -0700, David Lawrence Ramsey wrote:


>Well, forcing people to use an option just because they use OS foo or
>bar sounds hackish to me. I guess I would prefer doing a configure
>check for FreeBSD and doing magic for them on the fly, so they don't
>need to use -K.

Oops; forgot about that.  Now that I think about it, that's probably the
best solution, to have nano work "out of the box" without having to deal
with incompatible key values or similar things.  One issue, though, is
what to do if there's a terminal type with this problem that we don't
know about.  Should we allow the user to specify the option if
necessary, e. g. --enable-screweddelete :) or something?


>>In light of this, my patch would fix the statusbar for me when using
>>-K but break it for FreeBSD users whether they were using -K or not,
>>so it shouldn't go in.  Since I can work around it for the time being
>>by not using -K, it's relatively minor anyway.
>You mean the current patch I tested the other day, right?


>So what'd be the correct solution, again? I'm a bit confused by -d, -K,
>non-FreeBSD and FreeBSD at this point of the mail. What would be the
>long term, clean solution?

1. Remove -K and all associated code to interpret raw escape sequences
and turn keypad() on all the time, so that we only have to deal with
keypad values.

2. Add the possibility of interpreting KEY_DC as KEY_BACKSPACE, via -d
or a #define (the latter could be part of the configure check as
mentioned above).

3. Generalize and consolidate input routines so they aren't scattered
across many source files and don't duplicate vast amounts of code.  (All
right, this crosses over into general cleanup for ease-of-maintenance
purposes, but it needs to be done.)  I've taken a first step toward
this, a restructuring of single-character and verbatim input:

Keep in mind that I haven't tried to compile it or integrate it into
nano at all yet; it's more of a design idea right now, and still needs
some work.  Note that I've set it up so that it translates as many key
types into nano-specific key values as possible (e. g. KEY_RIGHT ->
NANO_FORWARD_KEY); this is so if rebindable keys get implemented,
rebinding a key will be as (relatively) simple as changing one key
value.  Note also that I've integrated code from my verbatim input
patch, although it'll have to be called and have its results interpreted
by specific second-level input routines (the edit window, the statusbar
prompt, the help menu, and the file browser) to actually be of use.

The reason I haven't done much with my verbatim input patch lately is
this situation with the input routines.  Since cleaning up the input
routines will severely break most of it and lead to my having to
reimplement it, I figure I might as well clean the input up first and
reimplement verbatim input in the cleaned-up version.

>Thanks for investigating David!

No problem.

Sluggy.Net: The Sluggy Freelance Community!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]