gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?


From: Parker, Ron
Subject: RE: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?
Date: Wed, 24 Dec 2003 15:50:34 -0600

> From: Andrew Suffield [mailto:address@hidden

> On Tue, Dec 23, 2003 at 02:35:27PM -0800, Tupshin Harper wrote:
> > Andrew Suffield wrote:
> > >On Tue, Dec 23, 2003 at 04:31:05PM +0100, address@hidden wrote:
> > > 
> > >
> > >>The special case of XML-diff/patch could be solved e. g. with an 
> > >>XSLT-based
> > >>mechanism for useful merges...
> > >>   
> > >>
> > >
> > >This says "this problem could be solved by implementing something that
> > >solves it", with XSLT thrown in as a red herring.
> > > 
> > >
> > But since xslt is turing complete, it addresses all the problems we've 
> > been talking about. ;-)
> 
> So does INTERCAL.

ROFL. Since starting to read through this thread earlier today, I have been
resisting bringing up the subject of INTERCAL in the context of a
diff/patch/merge tool that "does the right thing"-(TM).

I think one fundamental issue that many have missed in the course of this
discussion is that when you are patching with fuzziness or merging C-code
and the process results in something unexpected and possibly broken, it is
still in the expected form, source code.  To quote from the GPL:

        "The source code for a work means the preferred form of the work for
making modifications to it."

In this case the user should be relatively competent to look at least
understand what has happened.  This is not to say that they know which half
of a conflict is correct, or what the proper compromise is in a given
situation, but at least they aren't seeing the C-code conflict expressed in
INTERCAL.

Now, if the process of patching an OOo document (or anything else) results
in breakage in a "non-preferred" form, then the user loses, or the luser
uses (after too much egg nog).

My point, as many have alluded to, is that the OOo end user is used to
dealing with a word-processing document, spreadsheet or whatever.  What they
see in OOo, AbiWord, etc. is their "preferred form" and while they may be an
expert office worker, one may be relatively certain that they are not a
tar-gzip-XML expert and even if they are for the task at hand, XML is not
the preferred form.  Going back to my previous comment, would you want to
see your C conflicts in INTERCAL?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]