lynx-dev [dev.20] patch to restore removed initializer

[Kim DeVaughn]

For some reason that I cannot fathom, the initialization of the
ed_offset[] char array in GridText.c:HText_ExtEditForm() was
eliminated in dev.20, for some unknown reason, by some unknown
patch (or so it seems).

Doing so causes one's editor to be called with a garbage string
for a line offset, when the original cursor position is on the
first line of a TEXTAREA (or on any invocation of an editor that
is incapable of doing initial positioning).

The attached patch fixes the problem, so initial positioning works
properly (again).  It also cleans up a couple missing ]'s in some
comments, and chops a couple overly long ones that wrap on an 80
col term.


BTW, I *would* be interested in knowing why the initialization of
the ed_offset[] var was removed ...

/kim


Against 2.8.2dev.20:

diff -uNr lynx-2.8.2-dev.20+kd.orig/src/GridText.c 
lynx-2.8.2-dev.20+kd/src/GridText.c
--- lynx-2.8.2-dev.20+kd.orig/src/GridText.c    Thu Mar 18 09:21:28 1999
+++ lynx-2.8.2-dev.20+kd/src/GridText.c Thu Mar 18 09:08:12 1999
@@ -9346,16 +9346,16 @@
             *  We use lxbuf[] to deal with the two lines involved.
             */
            if (plx) {
-               strcpy (lx, p);      /* <- 1st part of a possible lx'ing tag  */
-               pre_n = strlen (p);  /* count of 1st part chars in this line  */
-               strcat (lx, ht->next->data);   /* tack on NEXT line           */
+               strcpy (lx, p);      /* <- 1st part of a possible lx'ing tag */
+               pre_n = strlen (p);  /* count of 1st part chars in this line */
+               strcat (lx, ht->next->data);   /* tack on NEXT line          */
 
                t     = lx;
                n     = 0;
                valid = TRUE;
 
                /*
-                *  Go hunting again for just digits, followed by a tag end ']'.
+                *  Go hunting again for just digits, followed by tag end ']'.
                 */
                while (*t != ']') {
                    if (isdigit (*t++) != 0) {
@@ -9576,8 +9576,8 @@
      *
      *  [We bypass bumping ->number if it has a value of 0, which takes care
      *   of the ->input_field->type == F_HIDDEN_TYPE (as well as any other
-     *   "hidden" anchors (if such things exist).  Seems like the "right
-     *   thing" to do.  I think.
+     *   "hidden" anchors, if such things exist).  Seems like the "right
+     *   thing" to do.  I think.]
      */
     anchor = start_anchor->next;   /* begin updating with the NEXT anchor */
     while (anchor) {
@@ -9596,8 +9596,8 @@
      *   boundary, this fixup only partially works.  While the tag
      *   numbering is done properly across the pair of lines, the
      *   horizontal positioning on *either* side of the split, can get
-     *   out of sync by a char or two when it gets selected.  See [com
-     *   ments] in  increment_tagged_htline()  for some more detail.
+     *   out of sync by a char or two when it gets selected.  See the
+     *   [comments] in  increment_tagged_htline()  for some more detail.
      *
      *   I suppose THE fix is to prevent such tag-breaking in the first
      *   place (dunno where yet, though).  Ah well ... at least the tag
@@ -9718,7 +9718,7 @@
     TextAnchor *end_anchor    = NULL;
     BOOLEAN    firstanchor   = TRUE;
 
-    char       ed_offset[10];
+    char       ed_offset[10] = "\0";
     int        start_line    = 0;
     int        entry_line    = form_link->anchor_line_num;
     int        exit_line     = 0;
@@ -10162,7 +10162,7 @@
      *   along with a flag to indicate "insert before" as we do here,
      *   or the "normal" mode of operation (add after "current" anchor/
      *   line).  Beware of the differences ... some are a bit subtle to
-     *   notice.
+     *   notice.]
      */
     for (htline = HTMainText->last_line->next, i = 0;
         anchor_ptr->line_num != i;            i++) {
##--eof--##