Open Bug 103767 Opened 23 years ago Updated 2 years ago

Key to start $EDITOR for <textarea> (external text editor)

Categories

(Core :: DOM: Editor, enhancement)

enhancement

Tracking

()

Future

People

(Reporter: malx, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted)

The best editor is the one, which is set in $EDITOR of every unix user! So you need to make shortcut (same as in lynx) to start it for editing of <textarea> fields (or may be DblClick on field also will do this?). You just can't make own editor so powerfull as vi :) it whould be waste of time. Or may be it whould be defined by special option in preference? (if so - you hould also think about leting this external editor to get line number to start at and charset). So you could set "xterm -e 'vi $file' -fn '*-$charset'" (also tell user if $EDITOR is not set - especially for Win*) This need becomes clear, if you whould recall number of Web based Forums and Free Mail services. Most of them make <textarea> for 800x600 - too small for 1024x768 :(
See also bug 35268, [RFE] Edit Source using External Editor.
Summary: [RFE] Key to start $EDITOR for <textarea> → [RFE] Key to start $EDITOR for <textarea> (external text editor)
-->Future Maybe this bug should really go to HTML Form Controls or XPApps (for helper app work)?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Fun idea; it would actually make web mail usable. I don't expect we'll have the resources to do this any time soon, but it would be a nice self-contained project for someone to contribute. (Minor nit: $VISUAL, if it's set, should override $EDITOR.) It could be implemented as a form control issue (start editor on focus in) or as a key binding inside the editor. I'm leaving it as editor/core because if we built it in as an editor command it would also solve the much-requested comparable problem in mailnews. Not sure who should own it; Kin, if you don't want it, I don't mind having it on my list (but still future/helpwanted). If anyone wants to volunteer to work on it, I'd be happy to offer suggestions.
Keywords: helpwanted
dup of bug 13474?
This one is a subset of bug #13474 And it is mor likely to be dup of bug #72539 But It could be implemented faster, then #13474 (with all proposed pipes) Maked as dependens (am I right?)
Depends on: 13474, 72539
Summary: [RFE] Key to start $EDITOR for <textarea> (external text editor) → Key to start $EDITOR for <textarea> (external text editor)
Mozex (firefox addon) currently supports choosing a hotkey to edit the textarea. Works for me with xemacs's winclient.exe using Firefox under Windows XP to edit trac wiki pages.
QA Contact: sujay → editor
Assignee: kinmoz → nobody
The new add-on architecture rendered "It's All Text" and friends unusable. Apparently, it is impossible to write an add-on which directly communicates with the browser via the filesystem. A few new add-ons try to work around this by implementing a server which acts as glue between Firefox and the eternal editor, most notably: * https://addons.mozilla.org/en-US/firefox/addon/ghosttext/ * https://addons.mozilla.org/en-US/firefox/addon/external-editor/ However, this approach is cumbersome and error prone, currently none of these new add-ons works satisfactory across different editors. Specially developers need a way to edit large textarea content in external editors (e.g. documentation wiki à la GitHub) to be productive and prevent frequent copy-pasting. Thank you so much for giving this really long-running feature request (nearly two decades!) a thought, proper support for textarea external editors would be a killer feature for many people, most certainly developers!
I really miss the "It's All Text" extension and i also think that the recent approaches with bridging native apps are not a good idea. Implementing a "edit textarea with external editor on hotkey" should be not a difficult thing and really more secure than recent approaches.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.