From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id gP+VCKkjK2OQhQEAbAwnHQ (envelope-from ) for ; Wed, 21 Sep 2022 16:46:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id qECRCKkjK2P6dQEA9RJhRA (envelope-from ) for ; Wed, 21 Sep 2022 16:46:01 +0200 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 B49663F3BE for ; Wed, 21 Sep 2022 16:46:00 +0200 (CEST) Received: from localhost ([::1]:33642 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ob0z9-0007Xe-RP for larch@yhetil.org; Wed, 21 Sep 2022 10:45:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob0x4-0007W8-BE for emacs-orgmode@gnu.org; Wed, 21 Sep 2022 10:43:50 -0400 Received: from mout02.posteo.de ([185.67.36.66]:37963) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ob0x2-00038X-5R for emacs-orgmode@gnu.org; Wed, 21 Sep 2022 10:43:50 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 19F2C240101 for ; Wed, 21 Sep 2022 16:43:45 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1663771426; bh=Zwru0hqCYW4Lif8eCkTenMG62LZMVXSmMYbTGib83gw=; h=From:To:Cc:Subject:Date:From; b=i1TzpX9UpoZq/gJ0sWrLTFZ7U2s23CtZIWUU/mlNnyFcVzBYC+4cw5zPVBFrU80g7 1z/76vc062FfQBRjqhMKfBdHoec9heEx6RrCq1iBFVgtusN89QzRp0+vEe96PlMx2L K9kARz5ERDbbaUxhN9tMBCbiUU+RILjB3MQzpBZKWgx1kMoyvTh2jVxRWcXy0JqF3M x0VFBN1y2UCxxFukT45xGrYKSuhT2uP5CvZ41NG2gADvONLVwgRI8ZUnBK4i1t2rf0 VXvNLf5Cwhd3TnycdHBozieOi5Z1OuSzj2nPbUprOLnvblQMWL1n87xx5JTgI6Nmff OuhVd6gScA+tg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MXh4J4XNWz6tnX; Wed, 21 Sep 2022 16:43:42 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: [Patch] Pre-/postpend arbitrary LaTeX code to a section References: <87o7vcsw8m.fsf@posteo.net> <87czbqyy5i.fsf@localhost> <87sfkmdkxa.fsf@posteo.net> <878rmdxg17.fsf@localhost> Date: Wed, 21 Sep 2022 14:43:40 +0000 In-Reply-To: <878rmdxg17.fsf@localhost> (Ihor Radchenko's message of "Wed, 21 Sep 2022 16:55:48 +0800") Message-ID: <878rmcvlcz.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.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_H2=-0.001, 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.29 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-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1663771560; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=x+mGUYeJy0DSei7uOTdH1ffvhQJgY5WL/NGubokmqvM=; b=i4wRqvEuRQQd6Pmf7IBETTcg/U9zNQazhRYBgd5/zfTMLsa5tNKaP4B3FrMGJwu0OvwxBd bs7MD6/XumQsOS32TI8sY0DUf5Tt1F4mG6SRaEHj+dLvIy6spRy/pSB1VGXEiqmlocGkVg nhlYXl+FMBlQhxyHhUA6TjpD8rSFL53kd0B3h592XMYhmjOCtqE73bFFDI1c8eyZhb7zJM B8DJazkrwyhIXDbZE0422tVMevt4RvXdYKhTfvcyUZFklqJ8K8aXNrZYpZl6S3tlQ5MVwC IONnx627B12tga2mD6pn/c2N+KKUqz+OGam9z7akN7VfVhHBqYecJnKWZA66og== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1663771560; a=rsa-sha256; cv=none; b=DL0z3eKW3He4oR2RynhUnCSFzvKRn+qIMgmqRErzKL3Urg4FO+rMAdVAWlg50B9FLfmSgK +l6vKFohsTUeC1iGJhIGHHfp4GQeEDwm5B27MLEfUkdKYUw7pMo9pMCaHUfhmgOFi3aZ0t zgi2nhfu86zxxF+qIHBfke6/wRgagzPk+8x7Ei+8IKetRmWo7+NtLwfatOZUz/+z+W9Ccj hK1UdB4YTIwvvHD/I8xb/j9YDkJ/zlQJMCzVC+hMu2VDVj9pwCBis8uuEsEnHvB1Y77XzF gEI0tOMKwGQY4fj8DGMFFssQCEl4eoZZ6jpmW1EIzQNqlxh0HLwbbZx5wkU8Wg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=i1TzpX9U; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -9.34 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=i1TzpX9U; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: B49663F3BE X-Spam-Score: -9.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: H/ljaGNpfDv/ Ihor Radchenko writes: > It may produce unexpected results if "Section" heading is demoted all > the way to paragraph. If Section heading is demoted all the way to paragraph, I assume that the expected will happen: that in the output to LaTeX a string will be added before \paragraph and another string after the content of \paragraph, which is perfectly consistent with the behavior of these two properties. It is not that I intend to insist on a discussion; I just don't quite understand what you mean. Note that these properties are for LaTeX fine-tuning, and the user is expected to know what he/she wants and where he/she wants it. If a user wants the arbitrary LaTeX code before a certain header to be exported as a section (because, for example, he/she has defined a command in LaTeX that changes the style of the next \section), you would expect to put those properties in a "\section" heading. > Also, :presec/:postsec property names are > confusing --- it is unclear if they are specific to LaTeX. (when about, > say, Beamer) Yes, I agree with that, and I had already commented on it in my previous message, based on what Maxim had pointed out before, that the names I had chosen were too imprecise. I like part of what you propose below: `:attr_latex: :prepend'. >>> However, I do agree that per-heading control over latex export is >>> currently cumbersome. >>> >>> The canonical ox-latex approach to customize headline export is >>> org-latex-classes variable. This variable defines (among other things) >>> pre/post commands during headline export: >> >> Apologies in advance if I misunderstood what you're suggesting, but >> isn't the "org-latex-classes" property supposed to affect the structure >> of the entire document? What I'm proposing here is rather something >> specific to particular headings (and its entire content), like the >> ":ALT_TITLE:" property. If I understand correctly, what you are >> suggesting is that org-latex-classes can have "local values" for >> specific headings, if such headings are 'marked' with some property? > > Yes, org-latex-classes is controlling the entire document. What I am > proposing (as an alternative) is subtree-level equivalent of > org-latex-classes that is also close to org-latex-classes semantics. > > More concretely, I mean something like > > * Section > :PROPERTIES: > :attr_latex: :prepend "section" \setcounter{secnumdepth}{0} > :attr_latex+: :prepend "section" \addtocontents{toc}{\protect\setcounte= r{tocdepth}{0}\ignorespaces} > :attr_latex+: :append "section" \setcounter{secnumdepth}{2} > :attr_latex+: :append "section" \addtocontents{toc}{\protect\setcounter= {tocdepth}{2}\ignorespaces} > :END: > > I suggest to use more canonical attr_latex that explicitly limits the > export backend. I see. But in any case, something like `:prepend "section"' would be unnecessary (and even counterproductive) for what I'm proposing, but I'm afraid I didn't explain myself well in the first message. One of the benefits of approaching this issue with a few minor modifications to org-latex-headline is that the result is regardless of the section level at which the property is applied. We may want to prefix the section with a specific LaTeX code only for \section (or \paragraph or whatever) and we may want to introduce a more general LaTeX code, level-agnostic. Explicitly put "section", "subsection", etc, IMHO unnecessarily complicates things. But I also insist (as I said at the beginning) that I don't know if this use case can also be extended to other users. Best regards, Juan Manuel=20 --=20 -- ------------------------------------------------------ Juan Manuel Mac=C3=ADas=20 https://juanmanuelmacias.com https://lunotipia.juanmanuelmacias.com https://gnutas.juanmanuelmacias.com