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)
Core
DOM: Editor
Tracking
()
NEW
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 :(
Comment 1•23 years ago
|
||
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)
Comment 2•23 years ago
|
||
-->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
Comment 3•23 years ago
|
||
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
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?)
Summary: [RFE] Key to start $EDITOR for <textarea> (external text editor) → Key to start $EDITOR for <textarea> (external text editor)
Comment 6•18 years ago
|
||
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.
Updated•17 years ago
|
QA Contact: sujay → editor
Updated•17 years ago
|
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!
Comment 8•6 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•