Re: lexbind ready for merge

Re: lexbind ready for merge

[Tassilo Horn]

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

Re: lexbind ready for merge

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Why on earth does Gnus need to call byte-compile-from-buffer?

It seems to be code dealing with something on XEmacs introduced in
2007.  I've now disabled the code when running under Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: lexbind ready for merge

[Stephen J. Turnbull]

Tassilo Horn writes:

 > >> 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...

(defun byte-compile-from-buffer (byte-compile-inbuffer filename &optional eval)
  ;; buffer --> output-buffer, or buffer --> eval form, return nil

I don't know why FILENAME is not optional in XEmacs; it can be nil.
It can be used in non-trivial ways in that function.  Among others, it
is used in an error message, which would be confusing if the value
were nil.  For that reason, I personally would tend to oppose changing
the signature, to remind callers that null FILENAME is not without
drawbacks.

It's not clear to me what the semantics of the other uses of FILENAME
are, but since it's explicitly tested as a boolean at least once,
XEmacs is apparently prepared for it to be nil.

 > > Why on earth does Gnus need to call byte-compile-from-buffer?

"The Gnus that is the true Gnus calls byte-compiler-from-buffer.
Otherwise it would not be Gnus."

                                    -- larsi-tse, "Gnus Te Ching"

<wink />