Kermit | 13 Jan 21:00 2005

Shipment Confirmation, Tracking Number : KAAT50301189129TKA



cnmws.com/?wid=100173






The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn. Alvin Toffler
THE PARENT arrived back on the scene. She gave me a tape by Dr. Laura Meyers from UCLA. I listened to that tape eight times. I listened over and over and heard the same thing again and again. Ms. Meyers said, 'These kids may need to hear a word many times (perhaps 72 times) before they ever say a word. A computer can be patient and say it the same way every time.' Now I understood. I was not patient enough. I did not allow the student to hear the words over and over. I was interrupting their learning by interjecting, when they were totally engrossed in what they were doing. I was asking questions they were not ready to answer. They were just learning language. They didn't have the answers yet.
We are discreet sheep; we wait to see how the drove is going, and then go with the drove. -Mark Twain [Samuel Langhornne Clemens] (1835-1910)
Brian was a boy with Down's Syndrome. He was taking several medications. Brian came from a nurturing family and extended family who provided him with every opportunity. His mother was a teacher and wanted what was best for him. He exhibited no language and was considerably behind his other friends with Down?s Syndrome. We set up a noun program at school. At first he seemed disinterested. He looked at the pictures and sucked his thumb. The more we encouraged him to engage the keyboard, the more he sucked his thumb. We then paired him with a child who was very interested in the noun program. Suddenly the two were fighting over who was next to pick a picture. He worked several times a week at the computer. At his 3-year IEP, the team shook their heads. They didn't understand. Despite the track record of many students with Down?s Syndrome, Brian's language was his best skill I smiled and his mother winked at me.
Lots of times you have to pretend to join a parade in which you're not really interested in order to get where you're going. -Christopher Darlington Morley (1890-1957)
I am not missing surfing.
All my life I've wanted to be someone; I guess I should have been more specific. Jane Wagner/Lily Tomlin (1939- )
The guards don't often love reading.
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
David Lawrence Ramsey | 13 Jan 22:48 2005
Picon

massive updates: UTF-8 support, etc.

Sorry for the silence lately, but I've made major progress in terms of 
UTF-8 support in 1.3.5-cvs, and it's taken a while to get it to an 
easily maintainable state.  It's still not completely finished, but the 
basics (moving around, typing, deleting, backspacing, displaying the 
shortcut list at the bottom of the screen, etc.) should be working in 
the edit window and at the statusbar prompt.

As many operations as possible use multibyte strings now, so as to keep 
the most code in common between the wide and non-wide versions of nano.  
In some cases, I've used parts of David Benbennick's old UTF-8 patch, 
and in other cases I've modified parts of it or written parts of my own.  
The operations that have been converted to do this are now in their own 
source file, chars.c.  During testing, I've discovered that the non-wide 
ncurses will not display multibyte UTF-8 strings properly in UTF-8 
locales using e.g.  display_string(), and the UTF-8-enabled prereleases 
of slang 2.0 won't either under the same conditions.  In the former 
case, we can just check for and link with the wide version of ncurses, 
but I can't figure out what to do in the latter case.  (Maybe slang's 
UTF-8 support doesn't extend to its curses emulation?)

Other changes include an overhaul of the high-level statusbar input 
routines so that verbatim input works at the statusbar prompt; changes 
to verbatim input's character input mode to accept four-digit 
hexadecimal numbers instead of three-digit decimal numbers so as to 
allow input of Unicode characters; and the addition of the ability to 
cut all text from the current cursor position to the end of the file 
with one keystroke (duplicating the same functionality as in a patch for 
Pico, although I call the shortcut CutTillEnd instead of DelToEnd and 
add the alias M-T in the main list for ^X at the search prompt).
Jordi Mallach | 14 Jan 01:26 2005
Picon

Re: massive updates: UTF-8 support, etc.

On Thu, Jan 13, 2005 at 10:48:05PM +0100, David Lawrence Ramsey wrote:
> Sorry for the silence lately, but I've made major progress in terms of 
> UTF-8 support in 1.3.5-cvs, and it's taken a while to get it to an 
> easily maintainable state.  It's still not completely finished, but the 

Hi David!

This is great news, half of Debian was waiting for this mail. :)

