Editing in a browser's textarea is no fun.
How about downloading the text to your favorite local editor
and uploading it back up again?
Besides being more convenient while editing,
the turnaround time could be faster.

Ideas

The download part is rather trivial: send down the pages text, with proper spacing;

I'm using that now, then paste back from the editor into edit pages textarea

Do not send down form fields; it is a form, because you want to enforce values - you can't in the editor

For upload, change the edit page - instead of textarea, have an upload button like the attach page; handle the form stuff there

Yes, all meta tags should be removed and later on added again, but the problem is that you don't know what version you were editing.
So possibly, add a %META:REVISION{r1.2}% - Don't remove this line! to the top of the text. If it's not there, pretend that it is the latest version. Ok, this all doesn't really matter now, but one day TWiki will perhaps be able to do revision merging, and we should be ready

As for downloading file names, content-disposition: inline; filename=%TOPIC%.twiki should do the trick. Not all browsers honour this, though, but netscape and ie seem to.

And the panel where you download the file could already have a form to upload it with the filename preloaded, so that you can easily edit it and just click on upload.

And as for starting the editor from the browser, because I chose .twiki as the extension, you could configure your browser to automatically run your editor with that type of file.

So it's all possible, with a little tweaking on the user side, but that's easily explained.

Thanks for the tip; before that, the files used to have no extension.
Still, netscape sometimes turns the name into garbabe like
VUG8GIJG.twiki.
Hmmm. Could be this happens, when I download the same name twice?
Anyway, here's the diff, which adds the option ?download=on
to the view script.

Nice. I would make the Content-Type be 'text/x-twiki' though, I think that follows the standards more. What about adding a timestamp so that you never download the same file twice?

I tried making text/x-twiki being handled by Kate on my KDE desktop, but the problem is then that when I open the file directly from the web, it gets a random filename. When I download with mozilla, it doesn't, but it adds a "-1", "-2", etc if the file already exists.

I also tried embedding it as an <OBJECT>, but that didn't really do any good either...

Ah well, at least I can edit the text in gvim now, all we have to do now is uploading it.

Zope (www.zope.org) has a thing called ExternalEditor. It's a system based on a clientside helperapp. You download the file/document you want to edit, the helperapp gets fired up, helperapp then fires up your preferred editor and keeps track of the (temp) file. Every so often the helperapp uploads/saves your file, and when you close the editor it saves the file for good and unlocks the file.

Perhaps with a little change (e.g. get rid of webdav) it could be a great add-on to TWiki.
If we then also can make a wysiwyg WikiML editor (just a normal desktop thingy, not a plugin) or a WikiML mode for e.g. Word/Emacs/.../... then we're there I guess. Also it then becomes a breeze to store e.g. Excel sheets in wiki, edit and save to the wiki - total office integration (a la Livelink).

First Pass at a Solution

So eventually a grad student wasting time is going to post a script...

I've written a little daemon that uses a FIFO to communicate to get and store
files to a TWiki. You supply your authentication to it and then talk to it
over the pipe, checking a log for errors and results. Add a couple of scripts
for the VimEditor and essentially the editor turns into a primitive Wiki
browser/editor system.

BUG WARNING:
this kills your form content
Which is odd, as other meta data like attachments and the form assignment stay intact!
... 5 seconds of thinking reveal:
of course this is not odd, it is obvious,
as this is what people manipulate from within the edit page,
not the form type, not the attachments...

The Electrix addon for Mozilla 1.3+ lets you use the editor of your choice for textarea. 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.

I have a different method that works around this and suits me well. On unix, I keep a GUI browser and lynx side by side on the screen. When I want to edit a topic, I pick up the URL from the GUI, paste it into lynx and change view to edit. Lynx uses my preferred default editor (^Xe on an editable text area to get it) and I can easily save a copy to my own /tmp/foo as I work, e.g. if the phone rings. Things like search/replace are easy, and you get a view of the (original) GUI-presented topic while you edit which I find saves a lot of head-scratching delays. This method might suit some other unix people who have strong favourites for text editors, in the interim at least.

By the way, I have tested EditTWikiExternalEditorAddOn and it worked pretty well with several editors (including emacs). However, that was on Beijing; I have not tested it against Cairo yet. There also is EditorDaemonAddOn which I believe people have used with vim.

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.