-- DaveHolcombe - 05 Jul 2000

Using an HTML editor of choice would be most flexible for users, but has these issues:

• On a topic edit:
  • Text needs to be converted first from WikiSyntax to HTML before feeding it to the HTML editor.
  • How to handle topic lock.
• On topic save:
  • Needs to be done on FTP level. Setup issues on server side.
  • How to handle versioning of topics.
  • How to handle topic (un)lock.
• A page that is saved by an HTML editor is in HTML format, e.g. not as easily editable anymore in the conventional Wiki way. It would be useful to have some intelligent HTML to Wiki conversion on topic save.

The ideal solution would be an HTML edit widget in the browser. The hurdle is that the current <TEXTAREA name="text" ...> is a rather primitive text edit widget of the browser. It would be nice to have a HTML edit widget like <HTMLAREA name="text" ...> that allows editing HTML in WYSIWYG style, but that means waiting for a next version of HTML and browsers supporting it.

-- PeterThoeny - 05 Jul 2000

It is possible to edit TWiki topics in an external editor already, but you almost have to be a command-line junkie and a no-graphics bigot to do it. ;-)

I frequently edit long topics or topics I want a lot of control over using Emacs in w3 mode. This is a Web browsing mode much like Lynx (only weirder.) It is also possible to specify an external editor in the latest versions of Lynx; I do this and of course I use Emacs, but there is no reason I can see why it would not be possible to use Notepad or even Hotmetal under Window$^©®TM. The external editor is not for editing the page, it's for editing the TEXTAREAs in the page's forms. This is an huge distinction, and a big win over the graphical browsers.

There are other issues than those that Peter alluded to with this: you can't have your editor automagically adding things like headers and whatnot, or even generally correcting your HTML for you--there are many TextFormattingRules and HTTPD server issues that an HTML editor won't be aware of. To really see this in action, just look at the source for this page and then edit it to look at the user created content; they are very different. I generally find that a hand-holding HTML editor is no substitute for knowing the tags and attributes I need anyway. This doesn't mean you have to have an encyclopedaic knowledge of HTML; a good reference book will do.

It would be very nice if the graphical browsers would catch up with Lynx and W3, and allow you to select an editor for forms content, until then we just have to make do.

-- KevinKinnell - 07 Jul 2000

Another option would be to use an applet instead of a <TEXTAREA ... > widgit. Ideally an open sourced applet could be used that can then be customized to support the proper TextFormattingRules.

-- JamalWills - 17 Jul 2000

I like the idea of an applet for WYSIWYG editing based on the TextFormattingRules. Alternatively a DHTML editor with JavaScript could be created. The type of editor needs to be made configurable in the user preferences, with a fallback to the current form based editor (for users in an environment that does not have Java or DHTML.)

-- PeterThoeny - 20 Jul 2000

This should probably go in a topic like UsePageEditorOfChoice

It is in AppletBasedEditor topic.

I've removed my previous contribution because I have implemented a solution that works with the VimEditor. I've posted it to EditDaemonWithGVimIntegration.

-- SimonClift - 12 Nov 2002

Simon, thanks for your idea. It seems like a possible solution. By constraints, is will be kind of a complex design. There are some "gochas" to watch for:

• Allowing any type of HTML editor will result in HTML text that looks different from the original one even if you change only one word, i.e. some editors add style sheet information, some change HTML tags from upper case to lower case, some change white space. This is not a problem when you view at the resulting topic, but the revision history of a topic would get unusable if there are consecutive edits by users who use different HTML editors. This can be somewhat addressed by "purifying" text back into the WikiSyntax before save. The question is how extensive that can be done.

• Requiring JavaScript and/or a browser plugin raises the RequiredEnvironmentForTWiki, it also raises questions about security and upgrade issues. Raising the required environment could be acceptable because using another editor then the default is optional.

• The category table can't be supported with an HTML editor. You can't tell an HTML editor to treat some part of the HTML text as a form.

To me, the ideal solution would be an optional TWiki specific browser plugin that offers a WYSIWYG editor based on the WikiSyntax. That way we would have control over the text formatting and also th category table.

-- PeterThoeny - 09 Mar 2001

It would seem to me that you could do an applet using some open source editor code like that at http://www.jext.org/ or pehaps even http://jedit.sourceforge.net. Maybe a rainy day project

Also see http://dmoz.org/Computers/Programming/Languages/Java/Applications/Text_Editors/Open_Source/

-- AlWilliams - 08 Sep 2000

Naive question refactored into ImplementationLanguageChoice as suggested by DavidLeBlanc ;^)

-- MartinCleaver - 16 May 2001

Re editing: If one did allow pages to be edited in an html editor, upon input, the text could be "devolved" into Wiki markup (as opposed to html markup) so that future editors (people) can continue to use wiki markup instead of html.

Re languages: Let sleeping dogs lie - use python or die!

-- DavidLeBlanc - 10 Mar 2001

This topic's been dead a long while now. I've just started using TWiki and have on occasion wished for an easier way to edit the Wiki markup. I'm not asking for a WYSIWYG editor but just a little more convenient way to edit the markup, which means I'm really interested in UsePageEditorOfChoice.

What I think would make my life easier is two tiny additions to the edit screen. One to allow downloading of the current Wiki markup and an option on the form to upload the markup. Making large edits could then be done by:

1. Click "Edit"
2. Click "Download Markup" and save the file locally
3. Edit the file locally with my favorite editor (vi)
4. Upload the editted markup, giving me the preview screen
5. Click "Save"