Do you think the current code is packageable, or should I wait for
1.3.6? I'm concerned about the 8bit nasty bugs in vanilla 1.3.5 which I
have in experimental.

Jordi
--

-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi <at> sindominio.net     jordi <at> debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
Mike Frysinger | 14 Jan 02:02 2005
Picon

Re: massive updates: UTF-8 support, etc.

On Thursday 13 January 2005 07:26 pm, Jordi Mallach wrote:
> This is great news, half of Debian was waiting for this mail. :)

i would say there's some users of Gentoo also wanting this fix too :)

not quite sure how big our UTF8 user base is, i avoid UTF8 when i can
-mike
Jordi Mallach | 14 Jan 08:38 2005
Picon

Re: massive updates: UTF-8 support, etc.

On Thu, Jan 13, 2005 at 08:02:50PM -0500, Mike Frysinger wrote:
> not quite sure how big our UTF8 user base is, i avoid UTF8 when i can

... says the English speaker :)

At least in the Debian developer community, I think most of us are using
UTF-8 locales by now. They aren't the default yet, but Ubuntu, for
example, will be UTF-8 by default with their next release.

UTF-8 is the way to go, anyway. :)

--

-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi <at> sindominio.net     jordi <at> debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
David Lawrence Ramsey | 19 Jan 17:47 2005
Picon

Re: massive updates: UTF-8 support, etc.

--- Jordi Mallach <jordi <at> gnu.org> wrote:
>Hi David!
>
>This is great news, half of Debian was waiting for this mail. :)

Oh good.

>Do you think the current code is packageable, or should I wait for 
>1.3.6? I'm concerned about the 8bit nasty bugs in vanilla 1.3.5 which I 
>have in experimental.

It's not quite packageable yet, unfortunately.  In the meantime, the 
attached patch should remove the buggy UTF-8 support from 1.3.5, so that 
the typing of 8-bit characters should at least work again.  It also 
fixes a mismatched prototype found by Jeremy Huddleston in Gentoo that's 
been fixed in CVS (break_line() should return a ssize_t and not an int).

(Those of you using the old patch that adds the "noutf8" flag should be 
aware that UTF-8 support in CVS is now autodetected based on locale, so 
the flag is no longer needed.)

In CVS, the areas that still need UTF-8 support are:

* Tab completion of filenames and display of filenames in the file 
browser.  These are both in DB's old UTF-8 patch, but the changes needed 
for them are on top of his changes in his old behemoth patch, which I 
haven't gotten to porting over yet.

* revstrcasestr() and the equivalent of strcasestr(), since 
case-insensitive searches for UTF-8 strings won't work without support, 
and also strncmp(), since its length argument needs to be in terms of 
multibyte characters.

* All of the help browser code, which currently cuts UTF-8 lines off 
prematurely.  (To see this, open a UTF-8 terminal using DejaVu fonts and 
the ru_RU.UTF-8 locale, and compare the appearance of the help menu to 
its appearance in an ru_RU locale.)  The use of help_line_len() may have 
to be changed, too, since calculating it for every line on the fly is 
much slower if it contains calls to strlenpt() to get the number of 
columns the line actually takes up in preparation for breaking it at a 
space.  And should it break at Unicode spacing characters as well as 
ASCII spaces?

* Possibly parts of the justify routine.  Should justified lines of a 
paragraph break at Unicode spacing characters as well as ASCII spaces?  
If so, what do we do when spaces need to be added to the end of a line?  
Do we just add ASCII spaces as we do now, or do we try to guess what 
spacing character should be there (which could be prone to error)?

* All of the rcfile code, since it needs to read string arguments in 
some cases and hence needs to parse the characters correctly.

* Whitespace display mode, since it partially relies on the rcfile code.

* The calculation of totsize, since it still maintains a count of 
single-byte characters instead of multibyte characters in UTF-8 mode.

* The use of NO_CONVERT.  Since it's normally used when opening binary 
files, it should treat even UTF-8 as binary when it's used and display 
the edit window and statusbar text as a raw stream of bytes.  I'm not 
yet sure where to put the hooks for this in a way that won't break 
display of other things and will stay consistent when switching between 
multiple buffers, though.

