From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 6FBIH4M+TWNCSwEAbAwnHQ (envelope-from ) for ; Mon, 17 Oct 2022 13:37:39 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id SC9LH4M+TWO7lgAA9RJhRA (envelope-from ) for ; Mon, 17 Oct 2022 13:37:39 +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 020E51AA50 for ; Mon, 17 Oct 2022 13:37:39 +0200 (CEST) Received: from localhost ([::1]:57444 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1okOR7-0001fU-2k for larch@yhetil.org; Mon, 17 Oct 2022 07:37:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37230) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okOKN-0008E9-NW for emacs-orgmode@gnu.org; Mon, 17 Oct 2022 07:30:39 -0400 Received: from mout01.posteo.de ([185.67.36.65]:53473) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1okOKI-0006RC-OX for emacs-orgmode@gnu.org; Mon, 17 Oct 2022 07:30:39 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 4C2C0240026 for ; Mon, 17 Oct 2022 13:30:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666006230; bh=3PwQAcmUccyYkibku1ofWrX8BMHTiXdwnV/juZuU0ww=; h=From:To:Cc:Subject:Date:From; b=HZ3R0qJtF3ZPU+ptXyOFTlYl4QQF4Fl7GNwlVoNYmcZqyqelVJPUS8AjH+h6wNKrj m39i9exrVbdicUtDoHR1hdA5m+Jn8hYVMQbNe87HsnUU1CuSNEyek6YNeN+MUAJJOL WKQXQBx2C6sorQp2cHSKmS4NuIBg7xrHf+qPJGh2mEVZGOwwCl0Vf3uT+PPrzCis/O 0m+Qct7ntby14MwFYJIxi8e1KKbsM3pMEhS0+Y/aAZpAqvWMMR58KQa9YbGprmDcm5 T1J/rtyJSVtavGFQq6uxI0LseRTa+c6J6RGYiZoRmsVS3QSe0CORwQz7bX+TfP2rwv tV3yeKlw8wrBw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MrZYJ3zzBz9rxB; Mon, 17 Oct 2022 13:30:28 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: Daniel Fleischer , Max Nikulin , emacs-orgmode@gnu.org Subject: Re: Line breaks and brackets in LaTeX export References: <875ygk6a8z.fsf@posteo.net> <87a65vitbz.fsf_-_@posteo.net> <87edv6izx4.fsf@localhost> Date: Mon, 17 Oct 2022 11:30:25 +0000 In-Reply-To: <87edv6izx4.fsf@localhost> (Ihor Radchenko's message of "Mon, 17 Oct 2022 09:04:39 +0000") Message-ID: <8735bmelgu.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@posteo.net; helo=mout01.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, 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=1666006659; 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=myZ645UjHc24QVoGJuq1CpPVeIzvcZzV457vb/caBL4=; b=i3xWdKCwRM/Ta72omXgskVnYPPYQCLmrkmZc2ZOnA8VTa1XOeyOzfAFn++Sez7m7Ir1m76 YXyJZO1mitm3Q+ePznsaw1kCs6J3AYgdLFh15Ruy92O77w/C2AZJD76lOEWEQfWqRj8BXC AQkV9qN+U1sA8Kgqqvavbj6Rz7KeLpTJWeMQPp6TDMJasGjatKOIZmlNQuUcWhr6Gmb1pp CpVPjyAeO049nORZ3tHBIMnYiouF3HDb/+c596uiu/vzCAH26Whem45lAwxWqQ1yQSZFLp du7hrVX4ANDbigdgld+qvSmfnHxlTgUgjEgVeoulNXJxS1ZCliYlXVKnH6Rk6Q== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666006659; a=rsa-sha256; cv=none; b=KFNykwJmR1B7ulOOkuR3MhiYXf6nS4dN+hMKapR4ZyjLao9eGSkZHN4TJ2bGYCrCTY6s// os6/5/lhrtQs8juPHRPFS6R2Oz/2jIw4BmBIgKcY99eIc2NepFQYuh5cEOMKPu4E4Dm92H luarTdNax/chvwtUIU0wihFgTKv+iXdMJJiwG6jBaY+2P3rvKZBTjyRdqfqKQz0/oE8y81 cwZhNnCVVbmNk2q7Fd2SKnfe4YZ0O1llRt+2tMoklvrvCN0m7ajz4YVFH1txrPQtnut7Fw cS1Tk77JBoNgSo246vvClaltH4DSPy8vD0OW/eOX1wwkvdlYS42wcZepOVC0qg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=HZ3R0qJt; 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: -3.92 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=HZ3R0qJt; 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: 020E51AA50 X-Spam-Score: -3.92 X-Migadu-Scanner: scn1.migadu.com X-TUID: nwTxDrN3Ny/G 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 \\? 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? ...? 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 is an example I came up with of how it could be fixed selectively >> in LaTeX (big, big caveat: it's just a proof of concept and likely to >> produce errors in other contexts. I think if a LaTeX package to fix this >> isn't already out, it is either because the problem is very rare and the >> solution for particular cases is known, or because there are drawbacks >> inherent to LaTeX that I can't figure out right now): >> >> \makeatletter >> >> \def\my@protectlbrack{ >> \@ifnextchar{[}{\relax}{} >> \@ifnextchar{*}{\relax}{} >> } >> >> \let\old@break\\ >> \def\\{% >> \old@break\my@protectlbrack} >> >> %% for tables >> >> \let\old@tabularcr\@tabularcr >> \def\@tabularcr{% >> \old@tabularcr\my@protectlbrack} >> >> % for use the old commands >> >> \newcommand\oldbreak{\old@break} >> \newcommand\oldbreakt{\old@tabularcr} >> >> \makeatother >> >> \begin{document} >> >> lorem\\ >> [ipsum] >> >> lorem\\ >> *ipsum >> >> \begin{tabular}{cccc} >> a & a & a & a \\ >> [a] & a & a & a \\ >> *a & a & a & a \\ >> \end{tabular} >> >> >> \end{document} > > Won't it make it impossible to use > @@latex:\\@@ > @@latex:[1em]@@ > > deliberately? 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]@@ Anyway, like I said, it's a proof of concept. In the tests I've done it works very well, but on a large scale I can't be sure of the results. Best regards, Juan Manuel