backporting changes to exported results for collaborative editing

backporting changes to exported results for collaborative editing

[Samuel Wales]

suppose you export a subtree to ascii or html, and then a bunch of
people want to help you edit it.  obviously you want the changes back
in org.

obviously the best would be if you could give them the source,
complete with comments.  but assume that they are not computer people,
and not org people, and you don't want to give them your irrelevant
comments.

also assume you also don't want to give them your irrelevant tasks and
you do not use org-export-with-tasks.

it might be that i already know the answer: just do the best you can
with diff, and request small sets of changes at a time, or request
manual instructions for changes.  but perhaps you have ideas?

-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it -- at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." --- very true words by Johanna Kaiser spoken to US NIH in
conference call with Walter Koroshetz, NINDS director
<http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>

Denmark: free Karina Hansen NOW.
  UPDATE 2016-10: home, but not fully free

Re: backporting changes to exported results for collaborative editing

[Marcin Borkowski]

On 2017-02-07, at 02:15, Samuel Wales <samologist@gmail.com> wrote:

> suppose you export a subtree to ascii or html, and then a bunch of
> people want to help you edit it.  obviously you want the changes back
> in org.
>
> obviously the best would be if you could give them the source,
> complete with comments.  but assume that they are not computer people,
> and not org people, and you don't want to give them your irrelevant
> comments.
>
> also assume you also don't want to give them your irrelevant tasks and
> you do not use org-export-with-tasks.
>
> it might be that i already know the answer: just do the best you can
> with diff, and request small sets of changes at a time, or request
> manual instructions for changes.  but perhaps you have ideas?

Maybe this could be automated a bit?  Like, org -> markdown, then
people's edits, then diff generating a patch, then some tool existing
only in my dreams currently that converts the md patch to an org patch,
and then apply that patch to the original org?  For small enough
changes, that could actually work, no?

Best,

--
Marcin Borkowski

Re: backporting changes to exported results for collaborative editing

[Charles C. Berry]

On Tue, 7 Feb 2017, Marcin Borkowski wrote:

>
> On 2017-02-07, at 02:15, Samuel Wales <samologist@gmail.com> wrote:
>
>> suppose you export a subtree to ascii or html, and then a bunch of
>> people want to help you edit it.  obviously you want the changes back
>> in org.
>>
>> obviously the best would be if you could give them the source,
>> complete with comments.  but assume that they are not computer people,
>> and not org people, and you don't want to give them your irrelevant
>> comments.
>>
>> also assume you also don't want to give them your irrelevant tasks and
>> you do not use org-export-with-tasks.
>>
>> it might be that i already know the answer: just do the best you can
>> with diff, and request small sets of changes at a time, or request
>> manual instructions for changes.  but perhaps you have ideas?
>
> Maybe this could be automated a bit?  Like, org -> markdown, then
> people's edits, then diff generating a patch, then some tool existing
> only in my dreams currently that converts the md patch to an org patch,
> and then apply that patch to the original org?  For small enough
> changes, that could actually work, no?
>

Maybe, but this sequence might be easier:

- export subtree to md =edit-me.md= (body-only not needed but cleaner)

- distribute to editor and retrieve as =editted.md=

- in a shell run ~pandoc -o editted.org editted.md~

- M-x ediff-regions RET
   - select all of =editted.org=
   - select original subtree
   - Use `##' to skip the whitespace only diffs.
   - resolve the differences as appropriate and/or save the diffs.


Babel blocks/results are *not* be handled seamlessly, so more would
need to be done if your editor wants to revise them. Otherwise, just
skip them.

I guess this might work with ascii or html, but I've not tried it.


Chuck