Ar an chéad lá de mí Eanair, scríobh Stephen J. Turnbull:
Damn, I don't know how I missed this. It's in my (now 200
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).
Heh, I thought it was a good sign--no energetic criticism means you agree,
Having looked more carefully, my veto stands; you will need to
votes to override it (though that is probably easier than I thought).
Not something I’m super-optimistic about--that would involve at least two
other active reviewers taking an interest in the thing.
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
> > 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
For the sake of my understanding your thinking, why don’t you agree with
classing the four together in that way? If I’m going to pass data structures
between programs, I’m going to use one of the four, when not Berkeley DB or
a relational DB.
> 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,
Except that at least two existing files in net-utils are libraries for Lisp
programming, and there’s no such separation enforced in the rest of the
Honestly, reorganising the packages tree to group net-oriented Lisp
libraries together is a worthy thing to do, but it’s a distinct, separate
task from importing json.el. Pressuring me to do it by means of your veto
will work, and my sense of perspective means I’m not about to hold a grudge
on it, but in a general sense it is the wrong way to go about this. The
right way would be to take the half-hour to do it yourself after the commit;
adding json.el to net-utils now doesn’t conflict with that.
Your argument about shadowing doesn’t hold as an objection, since it applies
equally to xml.el, which is already in the tree in an undesirable place, and
would be moved if we were to implement a net-lib package. (And ‘net-lib’ as
a name, parallel to ‘mail-lib’ is one real option.)
When I was in the scouts, the leader told me to pitch a tent. I couldn't
find any pitch, so I used creosote.
XEmacs-Patches mailing list