nano-devel
[Top][All Lists]
Advanced

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

[Nano-devel] updates, etc.


From: David L. Ramsey
Subject: [Nano-devel] updates, etc.
Date: Sun, 8 Feb 2004 18:05:53 -0500

Note: Apparently my normal email provider's IP address has gotten on a
spam blacklist, so any emails I've tried to send to nano-devel or
help-nano recently have bounced, although I can apparently receive
emails from them just fine.  To get around the problem for the time
being, I'm sending this from another account, and it's signed with my
public GPG key, found at:

http://pooka_regent.tripod.com/downloads/gpg/pooka_regent-asc.txt

----------

Sorry if I've been too quiet lately; I've been busy.  I have been
committing various bits and pieces to CVS in the meantime, though.

Significant changes:

* committed the code to spell-check only marked text when the mark is on

* added support for the escape sequences for function keys; the way
conflicts are dealt with is now explained in the comments above
get_escape_seq_kbinput()

* abcd() has been resurrected as get_escape_seq_abcd(), to simplify
escape sequence handling

* get_verbatim_kbinput() now returns an int* instead of a char*, since
get_kbinput() returns an int, and in any case the int(s) are properly
converted to chars later

* verbatim input is now disabled in view mode, as it should have been
from the beginning

* verbatim input now turns the keypad off and switches to raw mode while
it reads characters, so that we don't have to disable and reenable
signals, and so we get escape sequences for keys; the latter is done in
order to avoid getting bug reports that, among other things, M-V ^H
produces ^G on xterm (since ^H on xterm with the keypad on generates
KEY_BACKSPACE, which when cut down to ASCII range becomes ^G); M-V 0 0 8
could be used to generate ^H in this case, but this way things are less
confusing and closer to what vi does anyway

* the function key used for uncut doubles as unjustify when pressed just
after a justification, just as ^U does

* Meta-P and Meta-N at the search prompt are now aliases for Ctrl-W and
Ctrl-O (go to beginning/end of paragraph)[0]

* a comment in signal_init() said that SIGQUIT was being trapped, which
wasn't actually being done; it's done now

* fixed the saving of the mark when switching between multiple file
buffers; the old code that handled that was broken by the tweak to
ISSET() in 1.3.0 that made it return either 0 or 1 as opposed to the
value of the flag passed to it

* cosmetically tweaked the code involving direction keys; NANO_UP_KEY
and NANO_DOWN_KEY are now NANO_PREVLINE_KEY and NANO_NEXTLINE_KEY (for
consistency with NANO_FORWARD_KEY and NANO_BACK_KEY), and the help
messages for them have been changed accordingly

* tweaked the code in get_page_start() so that we always scroll when the
user tries to move the cursor onto the "$" at the beginning/end of the
line, unlike the old behavior in which we scrolled when the cursor was
on the character before the "$" at the ends of pages other than the
first one[1]

I have a few patches in the works, as well:

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

This patch attempts to finally fix all the problems caused by resizing a
window while nano is in an unstable state (e.g. compiling color regexes
or reading in a large file) as well as document some of the
curses-specific code in main().

(Regarding the former, fixed by a few hacks in Brand Huntsman's patches:
I definitely appreciate the attempt, but a more generic fix is needed in
order to handle the other cases.  Also, after removing your hacks, I
can't seem to reproduce the crashes, even after resizing many times;
would you mind removing your hacks. applying this patch on top of your
improved color code, and trying to make it crash as it has before, so
that I can verify whether this patch works for this case?  Thanks.)

It blocks SIGWINCH via sigprocmask() just after setting the handler for
it, and unblocks it for the duration of get_kbinput() (and hence all the
functions it calls) and for the duration of get_verbatim_kbinput(),
during both of which it's in a relatively stable state.

I'm dealing with Martin Ehmsen's backup directory patch at the moment. 
After that, I'm going to finish porting DB's changes to the search code
(mostly efficiency tweaks and removal of editbot references), and
expanding the fix for do_replace_loop() to fix similar problems with
searching (e.g. search for "^" on a file with more than one line; nano
will stop and display "This is the only occurrence" when it hits the
magicline).  I started working on it awhile ago, and it should be done
soon.  After that, I figure the stability testing should start so that
1.3.2 can eventually get out the door, since it's been almost a month
since the last release and there've been a significant number of
changes.

[0] Rationale:

* ^W and ^O are not very intuitive (unless you count their both being
one key from the edge on opposite sides of the same row of a QWERTY
keyboard intuitive)

* ^P and ^N are the keys to move up one line and down one line; why not
have M-P and M-N be the keys to move up to the beginning of the
paragraph and down to the end of the paragraph?

* M-P and M-N aren't used at the search prompt, and this seems to be in
a similar vein as using M-G as an alias for ^_ and M-R as an alias for
^\ in the edit window

[1] Note that this behavior, as well as the old behavior, is
incompatible with the behavior of the current version of Pico (4.6). 
The reason why I haven't emulated Pico 4.6's behavior in this case is
because it seems buggy to me, and I don't want to go so far in terms of
Pico compatibility as to imitate its bugs.  (If we do that, then we
might as well imitate things like Pico's display malfunction when it
encounters a ^?.)  Pico 4.6's behavior is to allow the user to move the
cursor onto the "$" at the end of the first page without showing the
character there, and even allow the user to edit that unshown
character(!).  If this ever gets fixed, then I'll look into making nano
compatible with the new behavior, but until then I figure it's better to
err on the side of consistency.

Attachment: signature.asc
Description: Text document


reply via email to

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