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•18 years ago
|
QA Contact: sujay → editor
Updated•18 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
•