[Pmwiki-users] Workflow when editing wiki pages from an external editor

[Christian Ridderström]

Hi

I'd like some input/thoughts on an expanded workflow for when you use an
external editor to work on wiki pages. Primarily I'm interested in
thoughts on how to handle concurrent edits, i.e. when someone else is
editing the same page that you're working on.

As background, here is the minimal workflow where everything is done from
within Emacs and only user edits the page. (Actually, today this process 
completely ignores other users and their changes are overwritten)

# The user opens a wiki page (by specifying the URI of the wiki page)
# The user edits the page source
# The user uploads the modified page source

That is a very minimal example. In practice, the following workflow is
much more common for me:

# Using e.g. Opera, the user browses a wiki site and then types 'C-e' to 
  edit one of the wiki pages. This signals Emacs to open that wiki page.
# The user types 'A-TAB' to switch to Emacs
# Now the next three steps are repeated for a while
## The user edits the page a little bit
## The user types 'C-c C-c' to upload the changed page to the wiki site
## The user types 'C-c C-b' to signal Opera to reload the page
   (so that the user can see the result of his changes)

These last few steps may actually be repeated over a time period of
several days, where the local copy of the wiki page is simply left in one
of Emacs' buffers in between.

Other pages are of course opened and edited in between (either from within
Emacs or from Opera), but that shouldn't affect the current main cycle:

# The user opens a page in Emacs
# Repeat:
## The users edits a page a little bit in Emacs
## The users uploads the changed page to the wiki site
## The users reloads the page in his browser

One drawback with this cycle is that you get a lot of small changes, so I
expect this workflow to be modified in the future to look more like this:

# The user opens a page in Emacs
# Repeat:
## The user edits a page a little bit in Emacs
## The user invokes a "preview" (which shows the page in a browser)
# The user comits the changes permanently

Now let's go back to the situation where we have concurrent edits. This
ought to be quite common since an edit cycle might occur over a few days.

So what I'm looking for now is some thoughts and ideas on how the workflow
should be modified to handle concurrent edits of a page. Perhaps it is
even possible to design a workflow that makes concurrent edits desirable.

PmWiki 2.0 will support merges, so here's one possible workflow:
# Repeat:
## The user edits a page a little bit in Emacs
## The user invokes preview ("external" changes are ignored)
# The user comits his changes in such a way that pmwiki automatically
  merge these changes with any changes made to the wiki page in between.
# Emacs automatically reloads the result of the merge

Here the preview was "private", i.e. only you see it. I can imagine
situations where you actually want to use a common preview, e.g. when
collaborating closely with someone.

As for the comit process, I can imagine extensions to it where the user is
allowed to choose between:
* Let PmWiki automatically merge changes
* Skip local changes that the user has made
* Overwrite changes that someone else has made
* Update local Emacs buffer with changes that someone else has made
* Download the changed wiki page into another buffer in Emacs, so that
  the user can compare the two page sources.
* Other alternatives?

Another interesting function would be to let Emacs monitor the wiki page,
and when someone else changes it, this is indicated by some message in the
status bar (e.g. "Page has been externally modified").

It might also be interesting to introduce an 'update' function in Emacs,
where if the user types e.g. 'C-c C-u', the changes in the local buffer
are merged with changes from the wiki site.

I'm not saying I will implement all of these ideas (or any, but I'll
probably do some of it). However, before I start I'd like to have a clear
idea of what I'm trying to accomplish --- figure out what functionality I
really need.

/Christian

PS. Notes on implementing a preview:

Preview could for instance consist of uploading the page to some kind of
temporary page, and have the browser show this page. I guess this is
something I could implement purely from inside Emacs, by uploading the
page to a page called for instance "Main/Preview<user>_<page>". When the
user then saves the change permanently, Emacs could automatically delete
the temporary page. A drawback with this is that the page wouldn't be in 
the group where it will be stored in when it's saved, so it may not look 
correct. That drawback might be solved if it's possible to give a separate 
parameter in the URI, e.g. 'faked_pagename=Some/Page'.

There are problem other ways of doing previews, but I think how to do the 
preview should be solved after the other parts of the workflow are nailed 
down.

-- 
Christian Ridderstr?m                           http://www.md.kth.se/~chr