From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id kPqDKDQpBGWDHwAA9RJhRA:P1 (envelope-from ) for ; Fri, 15 Sep 2023 11:51:48 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:4789::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id kPqDKDQpBGWDHwAA9RJhRA (envelope-from ) for ; Fri, 15 Sep 2023 11:51:48 +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 41A4C38B22 for ; Fri, 15 Sep 2023 11:51:47 +0200 (CEST) Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YoJPF9kx; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1694771508; 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=uau+P894HgG+a8m+lvEVx2E8Wv+K9JxBIjKvCLOvdi8=; b=SuCZsN9+j1AfnY+PH8fMK40+7GPXXLEiOznyh/q6rujY8+v2ayRBbt/3SsVbbDrHCBVpdC Zz8D0VGgGPokKwM39deVPnLNGC76LxU7lxMAt+n4xnqYFsgmNM3a4vMKFwoABAqd/tY07P hlD2fnhi8SxSeevMF11eU9MOxgqAAszDavxThtwV1TB3cBtzAXNGv++sPCkH5TbympkXIM EnMef8Q2AKB70+KmzFMu9l8/aCHnNO0TaU7A6hiAUphewqSpU5tt1ipA4mBPPKAmOgNhyw 6ZgQFH4jUHt96zu0F7m92T7MvK8JZF3zOrhoY99E3vBSqZxN/oAtNyvJB1cWBw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=YoJPF9kx; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1694771508; a=rsa-sha256; cv=none; b=QBzH1Xgve2zJEDPPhI3HPEdqEggGj3kHSgEGn7XKCgBVlBSK4bIoIRghf5PO+Hqr85CuKi Bt4idXqnWShjtR10v1YRxCqlGX9RTHDwrTKSZ69dLx/I/SXmpIGih+8LjLR2M8dJYTCh5s Adz/Txo0oGrnhBK+SDgV4xABSNwSxo28Tf48ulnaPopgQIYsAUUkIdd7E168GmGFIQLfvH ws0T3slJJwsV67LpYdsXrwZo0lamHYbrgbF4rX7pKO/02qNVS5234KCl+VzrTwd6f7moNl 7qp6d9Uy4F66fClY59KW0D9MZJBCTlMqBR6JZHytWTEcnZjgie5rv0sN6WhhoQ== Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qh5TU-0001SJ-3k; Fri, 15 Sep 2023 05:50:56 -0400 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 1qh5TR-0001Pj-BU for emacs-orgmode@gnu.org; Fri, 15 Sep 2023 05:50:53 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qh5TO-0003Pb-By for emacs-orgmode@gnu.org; Fri, 15 Sep 2023 05:50:52 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 2B1A9240027 for ; Fri, 15 Sep 2023 11:50:48 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1694771448; bh=a4lillHAg9DuUm7aeIxUnVPcygixi1HQ7OJ8jcx6UuE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=YoJPF9kxb/AyTJXx2lyJd+Kjg1bDK8v7UenkQusmvPY+aGSxOBd41vr7jke6GFH0+ 3Nv8/YY8fX3nNTg8cc5rVcavumo0R4PQlsKj7MERgXszVIZnftQ7Ohq/I/3Fhw1S+Z a88jwH44w2YAhgISG/YDv7nrtu4YVUre0U53BzatVHAs04C96NDs3jAeBaG/1YQxOe iS42OvBwwxa2osGthpqhVJVPK/4x+kF18CHzwKHPBssOZt9guaSBGgIEHiPCepa3pt Z8c8dgDyhLoXWxZNq4fELVWHTuIixnFiOuSnIlBlUkymaD54WJjc7/qOLMIpsyFH8V JPNbCnCxW1NTw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Rn8Zb2bmVz9rxH; Fri, 15 Sep 2023 11:50:46 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: [patch] Fixes and improvements in org-latex-language-alist (was: ox-latex language handling in Org-9.5 vs 9.6) In-Reply-To: References: <87v8cneyfu.fsf@posteo.net> <87edjanqxb.fsf@localhost> <87o7ieukum.fsf@posteo.net> <877cp0ybdg.fsf@posteo.net> <8734zoxzd0.fsf_-_@posteo.net> <87tts37lsx.fsf@localhost> <877coy9djg.fsf@localhost> <878r9biwwm.fsf@localhost> Date: Fri, 15 Sep 2023 09:51:43 +0000 Message-ID: <87h6nvahn4.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.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_H5=0.001, RCVD_IN_MSPIKE_WL=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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Scanner: mx1.migadu.com X-Migadu-Spam-Score: -2.31 X-Spam-Score: -2.31 X-Migadu-Queue-Id: 41A4C38B22 X-TUID: iuS1Cq2pMhEP Max Nikulin writes: >>> Every piece of code accessing this public constant must implement >>> fallback from e.g. "de-ch" (or de_CH) to "de". Or to "en" for an >>> unsupported language. >> >> Not necessarily. I mostly thought about some unconventional code that >> uses the constant for some reason unexpected to us. We do not want to >> break that. > > My point is that direct usage of `org-latex-language-alist' should be > discouraged. I doubt that code using `org-latex-language-alist' is common. But in any case, before trying to discourage the usage, we need to have alternative API. > I am not against them for the "#+language" keyword (however I am unsure > concerning e.g. human variant for de_IT). In the code I would prefer > ll_RR locale identifiers as a widely accepted practice. Either way should work. Because we have to support ll_RR/de_IT/etc for backwards compatibility anyway. This is a minor detail, IMHO. >>>> Though I am not sure if we can easily handle tricky >>>> cases like weird installation directory for TeXLive or MikTeX. >>> >>> kpsewhich babel-de.ini >> >> which may not be in the PATH. > > From my point of view it is a call to trouble. E.g. I have no idea how > to determine if LuaLaTeX is installed. Notice that in Debian the > executable file is provided by > > texlive-latex-base: /usr/bin/lualatex > > while actually texlive-luatex must be installed to make lualatex usable. > Unsure if there is a better way than > > kpsewhich -engine luahbtex lualatex.fmt > > and I am not sure that this particular command is reliable enough. > > Moreover kpsewhich may help to detect if some packages are available for > export or a fallback to less advanced ones should be used instead. We do not yet have a mechanism for fallback packages. The idea is reasonable. Not for now though. >>> /usr/share/texlive/texmf-dist/tex/generic/babel/locale/de/babel-de.ini >> >> which is not true on Guix, or when installed under /opt via make install. > > It is the exact reason to use kpsewhich. Besides install paths it > respects TEXMF environment variables that may additional user-specific > directories to search path. Makes sense. >> I did not mean the conventional distros that follow conventional naming >> schemes, but the edge cases - I see no point adding automation just to >> fight various non-standard user installations later. It will not make >> maintenance any easier. > > I am considering generating of some locale data on a developer machine > that has all necessary packages installed. In general I am against > storing of autogenerated files in git, but in this case it may have sense. This sounds like an extra maintenance burden. I'd prefer not to add it. What can be done is defining a constant in the code and adding a comment how to generate its value in case one needs to update the babel language info in future. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at