* What should be done about slang, since its UTF-8 support in 2.0 
doesn't seem to work with its curses emulation, meaning that nano 
binaries built with it can't support UTF-8 properly?

Other long-standing non-UTF-8 and non-TODO list issues that need to be 
solved eventually and which I haven't forgotten:

* Improvements to the color code and related improvements to the rcfile 
code (specifying regexes in separate files, specifying different regexes 
for different filenames of the same type, etc.), as mentioned in posts 
to the list a few months ago and earlier.

* Port over more of Gentoo's color regexes, as posted by Mike Frysinger 
awhile back.

* Modifying the shortcut list display on the last two lines of the 
screen so that it can handle overly long shortcuts in e.g. the Ukrainian 
translation.

* Adding the keypad flag back in if the issues with the numeric keypad 
and PuTTY still exist.  (There's currently only room for one more flag 
before the 32-bit limit is reached again, and bit fields don't work 
because there's no way to subscript them and hence no way to associate 
them with toggles, so maybe another approach may have to be used 
eventually?)

* Adding support for having the Alt key act as a Meta key when using 
PDCurses, as suggested by Tom Haller back in October.  Related 
questions: How do the KEY_ALT_L and KEY_ALT_R keys actually work?  Are 
they generated when you press those keys alone, or are they generated as 
part of a sequence when you press them as part of a combination (i.e, 
does [Left-]Alt-G produce "KEY_ALT_L" "g"?)

* Breaking the WriteOut routine into several separate routines for ease 
of maintenance, as suggested by Jay Carlson back in 2002, and possibly 
working with file descriptors instead of filenames in the process so 
that safe_tempnam() is no longer needed and mkstemp() can be used 
directly?

* Fixing the (now-overhauled) statusbar code so that it only refreshes 
when it needs to, as the edit window code already does.

* Fixing the history code so that scrolling works properly in all cases 
(since problems occasionally pop up, although I haven't figured out how 
to reproduce them reliably; adding code to just peek at the next history 
entry without moving to it would be easier to deal with), and so that 
there's no blank line produced when scrolling up at the top of the list, 
since text typed there is not preserved when scrolling as it is at the 
bottom of the screen, and having a blank line only at the end is 
consistent with the idea of the magicline.  Also break the history 
shortcut into two shortcuts, one for moving up and one for moving down, 
and set their key values properly so that mouse clicks work on them.

* Adding mouse support to the statusbar prompt, in terms of moving the 
cursor to where the user clicks.

* Possibly finding a generic way to merge the edit window and statusbar 
routines in some cases, in order to cut down on the amount of duplicated 
code between the two.  (Related: How should filename searches in the 
file browser be implemented, since findnextstr() works only with 
filestructs and filenames are a simple char* array?  Creating a fake 
filestruct containing all filenames would be easiest, but seems 
wasteful.)

* Going over the list of potential memory problems that Rocco sent 
awhile back, in case any of those could be latent bugs.

