This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Currently the external editor supports XEmacs, VIM, and two user-defined editor types USR1 and USR2. This style is inconsistent with other NetBeans configuration UI and does not take advantage of the Services API. Proper style is to (1) define an abstract class e.g. ExternalEditorType extends Object implements Cloneable, Serializable, with some method(s) to initiate a connection and so on; (2) each EET subclass (XEmacs + VIM perhaps) contains bean properties such as command, host/port/password, XEmacs library location, whatever is appropriate; (3) default instances of available EET subclasses are placed in Services/ExternalEditorType/ in the layer using .settings files with appropriate localized names and icons; (4) UI/Services/.../Editing/ contains a .shadow file pointing to Services/ExternalEditorType so it appears in the Options dialog; Templates/Services/ExternalEditorType/ contains templates (.settings with template=true file attr) for each kind of external editor so that the user could create more of them, e.g. alternate XEmacs configurations; (5) the main system option selects the external editor type according to a property editor of type Object constrained to load only ExternalEditorType, as described in the Services API "Property Editor for Services", and saving the selection as a lookup ID. You might have a generic EET subclass "unknown external process" applicable to VIM and so on, with an arbitrary number of preconfigured instances in Services/ but perhaps only one template in Templates/Services/, which would launch a configurable process but not provide any further UI to the user; use methodvalue="" in your .settings to employ static factories to preconfigure several standard instances of one class. This is as opposed to the XEmacs type which permits the library location to be configured and so must be a subclass. An additional advantage of the services style is that if ExternalEditorType is public and maintained compatibly, additional modules could provide support for other editor types if they require special setup beyond making a connection.
No need to extend ServiceType. You can just create abstract ExternalEditorType extends Object and find it using lookup. Rest is the same as Jesse suggests. And yes, this is the preferred way to implement plug-in extensibility.
[S1S-EVAL]