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
- Use this as a primitive ReadWriteOfflineWiki
- download web in one go
- edit locally
- upload touched files manually
Problems:
- How to connect the upload dialog and your editor session? Filename is a bit clunky:
- download this to c:\temp\DownUploadForEdit
- hit upload
- manually select c:\temp\DownUploadForEdit
- To make things worse: often, the browser picks completely incomprehensible, temporary filenames! I tried the HTTP Content-Location field, but it doesn't do the trick
Any tips for implementing the upload page
+ clever filename handling?
--
PeterKlausner - 23 Aug 2002
Great idea (I have been thinking about it myself

)
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.
--
WoutMertens - 23 Aug 2002
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.
diff -c view raw
*** view Thu Aug 22 14:24:21 2002
--- raw Fri Aug 23 15:42:58 2002
***************
*** 73,78 ****
--- 73,79 ----
my $revuser = "";
my $pdftitle = "";
my $pdfcall = "";
+ my $download = $query->param( "download" ) || "";
my $viewPdf = $query->param( "pdf" ) || "";
my $viewRaw = $query->param( "raw" ) || "";
my $unlock = $query->param( "unlock" ) || "";
***************
*** 116,121 ****
--- 117,132 ----
$text = &TWiki::Store::readTopicRaw( $webName, $topic );
} else {
( $meta, $text ) = &TWiki::Store::readTopic( $webName, $topic );
+ if ( $download ) {
+ print "Content-Type: application/twiki-text
+ Content-Location: $theUrl/$webName/$topic
+ Content-Disposition: inline; filename=$topic.twiki
+
+ ";
+ $text =~ s/^ / /mgo; # convert _leading_ tabs
+ print $text;
+ exit;
+ }
}
( $revdate, $revuser, $maxrev ) = &TWiki::Store::getRevisionInfoFromMeta( $webName, $topic, $meta, "isoFormat" );
--
PeterKlausner - 23 Aug 2002
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.
--
WoutMertens - 25 Aug 2002
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.
See
http://www.zope.org/Members/Caseman/ExternalEditor/readme for a more detailed explanation and
http://www.zope.org/Members/Caseman/ExternalEditor for sourcecode etc.
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).
JeroenVanDongen - 31 Oct 2002
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.
I've put this up on the page
EditDaemonWithGVimIntegration
--
SimonClift - 12 Nov 2002
Interesting stuff - I use
VimEditor a lot for coding so it would be nice to use it for TWiki editing as well. The page you mentioned doesn't exist yet, but I'm sure it will
--
RichardDonkin - 12 Nov 2002
You were too quick...
--
SimonClift - 13 Nov 2002
A couple of related pages are
http://www.emacswiki.org/cgi-bin/wiki.pl?WikiRemote (similar concept for
EmacsEditor? and
EmacsWiki? ) and
http://www.decafbad.com/twiki/bin/view/Main/XmlRpcToWiki (using
XmlRpc to link a
WebLog to TWiki). However, neither of these uses
vim so clearly not as good
--
RichardDonkin - 17 Nov 2002
The text mode browser 'w3m' uses vim (or whatever $EDITOR is set to) when editing textareas. See the update at the bottom of
EditDaemonWithGVimIntegration for more.
--
TWikiGuest - 03 Dec 2002
It looks like the Zope-Guys do have a solution for this take a look at
this for details. I'm not sure how it works but maybe it helps.
--
NilsBoysen - 03 Jun 2003
The mechanism of the Zope solution is the vision of this topic.
Unfortunately, the server part does not exist (yet).
http://www.zope.org/Members/Caseman/ExternalEditor/readme
explains:
- 7
- Every so often (if so configured), the helper app stats the content file to see if it has been changed. If so, it sends an HTTP PUT request back to Zope containing the new data.
If TWiki understood
WebDAV PUTs, i.e.
TWikiWebDavServer were implemented,
at least we could re-use the client helper app.
...
Just to have a primitive starting point:
I hacked
savemulti like so:
RCS file: /var/cvs/twiki/bin/savemulti,v
retrieving revision 1.1
diff -c -r1.1 savemulti
*** savemulti 2002/07/17 08:23:51 1.1
--- savemulti 2003/06/05 20:18:53
***************
*** 83,88 ****
--- 83,97 ----
# get text and other parameters
my $text = $query->param( "text" );
+ my $textfile = $query->param( 'textfile' );
+ if ( $textfile ) {
+ my $tmpFileName = $query->tmpFileName( $textfile );
+ open TMP, "<$tmpFileName" or die
+ "can't read $textfile from $tmpFileName: $!";
+ undef $/;
+ $text = <TMP>;
+ close TMP;
+ }
my $unlock = $query->param( "unlock" ) || "";
my $dontNotify = $query->param( "dontnotify" ) || "";
if ( $saveaction eq "Checkpoint" ) {
Then the added this form to the
oopsmore.tmpl template:
<form action="%SCRIPTURLPATH%/savemulti%SCRIPTSUFFIX%/%WEB%/%TOPIC%" method="post" enctype="multipart/form-data">
* *Overwrite topic:*
* Select local file
<input type="file" name="textfile" value="c:\temp\%TOPIC%.txt" >
then
<input type=submit value="Upload">
</form>
--
PeterKlausner - 05 Jun 2003
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...
--
PeterKlausner - 06 Jun 2003
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.
http://reddleman.org/site/projects/electrix/index.html
--
MattWilkie? - 27 Jul 2003
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.
--
SueBlake - 28 Jul 2003
By the way, Lynx now supports binary file uploads to TWiki attachments - see
BrowserIssues for the version required.
--
RichardDonkin - 29 Jul 2003
ThoughtsAboutUsingExternalApplications? discussses the generalization of this:
using external applications to edit attachments,
e.g. VISIO for drawings,
Excell for *.XLS.
I'm thinking about trying to use HTTP PUT.
(I've learned more than I wanted to know about HTTP trying to get
RedirectWikiUrls? .)
Q: I swear that I've seen some GNU EMACS packages that
allow wiki editing.
--
AndyGlew - 26 Sep 2003
This scenario can be simply realized with Mozex:
http://mozex.mozdev.org/
and if you want also to refactor, search and preview your topics, you may use Mind Raider
http://mindraider.sourceforge.net/docTwiki.html
--
MartinDvorak - 01 Mar 2005
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.
--
ThomasWeigert - 02 Mar 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