From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id ICcCIIwuJmBoYgAA0tVLHw (envelope-from ) for ; Fri, 12 Feb 2021 07:30:20 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id aTfRG4wuJmBHKAAA1q6Kng (envelope-from ) for ; Fri, 12 Feb 2021 07:30:20 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 7D8869402B3 for ; Fri, 12 Feb 2021 07:30:19 +0000 (UTC) Received: from localhost ([::1]:40126 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lASu9-0002u3-DR for larch@yhetil.org; Fri, 12 Feb 2021 02:30:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lASss-0002tW-Ps for emacs-orgmode@gnu.org; Fri, 12 Feb 2021 02:28:58 -0500 Received: from mout-p-103.mailbox.org ([2001:67c:2050::465:103]:12360) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1lASsq-00051w-3s for emacs-orgmode@gnu.org; Fri, 12 Feb 2021 02:28:58 -0500 Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4DcQ8y2Cb7zQlJn for ; Fri, 12 Feb 2021 08:28:50 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=guelker.eu; s=MBO0001; t=1613114928; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1r+ujVoCPXqFangBEzwboqCnvLITZ8PHRF4hyolciyo=; b=BBJ6Fc0Nrahg6KhnF6VBE568uyoOE5zjko59s8/OzEcR3Lr4CCqKMWu8J6tGVYphWKTtEy PPhvc6SpeH+iFGz3XvZpEx/4+mzjU8re6D+bIQJiEI5N/9Gyygm0BGwHhzHmQo0BoI+TxZ KZ7oNzHDCOhDvQHqDmACmxsbCLbnlHawIyDTHhiYY1X2GhxDTSmJ/KBQ/9FxBKdHWRwebq 7j86lF93MdIjzK+P1OmlhdIrmDKq/bb5qmfraWAaT4E+InZ9ZM6P7i97ADjFjSnIdKTX6I kxJq3IgrLYOi0WKkbE1VttMoLUFsauBJLb+xr1LKRncRRZ+7p9mOxMy7rtQSIA== Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter02.heinlein-hosting.de (spamfilter02.heinlein-hosting.de [80.241.56.116]) (amavisd-new, port 10030) with ESMTP id WIsLkIkoTqLo for ; Fri, 12 Feb 2021 08:28:43 +0100 (CET) Date: Fri, 12 Feb 2021 08:28:41 +0100 From: =?utf-8?B?TS4g4oCYcXVpbnR1c+KAmSBHw7xsa2Vy?= To: emacs-orgmode@gnu.org Subject: Re: local variables and export processing in hooks Message-ID: <20210212072841.GA3346@atlantis> Mail-Followup-To: emacs-orgmode@gnu.org References: <87sg65tuqa.fsf@ucl.ac.uk> <20210209113052.GF21978@tuxteam.de> <87a6sdtphg.fsf@ucl.ac.uk> <5917189e-3c8d-0854-561d-3af02a3868b4@posteo.eu> <20210210205610.GC6355@atlantis> <81579f62-41a3-552c-7f2e-1885e591d1d5@posteo.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <81579f62-41a3-552c-7f2e-1885e591d1d5@posteo.eu> X-MBO-SPAM-Probability: X-Rspamd-Score: -6.54 / 15.00 / 15.00 X-Rspamd-Queue-Id: 0C529187C X-Rspamd-UID: e5dd51 Received-SPF: pass client-ip=2001:67c:2050::465:103; envelope-from=post+orgmodeml@guelker.eu; helo=mout-p-103.mailbox.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.06 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=guelker.eu header.s=MBO0001 header.b=BBJ6Fc0N; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: 7D8869402B3 X-Spam-Score: -2.06 X-Migadu-Scanner: scn1.migadu.com X-TUID: DsNJT/rMW/E8 Am 11. Februar 2021 um 21:12 Uhr +0100 schrieb Sébastien Miquel: > The purpose of #+BIND is to set some variables in the copied buffer. > > Also, these variables are set after macro expansion (and > org-export-before-parsing-hook). Thanks for the information. If they are set after macro expansion, it will not help me (see below). > > I'm curious, could you explain why/how you use macros to set variables in > the original buffer ? The how is easy enough. First I, define an automatically buffer-local variable with (defvar-local the-buffer-local-variable nil) In the org-before-processing-hook and in the macro expansion function then I effectively do this: (with-current-buffer (car (buffer-list)) (setq the-buffer-local-variable "thevalue")) I agree that the heuristic on (buffer-list) may not be ideal, but for the cases I had so far it works just fine and retrieves the original .org buffer from which the system is currently exporting. As for the why: I am working on a personal citation system for my specific needs called zit.el (I am a German jurist, and we have quite peculiar habits on citation, of which excessive use of footnotes and not using LaTeX, instead having to submit in DOCX format are only some). I use this functionality to implement a footnote crossreference system. That is, the first time a citation appears it should appear in the footnote as: /Doe/, Some Awesome Work, 3rd edition 2014, pp. 44 ff. Then the next time this source is cited it should appear as: /Doe/ (Fn. 35), pp. 46. If it was not clear from the above: my custom citation system relies on org's macro system. In the org source I have something like this: [fn:35] {{{zit(doe2014awesomework[44 ff.])}}}. [fn:36] {{{zit(doe2014awesomework[46])}}}. The `zit' macro is my custom macro which operates on a buffer-local variable. If a citation is new, it adds an org target with a unique name (<>) to the macro expansion value and records it in said variable. If the citation is not new, it retrieves the target value from the variable and expands to a link to the target instead; org is smart enough to resolve links to targets in footnotes to the footnote number, which I make use of here. All this only works because it is possible to implement a macro in an elisp function by using #+MACRO with an `eval' statement. This certainly is a cool functionality I am quite grateful for. Now that I think about it: actually a normal variable would suffice. I used a buffer-local one a) because my custom citation system has some per-document settings, like the "Fn." in the parantheses above being a customisable string, which are naturally implemented as file-local/buffer-local variables and b) because one might have multiple org documents open at the same time. But because the citation collection variable is transient anyway (in fact, it is reset to nil in the org-before-processing hook so that on a subsequent run it starts from a clean sheet) and one can only export one document simultaneously at a time, a normal variable would be enough. I will probably change that. If #+BIND statements are not available in macros, they will not work for my per-document settings as described before, so I will leave them as file-local/buffer-local variables as they are currently. I needed to read up on how to mark my own variables as "safe" for that purpose, but I have now found out how to do that. Thanks for your answer! -quintus -- Dipl.-Jur. M. Gülker | https://mg.guelker.eu | For security: Passau, Germany | kontakt@guelker.eu | () Avoid HTML e-mail European Union | PGP: see homepage | /\ http://asciiribbon.org