Re: Adding 'compat' from ELPA as an optional dependency to ERC
"J.P." <[email protected]>
| Newsgroups | gmane.emacs.erc.general,gmane.emacs.devel |
|---|---|
| Message-ID | <[email protected]> |
Philip Kaludercic <[email protected]> writes: > "J.P." <[email protected]> writes: > >> Although, I believe doing so would also >> define compat- prefixed variants in all versions of Emacs, the idea >> being to save third-party packages from having to do stuff like >> >> (defmacro erc-compat--json-parse-string (string &rest args) >> `(,(if (fboundp 'compat-json-parse-string) >> 'compat-json-parse-string >> 'json-parse-string) >> ,string >> ,@args)) > > If a function like this were to be definied upstream > > (defun get-compatibility-func (name) > "Return the function NAME of a compatibility alias." > (let* ((compat (intern-soft (format "compat-%s" name)))) > (or (symbol-function (if (fboundp name) name compat)) > (error "No definition for %S could be found" name)))) > > then all that ERC would have to do is > > (defalias 'erc-json-parse-string > (get-compatibility-func 'json-parse-string)) > Nice. That looks really handy. (BTW, wouldn't a real life `get-compatibility-func' need some extra pizzazz to favor the prefixed form for certain versions? Because, as shown, something like (erc-jason-parse-string "42") would still signal a `json-parse-error' on Emacs 27, no?) >> But in ERC's case, there'd be no avoiding this kind of indirection. >> (Please correct me if that's a flawed understanding.) > > While prefixing is used, no, because we cannot assume that compat is > installed. Right. Makes sense. So, getting back to the main thrust of this thread, I guess I'll go ahead and add the proposed changes to Emacs 29, barring any last-minute objections. Thanks.