Re: XML Layout in .abw files

On Fri, 2004-08-13 at 08:10, Dom Lachowicz wrote:
> My mom and the church secretary don't care about
> diffing files. It's a use case we haven't designed for
> nor cared about, and I'm not sure that we're going to
> start now.
>
> Come up with a proposal and file a bug if it bothers
> you enough.
>

Although, experimenting with the revisions features once I was slightly
impressed; it just worked, and was surprisingly intuitive to
accept/reject various portions and for automerge. It would be readily
conceivable to cross meldish (an eye-candy ridden graphical differ)
controls with Abi's existing revisions stuff if it was determined
desirable (ie, one or two fewer clicks when in a certain mode, or
something).
But this is for editing by humans within Abi.

> --- Charles Goodwin <charlie@vexi.org> wrote:
>
> >
> > "Vexi Reference.abw" 176L, 65382C
> > But the part where I've found this to be a big pain
> > is in diffs
> > between .abw documents. I'm currently writing a
> > large document [0] as
> > part of a team, and we will be using darcs [1] to
> > post patches and
> > updates. But this is really difficult when .abw's
> > are laid out as they
> > are. Patches are obscenely large, and can rarely be
> > independent of
> > eachother because the content is kept on so few
> > lines.

We do have a lot of superfluous attrprop info in followup lines, but the
fact remains that AbiWord and its file format, like dom said, aren't
meant for this. For human editing, it would be more appropriately left
up to the facilities within AbiWord. For something generated by darcs,
well, hopefully human-darcsdiff interaction can be kept to a minimum.

> >
> > Surely it would be more sensible to reverse the
> > lines:cols ratio by
> > being more astute with the layout of .abw XML? Is
> > there are particular
> > reason that it's like it currently is? I'm sure the
> > ability to diff
> > files is not the only way in which the
> > large-columnar approach causes
> > difficulties.
> >

Meh. I do a lot (well, relative to most users) of hand xml editing of
.abw when working on test cases for QA, and I wouldn't necessarily think
it worthwhile of a major format rearchitecture preceeding whenever we
switch to the jar on the horizon. I really got used to it pretty quick,
I even have a tendency to switch back and forth btwn wrap modes (in, for
example, gedit) for the most efficient reading of corrupt xml (-8

Like any change, switching a large refdoc project like that to a
wysiwyg-intended format has its pluses and minuses. You've told us the
pluses, here's the big minus (-:

Regards
-MG
Received on Fri Aug 13 17:36:44 2004