This has mostly the same implications as a lengthy encounter with the TEXTAREA editor in your browser. The edit lock is kept the whole time. No fancy translations should be necessary. There are some advantages though:

• A brand new lengthy page can be edited over a long period of time, off-line, or with a fancy editor and then uploaded to a new page only when ready.
• It makes a poor-man's import much easier. I spent like 30 minutes yesterday getting a section of a word doc into a wiki page, involving much cut-n-paste.
• It makes you much less likely to lose your work during a lengthy edit of a single page. Your local text editor probably has better "undo" features and even some form of crash-protection.
• You can use all the features of your editor. In particular, I like to use auto-indent, search/replace, spell-check, embed text from other sources, etc.
• Off-line editing of an existing page can be done if you're careful. As long as no one else edits your topic you'll be okay. This is fine on pages which are edited by only you for whatever reason.

-- PaulChamberlain - 27 Jan 2002

I have started using the w3m text browser. It allows you to launch an editor of your choice for textarea boxes. Since I use Linux, I was running w3m in a term and then launching gnuclient to get a fast xemacs window for editing. That worked pretty well, but wasn't as smooth as I liked. I've since found the emacs-w3m package that allows me to embed w3m into xemacs. This works really well. When I go to edit a textarea, it just creates a new buffer for me with the edit text. To "put" my edits back in the form I just do C-c C-c. I've even gotten a wiki mode to do highlighting for me. Take a look at http://www.emacswiki.org/cgi-bin/wiki.pl?WikiModeDiscussion for more information.

-- DougAlcorn - 06 Jul 2002

Several of us seem to want an alternative to the textbox widget. See topics like this one and AppletBasedEditor, JavascriptBasedEditor, etc. After reading these three threads, I don't have a clear sense of whether there is an alternative available today or not. Can someone kindly clarify this to a newbie (namely me)? If an alternative exists, please let me know how to use this alternative. Should I set a Twiki variable like %EDITOR%? Thanks.

Wouldn't it be fairly easy to tell Twiki to launch an editor (like vim(1) or emacs(1)) instead of a textbox?

-- KripaSundar - 02 Aug 2002

See also DownUploadForEditing for a simple basic idea of how to download text into your favorite editor.

-- ClausBrod - 23 Sep 2002

If you don't mind using HTML markup for storage instead of TML, for those using mozilla there's always http://composite.mozdev.org/

"ComposIte is a chrome overlay which enables a streamlined Mozilla Editor for html composition in textareas. To use the editor, hit ctrl-e in a textarea."

Not suitable for every instance as looking at the output it produces you wouldn't want to edit it in the textarea afterwards, i.e. don't use it unless it's approved practice for a particular TWiki site. If all users are using it (small group collablorating using TWiki / corporate intranet) then that wouldn't cause problems. The output is very compact, no unneeded line ends, so it probably wouldn't look good in diffs.

Now I'm wondering if you could get it to output in TML instead.

-- SamHasler - 26 Sep 2002

I've started a CompositeEditor test page in Sandbox. If the output code can be cleaned and wikified this could be very exciting.

-- MattWilkie - 27 Sep 2002

I just downloaded CompositeEditor and found the approach interesting. By hacking the composite.js file (function compositeSave), you can even insert your own favorite line style. For instance, I now get proper CRLF sequences instead of those <br> tags.

However, this will only work as long as TWiki content is kept in strict HTML format, or else the Composite HTML editor will act up. I'm wondering if the Composite approach could be modified so that instead of opening an edit window within Mozilla, it would simply launch a user-selectable editor (Emacs, vi, HTML editors, whatever). But I guess since this is all JavaScript code, there's no way to launch an external application. Or is there?

-- ClausBrod - 27 Sep 2002

See MozillaBug:13474 - this patch lets Mozilla users launch external editors by hitting a key within any text field. Also discussed in Emacs topics on Support or Codev.

-- RichardDonkin - 30 Sep 2002

The Electrix addon for Mozilla 1.3+ takes this patch, or the idea behind this patch, a step further - it can be installed via XPI. Mozilla freezes while the external editor is open; the author says he is looking for away around this. Personally in the light of problems like BackFromPreviewLosesText I think this might be feature. http://reddleman.org/site/projects/electrix/index.html

-- MattWilkie - 27 Jul 2003

We have a very workable arrangement in HtmlAreaEditor, which really should be packaged as a plugin.

-- MartinCleaver - 27 Jul 2003

Electrix looks like a godsend, and it works for me, but only for certain editors. vim and Emacs work as expected, others do not terminate properly after saving and exiting, causing Mozilla to freeze. I'm using Mozilla 1.5a.

-- ClausBrod - 30 Jul 2003

I used to use mozex to launch vim. Since we have been prevented from using Firefox I've written some javascript to do a similar thing for internet explorer. I'll post it here if anyone is interested.

-- DanielShields - 03 Jun 2005

I have been using GNU EMACS' w3m, a web browser within EMACS, so I click on the text area and get an EMACS buffer that I can do real editing on.

In ThoughtsAboutUsingExternalApplications I write about using generic external applications, possibly even Word or Vision Most recently have added thoughts about doing file format conversion on the server side, so that a Word document, e.g., can be converted to wiki text. Or, my interest, a Visoo drawing to a GIF so that it can be seen on the wiki page.

-- AndyGlew - 15 Jul 2005

HTML editors can be integrated using the WysiwygPlugin infrastructure, which currently supports Kupu but could easily support other client-side editors.

-- CrawfordCurrie - 16 Jul 2005