It seems to me that Change Tracking and Comments are pretty much the only features you need that couldn't be supported with svn (and a user friendly front end to it) - I note that other people have made similar points.

You'd probably be able to use the svn history data to get all the delta's and assign blame. If you tie comment locations to svn revisions, you should hopefully be able to recalculate the appropriate new offsets for the comments.

Then you "just" need a nice gui for viewing that data and editing the file, delta and comment data.

Yes, I think you're right, but the devil lies in that "just". ;-)

After reviewing Adam's comments in TidBits #842, and reviewing the RFP, here are some additional thoughts. My perspective is influenced by years of publication production work, familiarity with a few high-end editorial systems for newspapers, a lack of knowledge of the software products like SubEthaEdit, some programming experience and website development experience. Let's say the features below are what I would like to see.

If I were going to attempt this project - and I assure you I am not - I would consider using Userland Frontier as the server (but after considering its long-term availability and future development. It has a lot of smart features built in or accessible. Mostly it would just serve and maintain serial versions and data on them such as the production stage, owner, writer, permissons, etc. But it would be a multifunctional server: besides serving story text, it would also serve info on, for example, all stories "owned" by an editor, a writer, etc; the production stage of each; the publication/date each story is intended; and so on. It's the latter capability that will make it a good editorial system.

I now think that stories need to be handled as tagged text with several types of tags. One set of tags would be for paragraph and in-line formatting, and would need to be rich enough to convert well into various user specified formats. The second set of tags would control the text coloring of edits and comments by various people. But I would be wary of trying to be able to see numerous stages of changes all in one version; rather it should be made easy for a user to call up previous versions for reference. Some metadata at the top would define the version, and other potentially useful control information. A possble third set of tags, possbly built into the first, might identify indivdual paragraphs (understand that a headline, subhead, bylines and other user definable styles are paragraphs); this might allow for better management of changes.

UTF-8 and Unicode probably should both be supported, or at least the latter.

The editor would probably need to be built from the ground up. I would like it to display a) styled text, as it is easier to read. That's not to say it should be the final format, just some format that the user can define for their own preferred writing/editing convenience. b) Single and multiple display panels in a single window, where one would always display the current version, and a second could display either a copy of the current version where the reader can scroll up and down to check for consistency between a current paragraph and other parts of the story. Alternatively, the second panel could display a previous version, _or_ extra windows could be opened to display these earlier versions. c) a switch for displaying in narrow or standard column views - I like the narrow for editing and proofreading.

Version control and offline edits. In professional publications I have always worked with fairly strict version/production stage controls. You have to understand that it is during edits and rewrites that a lot of errors get introduced in the copy. Essentially I see all version changes to be offline, but the editor might have a save button that would save to the active version on the server if it is available (ie. the user is internet connected that moment). A version called up from the server (as opposed to some copy on disk), would set a "lock" on the server, so that if say the writer has called the last version for rewriting, a lock is set, and the editor can see right away if the version is out for rewrite. The locks should be something the editor can override when necessary. On the user side, the version he or she has subscribed to such that they own the version is locked for their own use; when they are finished the press a Save and Submit button that releases the lock, and to do further changes they need to resubscribe, which starts a new version.

The pesky part will be the necessary situation where the writer really is offline and cannot access the server to subscribe to a version. Assuming they have the most recent version on disk, they can open it and work on it, but when the eventually submit it, it gets saved as a new version. Occasionally, another person may work on the story at the same time. So the server has to recognize that two current versions exist and communicate it. Here's a case where paragraph labeling could be handy: the editor could call up both versions (note the two display panels above) and step through the two probably doing some cut and paste; or they might choose to join the two, where paragraphs are displayed together, the version x displayed with a version x tag displayed, followed by the version y paragraph with it's tag displayed. I should also mention that the editor should have the ability to roll back to a previous version and make it the current one.

Having built-in chat and internal and external email and other notification cabilities would be a great enhancement. While there may be a set workflow, the editor ultimately controls to whom a version gets directed when he/she submits it (back to writer, to editor, to production); and the reciever should get notification of that the story is in their queue. (others would be locked out presumably.

Live spell checking and regular expression search/replace capabilities as suggested previously by others would be highly desirable as well.

I see all these features as quite capable on the server side using something like Frontier. Doing a good editor would require some real skills. I'll skip any details beyond those mentioned already of the version management features, except to say they should provide a high level of control, communications between a story's team members, and access control to writers or others. I hope these thoughts are helpful.

Excellent comments, John, thanks!

>storing different projects and archiving of completed articles
Suggest change to:
storing different projects and archiving completed articles

>the showing of different text colors for different authors,
Suggest change to:
showing different text colors for different authors,

Regarding the color problem, how about a fixed color for each person, followed by a number to indicate which session by that person (or alternatively which "pass" -- by anyone -- through the document)?

It would be instructive to hear how well you (and others) think QuickTopic does this.

Columns, to see different versions of the same part of the text or to show comments or related links/references, and the ability to see 2 different parts of the same document simultaneously, are very useful tools to boost writing productivity.

Check in/out management sounds like a solid first step, while the reconciliation rules get hammered out.

By all means, include outlining features - the sooner the better!

QuickTopic is quite good at collecting and displaying a group's comments on an bit of text; the only problem is that it's a bit of a pain to set up for more than occasional documents. Ideally a program like GroupEdit would build in such functionality so it would be highly fluid.

RE: darcs -- there are easily available pre-compiled versions for Mac OS X. Don't get bogged down in implementation details too early.

Wassup? Where did the project go, is it stalled, being worked on furiously in secret?

I'm too busy until some time in 2007 to do other than indulge myself with an occasional peek but there's a lot of synergy between this project and other stuff I've been working on and thinking about with regards to storing and choosing variants of bits of a rich document.

Some thoughts so far:
1) I think settling on a version-control system as a backend is a huge rathole down which the entire project will disappear. The semantics of file-oriented revision control are not what you're discussing. In particular, you want more incoherent merging, picking bits out of a set of changes.

2) I am playing with a tablet (I know, we're all still waiting for iTablet). These things are made for editing!

Of late, not much has happened. I've been working on a spec and use cases, but have been bogged down by other projects for a while. I hope to get back to it soon.

Further to the angle of revision-control and undo being tightly integrated, there's some interesting stuff happening in "e for Windows" which started partly as a way to get a TextMate-compatible editor on Windows. It's wxWidgets-based so theoretically cross-platform although the author has said he won't do a Mac version out of respect for the TextMate author.

http://e-texteditor.com/blog/2006/making-undo-usable

I don't think his user interface is actually suitable for your goals but may help with the use cases.

Another interesting, albeit old, paper is http://www.ifi.uib.no/konf/nwper98/papers/persson.ps
on combining revision control with editing.

I suspect there is a lot of similarity between the chunking of textual lines of code into classes and methods and the natural chunking into paragraphs and tables of your editing environment.

In both cases, whilst merging, splitting and reordering of chunks may take place, edits within them are usefully treated as bounded by the chunk. Hence, discussions of programming-oriented editors for OO languages become relevant ;-)