* Porting over the last of the useful code from DB's behemoth patch 
(other than what's needed for UTF-8), such as the improved rcfile 
parsing and the ability to handle smaller window sizes in nano.c.

* Possibly more rearrangement of source files, such as putting most edit 
window-specific functions in edit.c and most statusbar prompt-specific 
functions in status.c (not statusbar.c, since it doesn't fit in the 8.3 
filename limit and could cause problems on Cygwin).

* Fribidi support, as mentioned ages ago (although this has to wait 
until UTF-8 support is done and probably until we actually have a 
translation in an RTL language so that it can be tested properly).

The changes in CVS since my last email are:

* UTF-8 support added to the strcasecmp() equivalent, the strncasecmp() 
equivalent, do_next_word(), and do_prev_word()

* UTF-8 support fixed in mbstrnlen()

* String functions in utils.c moved to chars.c, as almost all of them 
need multibyte versions to support UTF-8, and they all deal with 
characters anyway.

* Support added for the -O/--morespace option, Meta-O toggle, and 
"morespace" rcfile option, which allows the blank line below the 
titlebar to be used as part of the edit window, as suggested back in 
October.

* Support added for the CUT_TO_END flag when pressing Ctrl-K at the 
statusbar prompt, for consistency with the edit window.

* Support added for moving to the next or previous word at the statusbar 
prompt, since it may be useful when long strings of words are there.

* Updated documentation for the manual pages and info pages, syncing 
their descriptions with those in nanorc.sample where necessary and 
documenting -O/--morespace.
diff -ur nano-1.3.5/src/nano.c nano-1.3.5-fixed/src/nano.c
--- nano-1.3.5/src/nano.c	2004-11-22 20:59:18.000000000 -0500
+++ nano-1.3.5-fixed/src/nano.c	2005-01-19 10:00:25.000000000 -0500
 <at>  <at>  -2399,7 +2399,7  <at>  <at> 
  * such space, and force is TRUE, then we find the first space.  Anyway,
  * we then take the last space in that group of spaces.  The terminating
  * '\0' counts as a space. */
-int break_line(const char *line, ssize_t goal, bool force)
+ssize_t break_line(const char *line, ssize_t goal, bool force)
 {
     ssize_t space_loc = -1;
 	/* Current tentative return value.  Index of the last space we
diff -ur nano-1.3.5/src/nano.h nano-1.3.5-fixed/src/nano.h
--- nano-1.3.5/src/nano.h	2004-11-08 23:08:48.000000000 -0500
+++ nano-1.3.5-fixed/src/nano.h	2005-01-19 10:03:07.000000000 -0500
 <at>  <at>  -162,7 +162,7  <at>  <at> 
 } topmidnone;

 typedef enum {
-    NO_SEQ, ESCAPE_SEQ, UTF8_SEQ
+    NO_SEQ, ESCAPE_SEQ
 } seq_type;

 /* Structure types. */
diff -ur nano-1.3.5/src/winio.c nano-1.3.5-fixed/src/winio.c
--- nano-1.3.5/src/winio.c	2004-11-22 20:59:18.000000000 -0500
+++ nano-1.3.5-fixed/src/winio.c	2005-01-19 10:05:35.000000000 -0500
 <at>  <at>  -112,30 +112,15  <at>  <at> 
 #endif

 /* Put back the input character stored in kbinput.  If meta_key is TRUE,
- * put back the Escape character after putting back kbinput. */
+ * put back the Escape character after putting back kbinput.  If
+ * func_key is TRUE, put back the function key (a value outside byte
+ * range) without putting it in byte range. */
 void unget_kbinput(int kbinput, bool meta_key, bool func_key)
 {
-    /* If this character is outside the ASCII range and func_key is
-     * FALSE, treat it as a wide character and put back its equivalent
-     * UTF-8 sequence. */
-    if (kbinput > 255 && !func_key)
-    {
-	int i;
-	char *s = charalloc(MB_CUR_MAX + 1);
-	wchar_t wc = (wchar_t)kbinput;
-
-	i = wctomb(s, wc);
+    if (!func_key)
+	kbinput = (char)kbinput;

-	if (i == -1)
-	    /* This wide character is unrecognized.  Send it back. */
-	    ungetch(kbinput);
-	else {
-	    for (; i > 0; i--)
-		ungetch(s[i - 1]);
-	}
-	free(s);
-    } else
-	ungetch(kbinput);
+    ungetch(kbinput);
     if (meta_key)
 	ungetch(NANO_CONTROL_3);
 }
 <at>  <at>  -221,29 +206,6  <at>  <at> 
 			retval = sequence[0];
 		    }
 		}
