From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id gJTkJF3apmWQZQAA62LTzQ:P1 (envelope-from ) for ; Tue, 16 Jan 2024 20:34:53 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e224::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id gJTkJF3apmWQZQAA62LTzQ (envelope-from ) for ; Tue, 16 Jan 2024 20:34:53 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="D/nKAAQY"; 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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1705433693; 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=qa8jBCRLF09gwuK8t6pHV4Ra8CvzEd/1JWMgTwRZ6cw=; b=M6xHjP6X1voxV+6un+9Zq/En2aVXjlUwLDIyfoYprwCS4n9QX+Sry2w350shJUOWaPGy1c 58yaM/qDCLF58MYmHQXwPr4ArVbny0FStwp80/9neW6/s788rpjPw6e14IUhroyDwuHopE bJ5LfZjr1tqOW59XtBgdbBx2P94N0hs6zQ4JKPFcWmAW+z5IMV4PBpFbaBVwCBMvtJcq6r /8I2O3TQdKh3lMMhC8OdJu2QEpR3buc/fNtwoTYq3uodBJv1FBI6Amo6j/aRJKwPhcm6z7 O3HKkPOlCyajM+TY5R8QAarL3oSSgrY48eo1NYxko+DXHmBppBqQ2+Xy93CvbA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="D/nKAAQY"; 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" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1705433693; a=rsa-sha256; cv=none; b=Sh9+ajMj6UNAzbeFXIWpvD9BqppM1gcc450Y16FTwzgRW7AJQEmX+pL2zdOmKuOp0RS5VX DCK4Dul2QFEmHMbxPPCtfonsT1f0K+/2fX3mIOaHe0nerIaT9vLD3KdNa0PfSmGt3HfOKJ Pswn/iK3wwZ3X3c8j+ex7nltPUK5WDV2Mfo3w+GTxsWU1PzDwuj5eVpjmIPS40MDqx9K0K 7gsBHEDhD0vbQtDLP1+FG+kIQa5RBVnchunRKynjQoCd69Kot+jsGWC8tuthpL3O7Y+9mV CpIOkJ0KD3GYohN2mej8vjDm8IDV19+E2h6W2msM8QDHL8a2c0wEjSbR2emImg== 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 81A1A1094D for ; Tue, 16 Jan 2024 20:34:53 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rPpCI-0005TA-35; Tue, 16 Jan 2024 14:34:06 -0500 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 1rPpCE-0005Sz-C9 for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 14:34:02 -0500 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 1rPpCC-0000qi-8C for emacs-orgmode@gnu.org; Tue, 16 Jan 2024 14:34:02 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E4D14240027 for ; Tue, 16 Jan 2024 20:33:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1705433635; bh=hL/eNPv2v/3wzY3VXugpNlU9B1a8Ubt6gunQKat79Z0=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=D/nKAAQYqndFCz/43gluL+tGJtSHyCCVmd3IYdHK6c9Rjs0xAZn9rfpEr8tqy+7tt Xd361C681b79JNzdtALJ2s5AOKRhloUqNHjeY+c2Zxwr2Z1+pPtP5DWh0S95/k70ms Gdhks+Z4ujPbs/lk0dBjpckgiBPG479rFij0HgD9gl8fvF3bT3+LpJEPzpD0gGuYxv b6B1KbbxaK9xxWG124lLIB+cOwmyYeDsD15m5BWCKAY5AclElT3UyzhpWEt25U1L9X 4kqLCMOd3IWq2aPb436CZIWO5W0X4xeqj3B9ZDgPFWok5Ems1Gs3FRSJewdQCZ6Z6R y4R/6U8M7K+6Q== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TDzhg2dwcz9rxK; Tue, 16 Jan 2024 20:33:55 +0100 (CET) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: Ihor Radchenko Cc: orgmode Subject: Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export In-Reply-To: <87cyu1l69f.fsf@localhost> (Ihor Radchenko's message of "Tue, 16 Jan 2024 14:09:16 +0000") References: <874jfvjo2k.fsf@posteo.net> <87cyu5uv7c.fsf@localhost> <878r4tfccn.fsf@posteo.net> <87zfx9t7di.fsf@localhost> <87wmsddlw5.fsf@posteo.net> <87r0ikrt5h.fsf@localhost> <87o7dnefwo.fsf@posteo.net> <87cyu1l69f.fsf@localhost> Date: Tue, 16 Jan 2024 19:33:53 +0000 Message-ID: <87il3tax9a.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: -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, 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-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -10.40 X-Spam-Score: -10.40 X-Migadu-Queue-Id: 81A1A1094D X-Migadu-Scanner: mx12.migadu.com X-TUID: 46G+FRuz9u81 Ihor Radchenko writes: > The very reason we use \\[0pt] is because it supposed to prevent > interpreting [...] at the new line/transcoded element as argument. > > You demonstrated that it is yet not always safe enough. > > May it be better to use something like > > \newcommand\nothing{} > \newcommand{\safenewline}{\\\nothing} > > And then use \safenewline instead of \\[0pt] > > In my tests, > > \begin{center} > \begin{tabular}{ll} > [t] & s\safenewline > [I] & A\safenewline > [m] & kg\safenewline > \end{tabular} > \end{center} > > Does not suffer from misinterpreting new line as argument. I remember the thread where these issues were discussed and the long discussion where many alternatives were proposed. After all, the \\[0pt] solution still seems the safest to me. It seems that the problem is located only in the verse environment, probably due to some particular redefinition of the \\ macro that makes that environment. In any case, square brackets are a problematic character in LaTeX (think, e.g., of some environment that takes an optional argument). I think pandoc chooses to always export them as {[}{]}: #+begin_src sh :results latex str="[hello world] [foo] [bar]" pandoc -f org -t latex <<< $str #+end_src #+RESULTS: #+begin_export latex {[}hello world{]} {[}foo{]} {[}bar{]} #+end_export We could do the same, but I'm afraid it's too late if org-latex-line-break-safe already exists... I don't remember if something similar was proposed in that discussion, and it was rejected for some reason. > `org-latex-verse-block' already has a giant regexp replacement: > > ;; In a verse environment, add a line break to each newline > ;; character and change each white space at beginning of a line > ;; into a normal space, calculated with `\fontdimen2\font'. One > ;; or more blank lines between lines are exported as a single > ;; blank line. If the `:lines' attribute is used, the last > ;; verse of each stanza ends with the string `\\!', according to > ;; the syntax of the `verse' package. The separation between > ;; stanzas can be controlled with the length `\stanzaskip', of > ;; the aforementioned package. If the `:literal' attribute is > ;; used, all blank lines are preserved and exported as > ;; `\vspace*{\baselineskip}', including the blank lines before > ;; or after CONTENTS. > > We may as well strip the trailing \\[0pt] there. I think it would be best to remove the last \\[0pt] in the verse block. I can prepare a patch, but I'm afraid that org-latex-verse-block is becoming an homage to replace-regexp-in-string... Best regards, Juan Manuel