* Re: lexbind ready for merge [not found] ` <jwvlizwadhu.fsf-monnier+emacs@gnu.org> @ 2011-03-30 14:54 ` Tassilo Horn 2011-03-31 1:02 ` Stephen J. Turnbull 2011-03-30 16:11 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 3+ messages in thread From: Tassilo Horn @ 2011-03-30 14:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: ding, emacs-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: lexbind ready for merge 2011-03-30 14:54 ` lexbind ready for merge Tassilo Horn @ 2011-03-31 1:02 ` Stephen J. Turnbull 0 siblings, 0 replies; 3+ messages in thread From: Stephen J. Turnbull @ 2011-03-31 1:02 UTC (permalink / raw) To: Tassilo Horn; +Cc: Stefan Monnier, ding, emacs-devel 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 /> ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: lexbind ready for merge [not found] ` <jwvlizwadhu.fsf-monnier+emacs@gnu.org> 2011-03-30 14:54 ` lexbind ready for merge Tassilo Horn @ 2011-03-30 16:11 ` Lars Magne Ingebrigtsen 1 sibling, 0 replies; 3+ messages in thread From: Lars Magne Ingebrigtsen @ 2011-03-30 16:11 UTC (permalink / raw) To: emacs-devel; +Cc: ding 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-03-31 1:02 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <jwvbp0t61xm.fsf-monnier+emacs@gnu.org> [not found] ` <877hbhxe12.fsf@member.fsf.org> [not found] ` <jwvlizwadhu.fsf-monnier+emacs@gnu.org> 2011-03-30 14:54 ` lexbind ready for merge Tassilo Horn 2011-03-31 1:02 ` Stephen J. Turnbull 2011-03-30 16:11 ` Lars Magne Ingebrigtsen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).