lynx-dev
[Top][All Lists]
Advanced

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

lynx-dev Some thought on additional TEXTAREA functions


From: Kim DeVaughn
Subject: lynx-dev Some thought on additional TEXTAREA functions
Date: Fri, 29 Jan 1999 19:26:58 -0800

There's been a number of comments relating to TEXTAREA editing, and
such, in several threads.  Let me try to summarize and respond to
them here.

I think the main things I've read, roughly boil down to variations
on the following topics:

  1) Provide the ability to directly "insert" a file into a TEXTAREA,
     without having to go through an editod.

   - This should be easy to implement.  All that's (conceptually) needed
     is to substitute a user-specified filename, for the tempfile that
     the editor uses.

     If I have time, and can figure out how to get a filename from the
     user (it looks like that will be the hardest part), I'll implement
     this function over the weekend.


     FWIW, the algorithm for adding new lines/anchors within a TEXTAREA
     seem to be fairly robust.  In testing the existing feature, I
     "grew" a five-line TEXTAREA, into one of over 1200 lines, and about
     100k of text, successfully submitted it, and had it returned in a
     seperate "results" page from the site, without any problems.

     After the TEXTAREA was expanded, the page continued to behave
     "normally" (ie, subsequent/prior links/anchors functioned properly,
     etc).  Since I was looking for memory leaks, and was running with
     --enable-find-leaks  turned on, it did take "awhile" to audit the
     memory usage, on exiting, however :-) .  No leaks were found, though.


  2) Provide a command of some sort, to "grow" the TEXTAREA directly
     (again, without invoking an external editor).

   - This too, should be fairly easy to do.

     The question I have though is, should such a command always grow the
     TEXTAREA by some reasonable, fixed amount, each time it is issued,
     or should it prompt the user for some arbitrary number of lines?

     I personally lean toward the "fixed number" approach, since I can
     just hit the cmd a few times if I need a larger area, and I don't
     need to look for, and read a prompt, and then have to enter a number,
     etc.  Of course I could always have my mind changed about this.


  3) Provide a method to auto-grow the TEXTAREA, on an "as required"
     basis, during lynx-based text entry.

   - I like this idea.  Seems like hitting a CR when in the last existing
     line of the TEXTAREA is the most reasonable "signal" to add a new
     line (which of course means you would need to use a tab or down-arrow
     to get out of the TEXTAREA).  This behavior *could* be o(ptional),
     but that seems a bit "nitsy" to create YAO for (IMHO).  [To those who
     "run thru" a TEXTAREA with CR's by habit, I can only say ... you must
     activate alot of buttons / enter alot of links  that immediately
     follow a TEXTAREA, by accident ... :-) ...]

     Unfortunately (here's the "but"), while probably not too much more
     difficult to implement than (2) above, each time a line (or group of
     lines) gets added to the TEXTAREA, the screen needs to be fully
     redrawn (or so I believe, ATT).

     I'd find it *really* annoying, to have a redraw performed each time
     I hit a line-adding-CR ...!

     I suppose as a compromise, that when a new line were needed, several
     could be added at once, similar to the "fixed number" method in (2)

     Ie, typing along <CR>, typing along <CR>, typing in last line <CR>,
     <refresh> (got 10 new lines to play with), typing along <CR>, typing
     along <CR>, ..., typing in last line <CR>, <refresh> ...

     Whatdaya think?


  4) A variation on (3), WRT a cut'n'paste interface.

   - I don't often use cut'n'paste, and I don't know how it is typically
     implimented.

     I suppose that if it appears to the application (lynx), just like the
     data came from the keyboard, then this is exactly like (3), meaning
     that you'd get screen refreshes after each new line (or group of lines)
     were added.  I dunno if there might be overrun problems with that, or
     not (does the cut'n'paster "throttle" when it's output is "blocked",
     etc ?).


Good ideas.  Lesee what I can come up with ...

/kim


PS: I am still looking for a function() in lynx, that will move the cursor
    to a specified line number within a page (when it is known that that
    line is a link/anchor).

    Anybody know of such a beast ...?

reply via email to

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