Open Bug 35268 Opened 24 years ago Updated 10 years ago

Edit Source using External Editor

Categories

(SeaMonkey :: Composer, enhancement)

Product:
SeaMonkey
Component:
Composer
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: alan-lists, Unassigned)

References

Details

(Keywords: helpwanted) 

I thought there was a bug on this, but I could not find it anywhere.  
mark as dupe if i just missed it.

It would be nice if Mozilla had the NS4.x ability to open an external editor for 
editing HTML source and image editing.

In 4.x the prefs are under Composer.  

We all have our favoriate ASCII text editors UltraEdit in my case.  When I want 
to edit the HTML source it would take you all a long long time to duplicate the 
features in UltraEdit.  So why not just give us a linke to external editors.

Not sure what all is involved, but this could be an easy way to get out of 
some of bug 14526.  If you all run out of time.
RFE->M20
OS: Windows 95 → All
Hardware: PC → All
Summary: [RFE] Edit Source using Exteran Editor → [RFE] Edit Source using External Editor
Target Milestone: --- → M20
Status: NEW → ASSIGNED
Target Milestone: M20 → Future
Adding helpwanted keyword and 4xp keyword, I hope you don't mind....

This feature is in Netscape 4.x and is very nice when you want to edit the 
source in your fav editor.  As it is n 4.x I thought 4xp keyword was important 
and helpwated in case someone else thinks they could pull this off.  

Of course I think bug 28792 "publishing facility in the editor" is more 
important.  However this bug/feature might be easier to implement by someone 
else.
Keywords: 4xp, helpwanted
CCing Hurricane (rcassin@supernova.org)

He may try this out 

/me hopes
*** Bug 52586 has been marked as a duplicate of this bug. ***
See also:
bug 8589   let "view source" open external editor.  
bug 47147  "edit image" with external editor.

As I understand it, this rfe is just for composer.
*** Bug 63790 has been marked as a duplicate of this bug. ***
*** Bug 69329 has been marked as a duplicate of this bug. ***
*** Bug 93946 has been marked as a duplicate of this bug. ***
-->brade
Assignee: beppe → brade
Status: ASSIGNED → NEW
spam composer change
Component: Editor: Core → Editor: Composer
See also bug 103767, [RFE] Key to start $EDITOR for <textarea> (external text 
editor).
Indeed, the View->Page Source window is nice enough to not
warrant any additional re-inventing of the wheel, but the
ability to call a user-specified external application 
instead would be yet nicer (substantially so, for those 
of us who use PSGML).  
And if the functionality exists to call an external 
viewer/editor for HTML source, Messenger could also
use it for composing mail.  Or should that be filed
(or has been already?) as a separate RFE?

Any chance of getting this feature into 1.0? And would it be much more than a 
UI pref? Many web developers I know (myself included) consider this the most 
missed feature from IE that Moz is lacking. (My girlfriend won't even use Moz 
because of it!) Just hopeful, although I know crunch time is on...

The keyword above ("helpwanted") means that no one is really working on this bug
yet (or if they are they haven't said so publicly).  Why not use File > Edit
Page and use Composer's HTML Source view?  If you have problems with that, I'd
love to address those (in separate bugs).  Thanks!
Summary: [RFE] Edit Source using External Editor → Edit Source using External Editor
Isn't this bug a dup or very similar to bug 13474 ?
Regarding comment <a href="#c14">Comment #14</a> above, the issue is not really
a bug regarding Composer. This bug is about being able to use whatever
editor/authoring tool the user wants to use, for reasons of power, accessibility
or preference. However, I agree with #15 above that this bug appears to be a
duplicate of <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=13474">Bug
13474</a>. Perhaps this one should be closed?


My understanding of bug 13474 is that it is specific to editing textarea
contents.  This bug is for editing the entire html source of a web page.  The
workaround in comment 14 is the workaround.  Right now, I have no plans to work
on this feature given the workaround.
-->
Assignee: brade → composer
The Comment #14 From brade@netscape.com in this bug looks intressting:
I try hard (for a long time) to motivate SOMEBODY to make the source 
view of composer useable for authors with needs for hand-formated html
source code  (even the head section). Due to several bugs (example:
    http://bugzilla.mozilla.org/show_bug.cgi?id=97278)
this is not possible since version 0.9.7. 
Now I think SOMEBODY==brade@netscape.com, because he wrote "... If you have
problems with that, I'd love to address those (in separate bugs).".
Mozilla is not useable for non-trivial html code, so please support an external
editor or make the html-source view useable for such tasks.
It would be nice to assign my external HTML editor, which is a text editor, to
the browser so that each time I upgrade the browser, it will not take over this
editors assignment to the Edit command on HTML and SHTML files.

I have to manually assign this program every time it is changed by Mozilla on an
upgrade install.
Adding myself to CC list.

Please change this bug's component to ViewSource; this bug has SFA to do with
Composer.

Please change this bug's severity to major.  I'm sorry, but this is not a RFE -
it's a BUG!  Loads of people want to be able to choose their page source editor,
and use IE because it allows them to.  Not being able to do it in Mozilla simply
sucks.
*** Bug 241441 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> As I understand it, this rfe is just for composer.

As I understand it, this rfe is to activate something *other* than composer when 
File|Edit Page is selected from the browser menu -- as noted in comment 16.  As 
such, it is filed under the wrong component.

I suggest that, on Windows systems, Mozilla provide a means to fall back on the 
system-defined HTML editor.  This is located in the registry, at
  HKCU\Software\Microsoft\Internet Explorer\Default HTML Editor
and the selection can be viewed in the Programs tab of the Internet Options 
control panel.  (Changing this setting in the control panel also changes the 
association of the Edit command in the context menu of Windows Explorer, 
something "Scott" [comment 20] might like to know.)

I don't know how, or whether, the other OS's define a system-wide editor; but 
ideally, a preference UI would be provided somewhere like:
  Edit pages using  ( ) Mozilla Composer
                    ( ) Default editor
                    (o) Other: myeditor.exe   [Browse]

For systems not supporting a default editor, that middle "default" selection 
could be disabled or, better, hidden.

This could be accompanied by a button, "Make Mozilla the default HTML editor", 
in which case the "Make Mozilla the default browser" action ought to be tweaked 
to *not* set Mozilla as the default editor, controlled separately (bug 196522).  

See also the Firefox bug 172817, which seems to be half about a feature like 
this bug's and half about a feature like bug 8589.
Product: Browser → Seamonkey
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
Ever confirmed: true

          You need to log in
          before you can comment on or make changes to this bug.