[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 ...?
- lynx-dev Some thought on additional TEXTAREA functions,
Kim DeVaughn <=
- lynx-dev Redundant link movement cmds? (was: Some thought on additional TEXTAREA functions), Kim DeVaughn, 1999/01/30
- Re: lynx-dev Redundant link movement cmds? (was: Some thought on additional TEXTAREA functions), Leonid Pauzner, 1999/01/30
- lynx-dev Re: Redundant link movement cmds? (was: Some thought on additional TEXTAREA functions), Kim DeVaughn, 1999/01/30
- Re: lynx-dev Redundant link movement cmds? (was: Some thought on, Larry W. Virden, 1999/01/30
- Re: lynx-dev Redundant link movement cmds? (was: Some thought on, Philip Webb, 1999/01/30
- Re: lynx-dev Redundant link movement cmds? (was: Some thought on, Larry W. Virden, 1999/01/30
- Re: lynx-dev Redundant link movement cmds?, Philip Webb, 1999/01/30
- Re: lynx-dev Redundant link movement cmds?, Larry W. Virden, 1999/01/30
- Re: lynx-dev Redundant link movement cmds?, Klaus Weide, 1999/01/30