On Mon, Jun 29, 2026 at 09:59:29PM +0200, Mike via Lynx-dev wrote: > I've created a PHP application (https://github.com/decision-making-mike/lms). > It allows the user to enter information via <input> (without the "type" > attribute, if it matters). I needed to test it in lynx. The testing > involved inserting a tab character, and I've got two related questions. > > The first question is about the key combination c-x, e. I discovered that I > can use it to invoke an external editor (and insert the tab character there). > The page at > https://lynx.invisible-island.net/lynx_help/keystrokes/edit_help.html states, > for this and the other two commands, that "these are special commands for use > only in textarea fields". If so, why does c-x, e work in <input>? Is it > implied that everything for <textarea> will work for <input>? If it's not > implied, maybe this behavior could be documentated on the mentioned page?
I did that in https://lynx.invisible-island.net/current/CHANGES.html#v2.8.8dev.10 2012-02-12 (2.8.8dev.10) * extend ^X-e editing of textarea's to include single-line fields -TD and apparently didn't think to see where I might improve the documentation. The bindings are complicated to work through... Looking at the source history, I see that I implemented it with this function: /* * Similar to HText_EditTextArea, but assume a single-line text field -TD */ void HText_EditTextField(LinkInfo * form_link) which is called from handle_LYK_EDIT_TEXTAREA. Reading that, it's easy to see that all I did was extend this function to allow it to work with input fields as well as textareas (no change to bindings): pre-existing: } else if (LinkIsTextarea(curdoc.link)) { added: } else if (LinkIsTextLike(curdoc.link)) { So... in answer to Is it implied that everything for <textarea> will work for <input>?# no, it won't (I suspect you're asking about "Insert file in textarea"). > The second question is about the key combination c-x, c-e. I discovered that > I can use this one, too, to invoke an external editor. Is this combination > documented somewhere, or is it a behavior specific to my installation? If > the latter case, maybe someone could help me discover what might define it on > my machine. Or, maybe lynx just ignores the second control character? I see this this in the source code, but it's not shown, e.g., in the generated page for "k": k KEYMAP display the current key map K EDITMAP display the current edit-key map That is, a shift-K (by default) gives a generated page for EDITMAP, which I see beginning with These are the current edit-bindings: Bash-like Bindings That link goes to the preformatted page that lead you to edit_help. On the generated EDITMAP page, I see SETM1 Set modifier 1 flag - ^X The source code has the table for the ^X in src/LYEditmap.c: https://github.com/ThomasDickey/lynx-snapshots/blob/29d5a703b02a2c137c8c03949ccfec74d6c17b8a/src/LYEditmap.c#L133 static const LYEditInit initMod1Binding[] = and has entries corresponding to ^E and e: {CTL('E'), LYK_EDITTEXTAREA | LYE_FORM_LAC}, and {'e', LYK_EDITTEXTAREA | LYE_FORM_LAC}, However (in a quick read), it looks as if I decided the preformatted page had enough information for the "modifier 1" that it wasn't necessary to generate a nice view of that table. I did that (making the generated page) here: 2013-11-28 (2.8.8dev.17) * add internal URL "LYNXEDITMAP:", which is (like "LYNXKEYMAP:") generated, making that the primary page for field-editing help -TD > I'm using lynx 2.9.0dev.5, if it matters. > > Mike > > -- Thomas E. Dickey <[email protected]> https://invisible-island.net
signature.asc
Description: PGP signature
