From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id QFE4GI6K0WICQQAAbAwnHQ (envelope-from ) for ; Fri, 15 Jul 2022 17:41:02 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 8MjLFo6K0WI+TgAAG6o9tA (envelope-from ) for ; Fri, 15 Jul 2022 17:41:02 +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 E3E6C20564 for ; Fri, 15 Jul 2022 17:40:57 +0200 (CEST) Received: from localhost ([::1]:40800 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCNR2-0004L4-IV for larch@yhetil.org; Fri, 15 Jul 2022 11:40:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCNOz-0002La-3f for emacs-orgmode@gnu.org; Fri, 15 Jul 2022 11:38:49 -0400 Received: from mout02.posteo.de ([185.67.36.66]:57861) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCNOh-0002dZ-Sz for emacs-orgmode@gnu.org; Fri, 15 Jul 2022 11:38:47 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 1FFB9240107 for ; Fri, 15 Jul 2022 17:38:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1657899509; bh=5ShAfcm4Gn4JxJxb+eFQyY7do/tqvg98ZSmntg8+1YU=; h=From:To:Cc:Subject:Date:From; b=ldSNxJ8cRXmENuMUc+TGofx3XoTMBNosOwB55XT/HF1bMLlzlU8ipN+EnUgEOTdry jbHpyGqAVlqXDNwy9kAqvQ5msaxRLnF7zvpRCY7GwGzME0+g2XKvBPhHYKcUQRvDQd 0xhsd95aMvWbPTrjTh4dFUzMx9EergZgN9JcBb8DAg0/eBFRUaNvqKP3ne8aJmOKWP Cuh8eSctj6PXxFgt2dwNAhGOX2zsjevwxLgkKkQKDEwY6rK/mf06kQ50GGI1Dt1bsP 98ckhMNSbg0AePf2p8fpFoJ0nMEEXrmJJuHP5z7RIsPcbhhdc9Jxi4B7EX8OW5ARy4 RyuwROH/03gzg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LkwVr1LGxz9rxV; Fri, 15 Jul 2022 17:38:28 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Max Nikulin Cc: orgmode , Ihor Radchenko Subject: Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists References: <87sfxiw2jp.fsf@posteo.net> Date: Fri, 15 Jul 2022 15:38:25 +0000 In-Reply-To: (Max Nikulin's message of "Sun, 10 Jul 2022 17:51:52 +0700") Message-ID: <87wncez8r2.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=maciaschain@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, 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-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=1657899658; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=d454HKwwueng5OYQ5QF0lX9u6ymJSvzp6g2xvtsRpKw=; b=Ah/Tk0faxjn4bz/MhHAB0YZwAuFvKI4rXxvJFljW5UZpPsEvdIucAx5s77hbCSYjYAaw7Z 8OVt6+Lpe6jlSZWLCWvntvWn0lvdyRhNW8bQjtMEBcPEhQJx0+63cty0NdgBJzfC/g+AeS OAD25QmXdhmZ9X926LfzLMmUKBa3VuF4StFw91DW8diC2GsshEfUFcWONKfvV1OzMfL22H v/rw+doHroND7yUmzbn7HGstFwfKbPJWotGSndqKprs9DDSMRQM8skHzKX/1SwgxGKsL6c bf0Q4N7ss2MKM6FipEdrrk+2o3RJ9PPJ9IwUPyg4jmFo8aOXl6diq+647NW5wg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1657899658; a=rsa-sha256; cv=none; b=PGi2ddhxwy34MLac+60AbDiJcvLi44vbjV2bEm6S0j4U1dK0ovLbtfFQ/GJGdXnAufmU7a sODFe9cM35MXmlbdz3WwsALCNFCADbpOmrO4ns0NIWC/hA7N+Eo1t4c6I/MwGwxZTAqPDR XFNvD1hsVQNWPkpSehHUC5TYGSDuyzEwoCUpGa44o4jvQeY/6WLQh57diMXBzba2FZpzHq 8rimRD8+zr13nxN/MKpbFMUHgsnrAJ/no4s5kT/x5E38wPla5r05lA+iMf7xTOzQWdKiUg om6acxDSweTtSpOWSaKcDoxQn0iGbAwjsBYVi94rDxm3U5YZgwMc0zR8nT5qCg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ldSNxJ8c; 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: -8.94 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=ldSNxJ8c; 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: E3E6C20564 X-Spam-Score: -8.94 X-Migadu-Scanner: scn0.migadu.com X-TUID: nQe6i3gAsdpq Max Nikulin writes: > I would consider structures with named fields (alists or plists) for a > case of adding some additional settings (Font name? But it is rather > defcustom than defconst) > > ("es" . (:babel "spanishmx" :poliglossia "spanish" > :poliglossia-variant "mexican") I was paying more attention to the fontenc issue and I had forgotten to comment this. I think your proposal to use a property list makes sense. But I don't quite see what new settings could be added without overcomplicating things. Babel in its latest versions has several ways to load languages, and many new commands to select fonts or associate font families to a specific language or script. But they don't work with pdfLaTeX, so the only thing I could think of is to keep the old babel method, valid for all TeX engines, according to which, if a user puts in an org document: #+language: es #+latex_header: \usepackage[foo,AUTO]{babel} it returns: \usepackage[foo,spanish]{babel} which is valid for all flavors of TeX. And I think that this way, as Org was doing so far, it will satisfy most users. But given the syntactical variety that babel now has (polyglossia is simpler), I don't see how all of that could be 'translated' to Org via Org settings. I think this is one of those cases where it's easier for the user to just build the LaTeX preamble writing LaTeX code or create a new 'class' for org-latex-classes. The problem with Org writing the preamble for the user is that it will never satisfy all users. That is why I think it is necessary for this 'automatic' preamble to be as basic and elementary as possible (I, for example, always write the preamble from scratch or write my own sty files). Otherwise we run the risk of converting, or wanting to convert, Org into a clone of LaTeX, but less flexible than LaTeX. I agree that most Org users (like most Pandoc users) just want to produce a clean pdf without messing with LaTeX. But if users want to do more things in LaTeX, they should know some LaTeX, even if they prefer to use a lightweight markup language as a latex 'interface'. That's why I think it's great that in Org you can enter arbitrary LaTeX (or html) code anywhere and at many levels. I think this is the real killer feature of Org. I don't know if I'm explaining myself... But this reflection of mine (which, of course, is debatable) would take us further, and this is not the case here. Other than that, your idea of using a property list sounds good to me. What happens is that I do not see a clear advantage (at least in the short term). Best regards, Juan Manuel