-	    /* Handle UTF-8 sequences. */
-	    } else if (seq == UTF8_SEQ) {
-		/* If we have a UTF-8 sequence, translate the UTF-8
-		 * sequence into the corresponding wide character value,
-		 * and save that as the result. */
-		int i = 0;
-		char *s = charalloc(seq_len + 1);
-		wchar_t wc;
-
-		for (; i < seq_len; i++)
-		    s[i] = (char)sequence[i];
-		s[seq_len] = '\0';
-
-		if (mbtowc(&wc, s, MB_CUR_MAX) == -1) {
-		    /* This UTF-8 sequence is unrecognized.  Send it
-		     * back. */
-		    for (; seq_len > 1; seq_len--)
-			unget_kbinput(sequence[seq_len - 1], FALSE,
-				FALSE);
-		    retval = sequence[0];
-		} else
-		    retval = wc;
-		free(s);
 	    }
 	    free(sequence);
 	}
 <at>  <at>  -262,8 +224,8  <at>  <at> 

 /* Translate acceptable ASCII, extended keypad values, and escape and
  * UTF-8 sequences into their corresponding key values.  Set seq to
- * ESCAPE_SEQ when we get an escape sequence, or UTF8_SEQ when we get a
- * UTF-8 sequence.  Assume nodelay(win) is FALSE. */
+ * ESCAPE_SEQ when we get an escape sequence.  Assume nodelay(win) is
+ * FALSE. */
 int get_translated_kbinput(int kbinput, seq_type *seq
 #ifndef NANO_SMALL
 	, bool reset
 <at>  <at>  -492,11 +454,6  <at>  <at> 
 	    }
     }

-    /* A character other than ERR with its high bit set: UTF-8 sequence
-     * mode.  Set seq to UTF8_SEQ. */
-    if (retval != ERR && 127 < retval && retval <= 255)
-	*seq = UTF8_SEQ;
-
 #ifdef DEBUG
     fprintf(stderr, "get_translated_kbinput(): kbinput = %d, seq = %d, escapes = %d, ascii_digits = %lu,
retval = %d\n", kbinput, (int)*seq, escapes, (unsigned long)ascii_digits, retval);
 #endif
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
Martin Olsson | 20 Jan 03:43 2005
Picon

prompt reappears at the wrong place when exiting nano

Hi,

I was wondering about this bug-like thing that happens with nano on some 
machines I use. Let's say I type "clear", "ls -al" and then "nano 
somefile.txt". Now later when I exit nano one of two things happen.

1. the console screen reappears with the prompt right below the line 
where I typed "nano somefile.txt"

2. the console screen reappears with the prompt somewhere in the middle 
of the old "ls -al" output

Is it a nano problem or a shell problem? How can I fix this?

mvh
martin
David Benbennick | 19 Jan 19:06 2005
Picon

Re: prompt reappears at the wrong place when exiting nano

On Wed, 19 Jan 2005 18:43:19 -0800, Martin Olsson <mnemo <at> minimum.se> wrote:
> Hi,
> 
> I was wondering about this bug-like thing that happens with nano on some
> machines I use. Let's say I type "clear", "ls -al" and then "nano
> somefile.txt". Now later when I exit nano one of two things happen.
> 
> 1. the console screen reappears with the prompt right below the line
> where I typed "nano somefile.txt"
> 
> 2. the console screen reappears with the prompt somewhere in the middle
> of the old "ls -al" output
> 
> Is it a nano problem or a shell problem? How can I fix this?

It's a Nano problem.  The same thing happens when you suspend with control-Z.

A workaround is to have the cursor at the last line of the window
before launching Nano.  Just hold down Enter for a while...  (And
don't change the window height while Nano is running!)
Marco Colombo | 20 Jan 14:24 2005
Picon
Picon

Updated Italian translation (1.2 branch)

yo!!!
I know that the 1.2 branch is completely stable and hopefully there will not be
the need of having more releases from that, but I'd like to update the italian
translation. you will find it here attached and gzipped.
thank you very much in advance!
ciao, marco
Attachment (it.po-1.2-branch.gz): application/x-tar, 14 KiB
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel
Jordi Mallach | 20 Jan 14:58 2005
Picon

Re: Updated Italian translation (1.2 branch)

Hey Marco!

On Thu, Jan 20, 2005 at 01:24:48PM +0000, Marco Colombo wrote:
> I know that the 1.2 branch is completely stable and hopefully there will not be
> the need of having more releases from that, but I'd like to update the italian
> translation. you will find it here attached and gzipped.
> thank you very much in advance!

Thanks!

Two days earlier it would have gone into the Debian package. Too bad,
because it is now frozen.

It's in CVS already.

Jordi
--

-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi <at> sindominio.net     jordi <at> debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/
_______________________________________________
Nano-devel mailing list
Nano-devel <at> gnu.org
http://lists.gnu.org/mailman/listinfo/nano-devel

Gmane