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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: MON KEY <monkey <at> sandpframing.com>
Subject: bug#7319: closed (Re: bug#7319: `defsetf' methods of `extent-*'
 in emacs-lisp/cl-macs.el)
Date: Mon, 08 Nov 2010 19:15:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 7319 <at> debbugs.gnu.org.

-- 
7319: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7319
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: MON KEY <monkey <at> sandpframing.com>
Subject: Re: bug#7319: `defsetf' methods of `extent-*' in emacs-lisp/cl-macs.el
Date: Mon, 08 Nov 2010 14:09:45 -0500

> 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

[Message part 3 (message/rfc822, inline)]

From: MON KEY <monkey <at> sandpframing.com>
To: bug-gnu-emacs <at> gnu.org
Subject: `defsetf' methods of `extent-*' in emacs-lisp/cl-macs.el
Date: Tue, 2 Nov 2010 16:38:05 -0400

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\

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.