Re: lexbind ready for merge

[Tassilo Horn <tassilo@member.fsf.org>]

Stefan Monnier <monnier@iro.umontreal.ca> 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