From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Satyaki Das Newsgroups: gmane.mail.mh-e.devel,gmane.emacs.devel Subject: Re: mh-e/mh-acros.el advices `require' incorrectly Date: Fri, 13 Jan 2006 15:36:51 -0800 Message-ID: References: <837.1137190309@olgas.newt.com> Reply-To: satyaki@theforce.stanford.edu NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1137195430 15208 80.91.229.2 (13 Jan 2006 23:37:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 13 Jan 2006 23:37:10 +0000 (UTC) Cc: Drew Adams Original-X-From: mh-e-devel-admin@lists.sourceforge.net Sat Jan 14 00:37:10 2006 Return-path: Envelope-to: gmmd-mh-e-devel@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ExYTf-0001Lr-Or for gmmd-mh-e-devel@m.gmane.org; Sat, 14 Jan 2006 00:37:04 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 68D4189382; Fri, 13 Jan 2006 15:37:02 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1ExYTZ-0002eP-Ic for mh-e-devel@lists.sourceforge.net; Fri, 13 Jan 2006 15:36:57 -0800 Original-Received: from xproxy.gmail.com ([66.249.82.195]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1ExYTX-0006cu-Az for mh-e-devel@lists.sourceforge.net; Fri, 13 Jan 2006 15:36:57 -0800 Original-Received: by xproxy.gmail.com with SMTP id s6so525424wxc for ; Fri, 13 Jan 2006 15:36:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZCz2wqQWghL843Q60lfhKE3E0uv3hUmzBjvp9L8Ko6qNo/QGadMTcJVvh3zwIjCSvGR6UQFDcjOA7Us01XUNd/woeC+//hQRZFohmnACXLzyVCc+qfdnuVgd4CN6MgyNLMaBrIYwM3Df0GNdRNz/eq83wOPtSxS3J5evC7vzZbk= Original-Received: by 10.70.34.20 with SMTP id h20mr4483762wxh; Fri, 13 Jan 2006 15:36:51 -0800 (PST) Original-Received: by 10.70.35.14 with HTTP; Fri, 13 Jan 2006 15:36:51 -0800 (PST) Original-To: emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net In-Reply-To: <837.1137190309@olgas.newt.com> Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 0.0 RCVD_BY_IP Received by mail server with no name Original-Sender: mh-e-devel-admin@lists.sourceforge.net Errors-To: mh-e-devel-admin@lists.sourceforge.net X-BeenThere: mh-e-devel@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Forum for the MH-E developers List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Fri, 13 Jan 2006 15:36:51 -0800 Xref: news.gmane.org gmane.mail.mh-e.devel:11269 gmane.emacs.devel:49041 Archived-At: On 1/13/06, Bill Wohler wrote: > Drew Adams wrote: > > > > The origianl `require' returns FEATURE even if it is already > > > provided, but the adviced `require' returns nil in such a > > > case. So, once mh-acros.el is loaded, a code depending on > > > the return value of `require' stops working. > > > > > > How about this change? > > > > What do you (and others) think about this? > > > > Besides the fact that we shouldn't use defadvice in vanilla Emacs code,= I > > don't think we should change the return value of `require' at all. It h= as > > acted this way for a very long time, and there is undoubtedly code that > > depends on this behavior (at least some external libraries). Besides, w= e > > certainly should not make such a change just before a release. > > Unless you load MH-E, require does not change. Even if you load MH-E, require isn't adviced since mh-acros.el is never loaded at run time unless you load it yourself. > I= f I understand > correctly, Kanichi's patch addresses your concern (about the return > value of require changing). Here's the ChangeLog for that change: Kenichi's patch won't cause any problems for MH-E. > > 2004-08-23 Satyaki Das > > * mh-acros.el (mh-require-cl): Remove unneeded autoloads. > (require): Add an advice to the function so that at compile time > the uncompiled file is loaded. This avoids compilation problems > when built in the Emacs tree. > > Satyaki, just out of curiosity, do you remember what the problems were? > Would we be able to remove the require defadvice if we removed the > circular dependencies? That advice forces the load of src .el file. Suppose you have three files a.el, b.el and c.el and the compiled files a.elc, b.elc and c.elc. Suppose that there is a macro foo in c.el that is used in a.el. Now let us make a change to macro foo. Then if we recompile all the files in the directory then they are compiled in the lexical order. So when a.el is getting compiled, require will load the c.elc and get the old definition of the macro. The advice above avoids this. A better solution would be to use Stefan's change in bytecomp.el. If it were checked in, we can drop the advice to require and it will make things nicer elsewhere too. Satyaki ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click