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 YAaJLsogTGPLUwEAbAwnHQ (envelope-from ) for ; Sun, 16 Oct 2022 17:18:34 +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 cICQLsogTGOpbgAA9RJhRA (envelope-from ) for ; Sun, 16 Oct 2022 17:18:34 +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 9365A108E3 for ; Sun, 16 Oct 2022 17:18:34 +0200 (CEST) Received: from localhost ([::1]:46532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ok5PN-0002Qs-Gy for larch@yhetil.org; Sun, 16 Oct 2022 11:18:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55824) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ok5CE-0005dc-TO for emacs-orgmode@gnu.org; Sun, 16 Oct 2022 11:05:00 -0400 Received: from ciao.gmane.io ([116.202.254.214]:52750) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ok5CD-0006fd-Fc for emacs-orgmode@gnu.org; Sun, 16 Oct 2022 11:04:58 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1ok5CB-00063E-RA for emacs-orgmode@gnu.org; Sun, 16 Oct 2022 17:04:55 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [bug] `org-latex-line-break-safe' breaks the export of verse blocks to LaTeX Date: Sun, 16 Oct 2022 22:04:48 +0700 Message-ID: References: <875ygk6a8z.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US In-Reply-To: <875ygk6a8z.fsf@posteo.net> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 28 X-Spam_score: 2.8 X-Spam_bar: ++ X-Spam_report: (2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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=1665933514; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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; bh=T8pqr9ZP0Rcn4IJIbkGGW6SkWZP18zrDkhLMZ1zrBS4=; b=J572MmJNwG2X3sTsUGk6AbjIsgs/T8ubbKHJVg9RyojSLTdjbqmcLdSF6Egt6uuvbGCDv8 v8RYX+qjQSrW0DbWB27J5ESHZju6rIUUmg0VPugHzUQH14yAXxtCk3PMO3hVU3N4BPcZHO j1QB2ZKtqr8Pe4hobX6O4Y68Z0iPzeDY8KCixFHoPob+5x8qPTKij/rAgAN5e4Q0a47hTX LT1iSbFB0g7GFmIF0o3C/SPjHhw00rJ3nlWnV2/Lwf4lFGWMVP71w0+OY6z/E7gDHDIOV7 RNFXPTcHvxZxG16N4aw3H6W8cso/E2IO8pt5LgbK6LR6K9+v8Ww7BYnnw5axtA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665933514; a=rsa-sha256; cv=none; b=gOvll8aAh1x4mBVntbrNzEAR1EVoYLabVaxGyvpUd85Yb/tN4mkGV2mH1T9kQqEJRNkOeP bUE4ag2gGy83lcbEyv3nzAf/VDaE+4HxHur35Bl7shURxl3gAksnl6p3le/5M/ZegYmTLW xy1mUnQKkuSJsufE1dXCo6FYIoWJHReMPq997ZFHZz56xppo/MXdlzdlC5J4VJClkQVcwf UTtpPR1JqBPBB8JjXfIEXbEMpiMqy0MAWjC2SPVAgRiMVE6BVacYHY9ea5PbHpF/geTzts caDzbAwCEra/N3cqwispP30ZEXxhOHrGlYOrmkzfgit9mfgevqabep5tw5Qx7w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 4.29 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none); 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: 9365A108E3 X-Spam-Score: 4.29 X-Migadu-Scanner: scn1.migadu.com X-TUID: NICqoRYbKyCE On 16/10/2022 04:35, Juan Manuel Macías wrote: > > To begin with, it is a particular solution > applied in a general way. This can have unexpected consequences, as has > happened in verse blocks. In my opinion Org has to apply a general solution merely because a table may be result of evaluation of an org-babel code block. I may be wrong, but I suspect that some users do not care what is the intermediate format when they need a PDF file. > And finally, I think that applying a general solution to this problem is > something that should be done(IMHO) in LaTeX and not in Org, Org has a bit more information concerning context of square brackets. They may be just text of a table cell or contents of an export snippet. In a LaTeX file they are just square brackets and there is no way to distinguish them. I believe, it is a design flaw in LaTeX that the \\ command does not have a counterpart with no optional * and [] arguments. For humans \\ is enough, but it is fragile when LaTeX is used as an intermediate export format. A part of the problem is that all 3rd party packages should be adapted for the robust \\ sibling. Likely it may be solved by additional pass in the exporter code but it will significantly increase its complexity. I have no idea what is appropriate place to discuss such issue with LaTeX developers. The following is irrelevant to the recent changes. I have tried ---- >8 ---- text #+begin_verse a b c d e f g h #+end_verse ---- 8< ---- With the fix Ihor committed today I have got ---- >8 ---- text \begin{verse} \vspace*{1em} a b\\\empty c d\\\empty \vspace*{1em} e f\\\empty g h\\\empty \end{verse} ---- 8< ---- My expectation was ---- >8 ---- \begin{verse} a b\\\empty c d e f\\\empty g h \end{verse} ---- 8< ---- I am surprised that \vspace is added instead of empty line between stanzas. Is there a reason to override LaTeX defaults? If such reason exists would not it better to add \parskip=1em plus 0.5em minus 0.25em\relax before first verse line? Is hard coded rigid vertical space acceptable when high quality output is desired? \vspace before first line looks like a bug. Frankly speaking, nested calls of `replace-regexp-in-string' makes the code hard to read. P.S. I have not found exact citation, but I noticed a mention: Lamport expected that verse environment would get negative feedback from poets.