[Q] Import Edward O'Connor's json.el.

[Stephen J. Turnbull]

Damn, I don't know how I missed this.  It's in my (now 200 posts long,
which I've finally found time to weed out) xemacs-todo folder, but not
in any of my list-specific folders :-(

You have my apologies; you did respond to my QUERY.  Still, you should
have waited for a retraction before committing (ie, pinging me because
I seemed to be ignoring you).

Having looked more carefully, my veto stands; you will need to collect
votes to override it (though that is probably easier than I thought).

Aidan Kehoe writes:
 > 
 >  Ar an triú lá déag de mí na Nollaig, scríobh Stephen J. Turnbull: 

 >  > This doesn't belong in net-utils.  Nor does xml.el, for that matter.
 >  > We'll have to think about the implications of moving xml.el, but let's
 >  > not follow that precedent here.
 >  > 
 >  > The existing package that fits best is prog-modes, 

 > It doesn't fit in prog-modes at all. JSON is a data format, like ASN.1,
 > S-expressions, and XML.

I don't entirely agree with classing JSON, ASN.1, s-exprs, and XML
together in that way, but you're right, it doesn't fit into
prog-modes.

 > This is not a mode. This is a library for Lisp programming.

OK, having looked more closely, I agree with that.  For that very
reason, it doesn't belong in net-utils.  net-utils is mostly user
interactive utilities.  Other *-utils such as edit-utils and os-utils
are mostly interactive user stuff or user configuration utilities,
too.

 > There doesn't appear to be. The intersection of Emacs Lisp coders with
 > Web-2.0 enthusiasts is a lonely place. 

That doesn't surprise me, at this stage; elispers are a pretty
conservative bunch in some ways.

But looking at what the libraries do rather than focusing on marketing
buzzwords, dns.el is an example of the same kind of LISP library used
for marshalling a wire format.  feedmail.el, maybe, but it really
belongs in mail-lib.  net-utils.el itself, although I wonder if
anybody uses it for anything but its interactive diagnostic utilities.
Maybe xml.el fits this paradigm, but it only goes half way (it's only
a parser).

 >  > they should be collected in one, reasonably well-named place.

I see no reason to change my opinion about this, even though it's
much-better-informed now (to the point of changing what "they"
includes).