Re: [Gnu-arch-users] Re: Graphical merges

[Tom Lord]

    > From: Matthew Dempsky <address@hidden>

    > Tom Lord <address@hidden> writes:

    >> No, that's exactly what to avoid.  User interaction for merging
    >> should not occur within a single run of star-merge.

    > What's the rationale for that?  (It "makes sense" to me, but I'd
    > just like to have a better understanding of the big picture.)

Consider the class of interactive procedures which have multiple,
order-independent steps.  One example is if you want to rename the
identifer `foo' to `bar' in 10 files.  In some sense, that's a 10-step
procedure -- one step per file -- but it doesn't matter what
(temporal) order (or partial order) you do those steps in.  Another
example is interactively merging changes into 10 files.

User interfaces shouldn't arbitrarily impose an ordering on such
procedures.  Users should be able to skip around between steps, do
multiple steps simultaneously, set the work aside and resume it later,
etc.   For the user, that's the difference between sitting in front of
a workbench and sitting in front of an assembly line.

For the merging procedure, interaction from a subprocess of `tla
star-merge' would (without really excessive workarounds) impose an
order on which the merging steps are performed.  You couldn't skip
around or mix in entirely separate tasks so easily.   What would
happen, for example, if you exit a GUI merge-tool that tla is
`wait(2)'ing on before you meant to --- can you go back?   What if
when you see the third file in the list you think "I want to do this
one _last_"?

Regarding "(without really excessive workarounds)" -- well, in
principle you could build some kind of "agenda manager" into tla.
`star-merge' would first compute all the merge steps needed, then let
the user navigate through those tasks using the built-in agenda
manager.  

That would be a big win in one sense:  the agenda manager could keep
track of your progress.   Even if you skip around, it could tell you
"Oops... you still have 3 files left to do."

But it would be a lose in the sense that tla is the wrong place to
build that agenda manager functionality.   It's a pretty generic need
and would be better handled by a generic interaction manager (like
screen or emacs or an X window manager -- but with this added
agenda-management functionality).

-t