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 aHuZGbRBTWMXswAAbAwnHQ (envelope-from ) for ; Mon, 17 Oct 2022 13:51:16 +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 lCeaGbRBTWPZUgEA9RJhRA (envelope-from ) for ; Mon, 17 Oct 2022 13:51:16 +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 CB9F7DF4F for ; Mon, 17 Oct 2022 13:51:15 +0200 (CEST) Received: from localhost ([::1]:42840 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okOeI-0003yQ-VW for larch@yhetil.org; Mon, 17 Oct 2022 07:51:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okOaB-0003uL-UF for emacs-orgmode@gnu.org; Mon, 17 Oct 2022 07:47:21 -0400 Received: from mout02.posteo.de ([185.67.36.66]:41775) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okOa9-0000Y6-OY for emacs-orgmode@gnu.org; Mon, 17 Oct 2022 07:46:59 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 55804240103 for ; Mon, 17 Oct 2022 13:46:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666007215; bh=oGuayI91VGF1waqeZ1jWQbFQaM5ovDxAKIZQmvappD0=; h=From:To:Cc:Subject:Date:From; b=Xh5G9gO037rmGkC8OFdyWGAZnyx3IsuFJIAc2XPZf5yUQ9UPFa59tkHHNsXdeznk2 zxqeS+t/Sk5aZSZU9xU7xKcgjt5ALkE2JwfjuYo2QqDHCBfdoZIOtoRvxkJ6rCbVaJ BK2BrGxRw8hFrgQx1H+f6Bc853w6yl+c7ppIjaFwhdZSHdpGtLFDdyIN5+18y0KFuC VO5nZJdFK5TXf0tuRhZkGDgvMrkXEvC0nVhKKf+wfyKw76+gPrWKgeTvOwXAoahfJ8 bv1CCpg+BfvpGjYzVZGb6Fj4XotU30pA0zMnZcj5gnh9aq73hPTRCGUTqsYhnLK00x A5+iZ7FjtOBeA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MrZwC35R4z9rxB; Mon, 17 Oct 2022 13:46:51 +0200 (CEST) From: Ihor Radchenko To: Juan Manuel =?utf-8?Q?Mac=C3=ADas?= Cc: Daniel Fleischer , Max Nikulin , emacs-orgmode@gnu.org Subject: Re: Line breaks and brackets in LaTeX export In-Reply-To: <8735bmelgu.fsf@posteo.net> References: <875ygk6a8z.fsf@posteo.net> <87a65vitbz.fsf_-_@posteo.net> <87edv6izx4.fsf@localhost> <8735bmelgu.fsf@posteo.net> Date: Mon, 17 Oct 2022 11:47:38 +0000 Message-ID: <874jw2r7s5.fsf@localhost> 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=yantar92@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, RCVD_IN_DNSWL_NONE=-0.0001, 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-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1666007475; 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=FZ/ITfPUA1wznNR6brhRJM4LJvBLtiXFjb2+wTEcfK8=; b=DX+pnoFnGXk5NRxNGMOtwsJZmEkOQQzHgCaxKk2NL46sCqs5lHndCGvbmNXE6/S4c2e7uP X3ZiWzgUf2NWWYmL5qK7CSIDdWuKAedMfE70kh70Rwk/ZawDquCAVjDIq3j/oQ+95Oume7 MjtPxgJRieN/iqV7Ae4gNKbHYDL58vwcnLUDlHLhvvsus4JRShZeGXY5EFq2SjDMX76IF1 dbr64Ws2TU2RJbT2keJCObXiHwblcMZJ8S+jNAxZCG/JpfayjQmgBeGWecc1ZSquDvE8kL mVmGh1A6QjKFNQM+0VrJhezAZK5SY4OXuQYM3JQ/loRE5Tar7yMhgpQCo9mpRQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666007475; a=rsa-sha256; cv=none; b=jt6ndvoKW4gOndqS26McB5+wGiR1nDrOgpO5xzu1ZycZcMdUnlQ8Yl9/2wPNNzbjVBkyGp i6Ksnvmx1cnVrMv0XEoyvgkghZu0hd1tjn6UieQ4ze3vELztuxC6cMS/xoECd9iQ5z+Od5 PbXL4BeeocdKu9+9dWjel1TbVChyX+s9gx441hng5bwszUi3Ea0Tmd7mwpcuPFrXMQYLzv Cvhn70E6vKm5KHaft6c5lsDTfPBbRDmBbqiZAF/UwsYhOWSDXVwgbdPG+SdUbvxRJAhfr5 cnOn1lkeJ58rTFEzNIk9HlSaGnz/B1XBGEKI1hFHcD3YDtLefu2kbhSVMCAgbQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Xh5G9gO0; 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.72 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Xh5G9gO0; 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: CB9F7DF4F X-Spam-Score: -8.72 X-Migadu-Scanner: scn0.migadu.com X-TUID: IUBqTnPPtVTI Juan Manuel Mac=C3=ADas writes: > Ihor Radchenko writes: > >> I see no issue with defcustom in general, but can you explain what >> practical problems it is going to solve? I am not talking about >> aesthetics of the exported LaTeX. > > In my opinion it is not so much a question of aesthetics as of (let's > say) a certain conformity with what a LaTeX document should be. I think, > for example, in the case of a user who must submit his/her work in LaTeX > format to a publication, following the rules of that publication. It is > one thing for a LaTeX document to compile without error and quite > another for a LaTeX document to be or not to be formed according to good > practice. Would there be a problem sharing LaTeX documents with > unnecessary commands like \empty after all occurrences of \\? I haven't seen any publication rule that prevents using valid LaTeX commands like this. Do you have concrete examples? If not, one could argue that any auto-generated output could break some imaginary rule. I am also wondering how LaTeX documents generated from LyX or TeXmacs look like. Are they not using some obvious machine-generated constructs? > Anyway. As for the compilation, it is highly unlikely that \empty will > cause any unexpected error. But LaTeX and its over 6000 packages is > unpredictable. It also seemed unlikely that \relax would cause any > problems, and catching up on the last discussion, it had to be replaced > by \empty because it returned an error just before \hline. \relax is one > of the recommended solutions from LaTeX, because it tells LaTeX that the > previous macro has finished expanding, but it is recommended keeping in > mind that the user will apply it only when needed, not everywhere. And > before \hline it doesn't make sense because there will never be an > '\\[...]' error. So, in the current situation, we can ask ourselves: is > \empty everywhere safe? Everything points to yes. Can we be 100% sure? > ...? My answer is: "\\" is 100% not universally safe. Simply because we have that bug report with [ ... ] items in tables. So, anything with no concrete counter-example is better as long as we are reasonably sure that we are not breaking LaTeX conventions. > The only thing I can think of, for a non-selective solution like the > current one, is the following: if \\ has an optional argument that must > be a length, then let's give it, but with a value of zero: \\[0pt], which > is equivalent to putting the value by default (zero) explicitly. This has been proposed and then rejected by Max in https://list.orgmode.org/orgmode/ti5tdb$rd2$1@ciao.gmane.io/ and he concluded that some side effects are present when using \\[0pt]: Max> \\[0pt] Max>=20 Max> causes insertion of some code for negative vertical skip (of zero heig= ht=20 Max> this case). It should not be really harmful, but I would avoid this ha= ck. > What I've done in this code is redefine \\ so that if the next character > is a [ or a * it doesn't do anything. To use the macro with the old > behavior, you would have to use the new macros \oldbreak and \oldbreakt > (this one for tables): > > @@latex:\oldbreak@@ > @@latex:[1em]@@ It means that LaTeX packages that redefine \\ may be affected. I'd prefer to avoid such side effects. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at