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.