From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 6BP9BqfXUGN3vQAAbAwnHQ (envelope-from ) for ; Thu, 20 Oct 2022 07:07:51 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id UKXhBafXUGPq+AAAG6o9tA (envelope-from ) for ; Thu, 20 Oct 2022 07:07:51 +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 DB36C45A6A for ; Thu, 20 Oct 2022 07:07:50 +0200 (CEST) Received: from localhost ([::1]:36370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olNmY-0000JK-2A for larch@yhetil.org; Thu, 20 Oct 2022 01:07:50 -0400 Received: from [::1] (port=48202 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1olNmX-0006xL-UG for larch@yhetil.org; Thu, 20 Oct 2022 01:07:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olNll-0006w0-U3 for emacs-orgmode@gnu.org; Thu, 20 Oct 2022 01:07:01 -0400 Received: from mout01.posteo.de ([185.67.36.65]:38543) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1olNlg-0001SY-BV for emacs-orgmode@gnu.org; Thu, 20 Oct 2022 01:07:01 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 38461240026 for ; Thu, 20 Oct 2022 07:06:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1666242414; bh=HwIHJrDepdxJDa/b0PX/sy7HJCBh2cePupuDjZ9t/iQ=; h=From:To:Cc:Subject:Date:From; b=lzOxM5/kXCiKMATzV6lNjo3DLkH3DHK77p/qQSBgHyyB+t9hYqaSxnYT027IkHLDg Dl9KdOcMLjHBCktx82K/x7kq6umvZKpRneCtxGwMc/0+EhszxfM/+AGwkUhELLKldg u4F2tjqTP/j1Yd3LuC81t/nsyrrdMPnoyZAFYU3hhOsR80fwbXfHR4tBcI/TaWUplg WV12Htn6AvsU5cU8IyQpUSwPLe55YJZHZN1S3L/zB4yn33pYi4fisrP0U1jfzoHPv2 XnjbrXs469qx+pxVlFb1BflcYU8UKs6fX2S88giQyBAr+RkcyUao8InNuJeR/A96l4 ae+6zhus5f5Vg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4MtFvH6Dkrz9rxB; Thu, 20 Oct 2022 07:06:51 +0200 (CEST) From: Ihor Radchenko To: Max Nikulin Cc: emacs-orgmode@gnu.org Subject: Re: Line breaks and brackets in LaTeX export In-Reply-To: References: <875ygk6a8z.fsf@posteo.net> <87a65vitbz.fsf_-_@posteo.net> <87edv6izx4.fsf@localhost> <8735bmelgu.fsf@posteo.net> <878rlecx49.fsf@posteo.net> <87h701hhjp.fsf@localhost> Date: Thu, 20 Oct 2022 05:07:37 +0000 Message-ID: <875ygf9j6u.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, 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=1666242470; 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=3G/iccURsEIIxt0XmDvG5Pg4UzvHsW6Dhs3K/v8K+Ik=; b=dQRubp01NAws5blf+vk+vs1S81+pHcEr0CBDv0gAttM4eJGW+gtHhBwSlry3547BSaVpDk gI3DcdbqhqzSVWVaf2dgPihIRamkpRem0VZx+aRWtTjuYd3K7BDz0GS7lKcmejFkp55LoE m0UecJbi/q8SMctt1PO+cF8sIp5bA/dc74BAFn9xmCec8JfnKhUkQJW3NgUoVqLGuXdeAG CGara9HSLAVdxQqWR0Q3FNDCUm/QgascMC3kfb/TIknOXX9tXC36OQNHLPuac3ATr4pNih 2LujMUaO595ZAypDh9/Sg5xPyklkb3ZVIjmtpUTACtHe8VqY2AoyTAeWv/ZoFA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1666242470; a=rsa-sha256; cv=none; b=rwmgXhkpRn3J+Q4QQf+Lrvv7dhMJSnREs9M4qkpvQR/nECU42UJn9gsKE6dHLg8VObrQvY 0o8Lym9jyvl+b9dMZxL9YAvOsYq2RJsf4cmfkFZz6Iw2XLHCutRUf4YpBt7OyQyHsh53VV 0M9st3pO8+yDSnwfIgVc4lQGycR9wgU4Pwq2fICgU9f95C/FHv36YVpr60JK1YorNODaZe 5nyRYx0Bu5ErPGUTMzPwqxdePg7bDszN7oNL9bcmV/SN6nyP2WovC2liEcMxiEbYlMPga+ wqMIvcF+qcR2A/wCxhfCPYFuN3KjPGEy2d9tUW9LPgA1epivCJTc/2dABL6o3g== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="lzOxM5/k"; 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.43 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="lzOxM5/k"; 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: DB36C45A6A X-Spam-Score: -3.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: c/H2ZByjzkii Max Nikulin writes: >>> Selectively adding some workaround require complete reimplementation of >>> exporters. I have some curiosity concerning pandoc approach, but I am >>> unsure if I will reserve some time to read its code. >> >> Maybe or maybe not. We have org-export-get-next-element and a number of >> exporters doing something special for the first/last object inside a >> container. > > I have an impression that markup generated by children often added using > %s to some other construct. I may be wrong. You are right, but missing subtle detail. Export transcoders for container elements are called with 3 arguments: data, contents, and info. DATA contains the actual AST of the transcoded element, including its children available via org-element-contents. CONTENTS is the string representations of the exported children elements. Before CONTENTS is generated, relevant transcoders are also called for each child of the DATA. When transcoding children (e.g. table rows), the sibling rows can always be accessed using org-export-get-previous-element and org-export-get-next-element. >>> An idea how to avoid complete redesign: at first add something like >>> %__ORG_PROTECT_NEWLINE__ >>> after each \\, later at an optimizing pass remove the comment if next >>> line does not start from a star or a square bracket, otherwise use some >>> workaround, e.g. "{[}". \relax may be suitable as well (in the beginning >>> of rows, not after \\). >> >> I am not sure if it is a good idea. It may interfere with export filters. > > I do not expect negative effect from a comment added at the end of line. > Optimizing pass may be performed prior to user filters. Filters are applied by ox.el immediately after transcoding each element. See the final expressions in org-export-data. The filters may alter the exported string, including removing the %__ORG_PROTECT_NEWLINE__ we put there. Of course, we can warn users about this particular caveat, but I do not like such design -- it is too fragile. > As another approach text properties may be used as a communication > channel unless they are stripped by ox. I am not sure what you are referring to. If modifying exported string, it will suffer from the same problems as your idea with comment. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at