Making thingatp.el official instead of thing.el [Re: Please Vote on Proposals]
[Io moved to =beta]
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
We have several options.
a) Implement the "thingapt" API in terms of `thing.el' so that
programs just work. This would be in the spirit of fsf-compat.
(Although the analogy doesn't fully hold water. It's listed just
for completeness.)
b) Proclaim `thing.el' obsolete and replace it with `thingapt.el'.
This has the problem of losing backward compatibility in a way that
would set Kyle on your shoulders, clawing at your spine.
c) Proclaim `thing.el' obsolete and `thingapt.el' its follower.
Provide clear instructions on how to change all programs, and keep
`thing.el' in a "compatibility" package (not `fsf-compat', but
`old-compat'.) This is an option only if FSF's `thingapt.el'
really is better than `thing.el'.
d) The same as c), but implement `thing.el' API in terms of
`thingapt.el' for compatibility.
Which one do you think should apply?
Well currently the only thing in our package tree that uses thing.el
is mode-motion+.el (this even uses some internals, there are some ugly
tricks to reduce cons'ing). So we could rewrite that and do d).
However we could also simply consider thing.el part of mode-motion and
be done with it. I don't think browse-url is that much better than
thing.el and/or vice versa. browse-url's only claim to fame is URL
support.
Most packages seem to use their own at-point stuff. I thing browse-url
using thing-at-point is a new trend.
I think the lazy option would be
e) let the two coexist. Maybe stick a comment in thing.el that it is
depreciated.
I don't think it is even worth it doing a)
Jan