[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev Any word on status of extended text entry fields?
From: |
David Combs |
Subject: |
lynx-dev Any word on status of extended text entry fields? |
Date: |
Fri, 1 Jan 1999 15:48:59 -0800 (PST) |
To: address@hidden
2 Subject: Re: lynx-dev Any word on status of extended text entry fields?
3
4 > From address@hidden Thu Dec 31 23:06:01 1998
5 > Date: Fri, 1 Jan 1999 02:03:37 -0500 (EST)
6 > From: address@hidden (Larry W. Virden)
7 >
8 > At one point back in the old days of 1998 I thought someone was going
to
9 > be working on a 'safe' way of letter the user drop into an editor for
10 > text entry fields in the same way that they drop into the editor when
doing
11 > a mailto/news/nntp type entry.
12 >
13 > I don't recall that code ever appearing though - is someone really
working
14 > on that feature? It's one I really could use almost daily...
15
16 I suppose Larry is talking about multi-line entry-fields.
17
18 Now, not having somewhere right off that has such an
19 entry field to try, let me ask if THIS would work ok:
20
21 The way I work is that I *always* have a full-screen emacs
22 going (I keep it up for weeks at a time).
23
24 To get into netcom.com for my shell account, I press "front"
25 on my sun keyboard, which brings-forward a full-screen
26 "shelltool" (something like a dos-prompt window), in which
27 I run Kermit, and dial into netcom, log in, read mail,
28 and eventually run lynx.
29
30 I find that to type in a long address, for eg the G lynx
31 command, that it is easier to fix mistakes sometimes if
32 I first flip back to the emacs full-screen window, type it
33 in there, get it correct, regionize it, then "copy"-key it,
34 flip back to the shelltool window, and "paste"-key it
35 into the g-entry -- works fine.
36
37 Now, I wonder if I could do that for a MULTI-line input
38 into a text-entry area -- type in all the stuff into
39 emacs, and paste it into that text-area
NO CARRIER
[You can see that I just did the opposite after netcom or
one of its communication lines just now crashed -- having the
emacs session always there is really nice, especially you can do
a "paste" into emacs via its "y" (yank, opposite meaning
to vi's "yank") command. I'll now finish the email "off line"!]
. If that would work, then doing it this way would seem almost
FASTER than by having to start up some editor (unless it's super-fast,
like vi or its ex).
UNLESS perhaps it was fixed up so that you could fill in ALL the
text fields with ONE editor-invocation, ie could go, via your favorite
editor's friendly well-known commands, through the entire screen-full
of text areas, filling each one in via the editor -- and then
via the editor-commands, going down to the NEXT text-area, filling
it in, etc, finally exiting the editor only when you've filled
in ALL of them...
although to make that possible, the page would have to be reformatted
such that there would be only ONE text-area per line, so that it would
be easy to input EXTRA lines via the editor.
Then, when done, you "wq" or "x" or whatever from the editor, and
lynx would figure out
(via a crude "diff"?, or via lynx-generated
"textArea LABELS" on the page you edited and which you promised
to not change while editing)
and would then actually itself do the "filling in" of the textareas,
and fire the page back to the www-site.
Seems like a lot of work.
---
Shorter than that, seems like my trick of the full-screen emacs window
just behind the one with kermit+netcom+lynx in it would suffice.
With only two windows "up" (not "minimized") it's only one key-push to
get to where I'm typing into emacs, then regionize (usually
control-space then 0k) then "copy"-key, then that same key-push again
to get back to the window for lynx,etc -- then ONLY NOW the the real
"pain" part -- have to finally take my right hand from the keyboard
and reach over for that (stupid) mouse and maneuver the cursor to that
input area (for eg lynx's g), and then, right hand happily back where it
belongs (ie, on the keyboard), hit "paste".
(last but not least, maybe -- if line crashes as I'm doing all this,
at least I have a record, in that emacs buffer I was typing into.)