bug#7319: `defsetf' methods of `extent-*' in emacs-lisp/cl-macs.el

bug#7319: `defsetf' methods of `extent-*' in emacs-lisp/cl-macs.el

[MON KEY]

Current through bzr-102222

emacs-lisp/cl-macs.el has `defsetf' methods for:

 `extent-data', `extent-face', `extent-priority',
 `extent-end-position', `extent-start-position'

AFAICT GNU Emacs deosn't define the corresponding operators:

 `set-extent-data', `set-extent-face',
 `set-extent-priority', `set-extent-endpoints'

GNU Emacs doesn't even support the majority of cl*.el functions at
runtime (let alone setf methods for many core procedures) so why does
it make an attempt tos upport CL related functions for an alien
application's incompatible lisp featureset?

emacs -Q

(defun bubba (x)
  (eval-when-compile (require 'cl))
  x)

M-x compile-defun

(symbol-plist 'extent-data)
(symbol-plist 'extent-face)
(symbol-plist 'extent-priority)
(symbol-plist 'extent-end-position)
(symbol-plist 'extent-start-position)

Is this another example of CL polluting the "global names"?
:P

--
/s_P\

bug#7319: `defsetf' methods of `extent-*' in emacs-lisp/cl-macs.el

[Stefan Monnier]

> emacs-lisp/cl-macs.el has `defsetf' methods for:

>  `extent-data', `extent-face', `extent-priority',
>  `extent-end-position', `extent-start-position'

Funny, eh?
It's most likely the result of CL supporting both Emacs and XEmacs.
Of course, nowadays the Emacs and XEmacs versions aren't kept in sync
any more, so we could get rid of it, although they don't cause any
harm, AFAICT.


        Stefan