From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id gFAIE7gfdGcQfAEAe85BDQ:P1 (envelope-from ) for ; Tue, 31 Dec 2024 16:45:44 +0000 Received: from aspmx1.migadu.com ([2001:41d0:403:4876::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id gFAIE7gfdGcQfAEAe85BDQ (envelope-from ) for ; Tue, 31 Dec 2024 17:45:44 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="m/3L8c1Q"; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1735663544; 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=reiW0rXeR66kFwFXNNE8tXpA2OrQyqBmBlB/xy2BLZw=; b=kv283g+pjE1WQFo8ZQZp6U1/CadVXAeSmQGZ5NZRb2uUE50RnzsltyWHWicU9sohFWez+c qZ9J9oR9LDDwM7J/DgFFc6M/Xgn6KMoPQWFFlVB1R7IjXyOuMqvNhAKZawtykVzMXjPjVj 6T7N65/pC7zcYoGVwZSYzbXoX6DcfhXslxMO9MlOFle+EgUEFqz54wMv4EvKLMBgOF17Z3 bcW/AxPTxH/A77quU3L0K3oD5k8xW8+BR44c10kkeTl5Mq/HtUyW4FrxsCK2H2r5cfLgaB Ix+T+RA00k3LxWxsgBqcEncLS1VOiIEJaDvuYdBybd4n4NIw31xWlEx+Th/4yg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="m/3L8c1Q"; 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"; dmarc=pass (policy=none) header.from=posteo.net ARC-Seal: i=1; s=key1; d=yhetil.org; t=1735663544; a=rsa-sha256; cv=none; b=ZpwU5ka7qy3vxbVQlMyoMktQHrsy55cL5g4c7bsp6FAuyX5E+G5OqEi+pRuIkd7DGjPPjy MgGQg1Q0LBaxRQLAMnlK3edSINGV6qX81R+ZWjxGw+5Tjmmuhiy0w/4pNrTh3xBOlLINLx zdOrHiShWQ8yN5NADd2iPmlX+wckKRFz6PpobmLHM1lcNwzGHGLpvjidpBlKSgjlJVAKqA i/ImvBL1SI7Rxw5IhzactW21NG2BTXY+1x05dfCAm4MIrvwOWZi2zdnLLoIKhfCdweOmEb 7/E7RDnQPzKP7887CBwhHjzk84oVRnZolA3pA5uCIhcEJM02ehc1QgObgN5x+g== 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 C1DB692C90 for ; Tue, 31 Dec 2024 17:45:43 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tSfMZ-0000B6-OI; Tue, 31 Dec 2024 11:45:01 -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 1tSfMM-00008l-Re for emacs-orgmode@gnu.org; Tue, 31 Dec 2024 11:44:47 -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 1tSfMK-0005y9-Fe for emacs-orgmode@gnu.org; Tue, 31 Dec 2024 11:44:46 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7063A240028 for ; Tue, 31 Dec 2024 17:44:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735663481; bh=bpO9TXYKLKg9297xk8gmCUf39pUM7ksJ+751TLxdxpk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=m/3L8c1QGhVryOeP+LMIcCa3gxwk19dP4k9SwLcD0EPTeE3UDou9v1fs173f6nJtM nbXA0XYAV6Aw4+uLrVwq+rx2wDEacZJOoO2+TPfV4HILhZb8pKjp5uvLNvSoOj6Lqr AA5IoN2rlsPDvgCioUPjKGoy4fZOkgMmr3GEql8u76CZFD9DHz9I91p0G67lDrLqPe WaOunGjiIJhWXrviSHsIZXsCCPCQbh17TJP4yaGRbUwjNqIhYmB5LvJOBYBwi+hOmn PolK75ANOPx9FZGywp4t7ffD70AAB0JksNM+zww9NTKYsqsOahhRgVLDSqd2Ca8Zok QRnQHc+wOqs2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YMzMr5Bl7z9rxG; Tue, 31 Dec 2024 17:44:40 +0100 (CET) From: Ihor Radchenko To: Rudolf =?utf-8?Q?Adamkovi=C4=8D?= Cc: Max Nikulin , emacs-orgmode@gnu.org Subject: Re: The less ambiguous math delimiters in tables In-Reply-To: References: <87ldw5igab.fsf@localhost> <87bjws8l0i.fsf@localhost> <87v7v0geqs.fsf@localhost> Date: Tue, 31 Dec 2024 16:46:07 +0000 Message-ID: <87seq3hkc0.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.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, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=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-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -9.18 X-Spam-Score: -9.18 X-Migadu-Queue-Id: C1DB692C90 X-Migadu-Scanner: mx10.migadu.com X-TUID: p0EtiScYx1vs Rudolf Adamkovi=C4=8D writes: >> It is not just about \(...\). > > Of course, and I agree that a more general mechanism is needed to solve > all precedence problems, be it in tables, or (better) in general. But, > as I said before, even if we had such a mechanism, it should not be > necessary to use it for \(...\) in tables, as there is no ambiguity, and > so no "madness", no? Does that make sense? Or, am I mistaken? IMHO, making special cases just for certain types of syntax is worse than universal approach. Imagine that \(...\) takes precedence as you say. Then, users may look at it and assume that everything else works the same. And get confused when it does not. Or an opposite - get used to how the rest of markup works just to find out that \(...\) is suddenly different. And that it aside from complicating the parser *a lot*. It is not at all trivial to implement what you want. --=20 Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at