[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lexbind ready for merge
From: |
Tassilo Horn |
Subject: |
Re: lexbind ready for merge |
Date: |
Wed, 30 Mar 2011 16:54:09 +0200 |
User-agent: |
Gnus/5.110016 (No Gnus v0.16) Emacs/24.0.9999 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>> The reason is that in trunk, that function has the signature
>> byte-compile-from-buffer (bytecomp-inbuffer &optional bytecomp-filename)
>> but in the lexbind branch, the optional bytecomp-filename has been
>> removed:
>
>> byte-compile-from-buffer (inbuffer)
>
>> AFAIKS, gnus doesn't use the foo.el file anyway, so basically that arg
>> can be removed. But maybe the `byte-compile-from-buffer' definition in
>> [[S]X]Emacs requires exactly 2 arguments? I don't know...
>
> Why on earth does Gnus need to call byte-compile-from-buffer?
The purpose of the whole dgnushack.el is to figure out the correct
load-path when byte-compiling. But I'm the wrong person to ask why that
messy dance has to be danced... I added the Gnus list to the Cc.
The function definition is
(defun dgnushack-emacs-compile-defcustom-p ()
"Return non-nil if Emacs byte compiles `defcustom' forms.
Those Emacsen will warn against undefined variables and functions used
in `defcustom' forms."
(let ((outbuf (with-temp-buffer
(insert "(defcustom foo (1+ (random)) \"\" :group 'emacs)\n")
(byte-compile-from-buffer (current-buffer) "foo.el"))))
(when outbuf
(prog1
(with-current-buffer outbuf
(goto-char (point-min))
(search-forward " 'foo '(byte-code " nil t))
(kill-buffer outbuf)))))
and its use is in dgnushack's form
(when (dgnushack-emacs-compile-defcustom-p)
(maybe-fbind '(defined-colors face-attribute))
(maybe-bind '(idna-program installation-directory)))
where maybe-[f]bind is declared in lpath.el, whose top level comment is
;; Shut up.
;-)
Bye,
Tassilo
Re: lexbind ready for merge, Tassilo Horn, 2011/03/30