From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Sun, 24 Dec 2023 18:13:39 +0000 Message-ID: <878r5j31v0.fsf@localhost> References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> <875y0n4px0.fsf@localhost> <87r0jb34hi.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38253"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "T.V Raman" , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 24 19:10:56 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rHSwB-0009jX-Gr for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 19:10:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHSvn-0007yG-95; Sun, 24 Dec 2023 13:10:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHSvm-0007xt-07 for emacs-devel@gnu.org; Sun, 24 Dec 2023 13:10:30 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHSvk-0006lF-5T for emacs-devel@gnu.org; Sun, 24 Dec 2023 13:10:29 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D4CCC240103 for ; Sun, 24 Dec 2023 19:10:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703441426; bh=YL6se1n1VWZzr6NDK3R3cU5NRzIAO3cxspYKqhIjHbc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=PHZlozAwJcicBuRIHRyF6EQ9Alc52Do/GTyWhlz8L9ILvOudo4/5n6hStFKPo5unF 7xLhzD4hubxqg+CXWV1NZ/C3VXksj/vviRjc6iU3TE8+2b1t2ICf34tqM12dcWr8yF wXkdoHX25WUXilRrTpglUcZiH4s9SHp0NyZqhnbWTOQ9nIxeTrZDF+cdYhJLmSRiBg CP6GGOeZ00JCbdb6ZKKDKjqW0+wXLLo99CBCgwAOuswjQhFjpKhQZySiy5286MheVq 9EySZnF7ajdbOUtrNETgbEeMGK4M4qBMYBP4tFl3ybVOzGzDoIfevJv+azXvTHY3FJ elpLQ5PQBfs3g== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Sypwy2y6hz9rxF; Sun, 24 Dec 2023 19:10:26 +0100 (CET) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314164 Archived-At: Jo=C3=A3o T=C3=A1vora writes: >> It is not about a specific macro. Any macro may be broken this way. > > No, that's that not true. Only macros defined in one file and > expanded in other files. And not if you use this technique. You are indeed right.=20 >> > [ Tangent: one thing I notice is that the expansion in ox-html.el is >> > buggy. It evaluates the keyword arguments to the macros multiple times >> > for no effect. The solution would be to change the macro calling >> > convention to be: >> > >> > (cl-defmacro org-export-with-buffer-copy ((&key to-buffer drop-visibil= ity >> > drop-narrowing drop-contents >> > drop-locals >> > &allow-other-keys) &body bod= y) >> > ...) >> >> May you elaborate? > > Just expand the macro as in ox-html.el and see for yourself. Hmm... It actually looks like a problem with `cl-defmacro' rather than with macro definition itself. >> > `(org-export--call-with-buffer-copy (lambda () ,@body) >> >> AFAIU, this technique will prevent compiler optimizations, won't it? > > What compiler optimizations are you talking about? The only > price to pay is an extra funcall. "We can solve any problem by > introducing an extra level of indirection." The function compiled, > where presumably the complicated optimization-worthy logic lies > is still compiled. Any use of (funcall 'symbol ...) means that compiler is not able to know the function slot of 'symbol at compile time, because it may change. Hence, any optimization that relies upon knowing both the context of the funcall and the internals of 'symbol will become impossible. And this will not solve the problem when Org files are loaded in mixture from Emacs built-in version and from some other version (ELPA, manually installed Org mode, etc). --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at