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 ms9.migadu.com with LMTPS id UFtGE7XmjmSYSAAASxT56A (envelope-from ) for ; Sun, 18 Jun 2023 13:12:53 +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 0OVpErXmjmSvHgAAG6o9tA (envelope-from ) for ; Sun, 18 Jun 2023 13:12:53 +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 C9BCA141C4 for ; Sun, 18 Jun 2023 13:12:52 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qAqK1-0006q6-HI; Sun, 18 Jun 2023 07:11:53 -0400 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 1qAqJz-0006pu-Uz for emacs-orgmode@gnu.org; Sun, 18 Jun 2023 07:11:52 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qAqJx-0007CD-NH for emacs-orgmode@gnu.org; Sun, 18 Jun 2023 07:11:51 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id C3DDB240105 for ; Sun, 18 Jun 2023 13:11:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1687086706; bh=ELC1gzAo0OcnXM85D38dBn9T00cvY2EJoYFwK0d7hnM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=fuMoYA4wegZGXo62/zqTroaTTMfxuC1Td5fCCgj1/afs9FWpGzrewLWchP35EwDSp Opq9Fik6YW1jxMf6BBNpZXvBB/C8N684zfiTwpv1eeptFNmwumFDR7HgBAUe+Mve76 A2/Vz4cj5iY5+3x+fAg0JmJJBMLyK4ILX5CLMH7eXj69Mif5xSZOvkR0Sr34WXwDzX xK8Hlgqqlai7ec5tE7el7QTuOxaG+djn0dU5HOb4BisZgywrQ3y7AFN1y/V2bKEauc vSpd6JpNxAyga/qZ/n5iRoxvxo+InnPr47vN7dtZJjGsbMYzAeH/MP1VFGgSNQ8o2n 6nt8xXLnTuJDw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4QkVb55psFz9rxQ; Sun, 18 Jun 2023 13:11:45 +0200 (CEST) From: Ihor Radchenko To: sebastien.miquel@posteo.eu Cc: wolf , emacs-orgmode@gnu.org Subject: Re: [BUG] Source block indentation does not work properly for yaml-mode [9.6.6 ( @ /home/user/.emacs.d/elpa/org-9.6.6/)] In-Reply-To: <8d8642c9-ced3-b254-0f49-f7b9c06311ff@posteo.eu> References: <87ttva8chx.fsf@localhost> <8d8642c9-ced3-b254-0f49-f7b9c06311ff@posteo.eu> Date: Sun, 18 Jun 2023 11:16:40 +0000 Message-ID: <87352p9g13.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.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.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=-1, RCVD_IN_MSPIKE_WL=-0.01, 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-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1687086773; 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=Krn+G1+j+c3F5FHjZCa9FkTUzmPCnlTPqI6h2nrWwew=; b=KM6TFdbZ3HSfve/oIhkAaYl4bX/GACaNl4B3bSK+KprwzLAP/oD6H/WOmAB6GrPtbEm70t S+aghJV3aMNS5DKzWoUXH6CJXl2rogMPzwxKgwJhNDG3K+oXbeS3Sd7NIZXd/ce0jBft/6 Eq0W2WPIodTDg7JP6IOdrWizIsv6zk76JDaQimZbZcnaY9v5vs45V4KkHEIsTx+RD7E2xl rvkt0kdGO0/6bG9CIZFkOgJJD0FK6OkIv9Gi0WHBkFwCaxRy+ddlV/1IkIn+4SLwBRbrGS 48LrjAeU6xR64si3VjgzlYIsB9d/depfv8rSzfLNIasMF637z6jk7SyEQUI+5Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=fuMoYA4w; 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=1687086773; a=rsa-sha256; cv=none; b=P7ZPyF6wajKW4Hk6jFvAMjLZWhT/6VbqtYKSVEAzpIxDL3NL5aT1fJ8M6/S+2g48QM5Ny9 EAt1jungJOdBVJWouDq19tTcAKbVae+9h/GWWKY8DQu0PeJAr18ObV0XcySz6ZyHYNP4tw /nPi7raV/IlMU22QCWesb387VxI6CmDPSCByA0RmpSRo953um/sGUSmpzMmj3FO9ltGOI3 Q+z0WQJJeBCkLysnXGhGAw8lSyn97oyTYmOv3or6HnwMn/7cI/B73sXbDkj9mmzAzABf3k LRPUbbarBCiwAMGQmtmKIHhgbnru9bRq00jSqmmtsh7T1ITjGhs6kPR3YZHQtg== X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -6.21 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=fuMoYA4w; 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: C9BCA141C4 X-Spam-Score: -6.21 X-TUID: a3yyTwQnj9w/ S=C3=A9bastien Miquel writes: > Ihor Radchenko writes: >> Confirmed. >> This is caused by `org-src--contents-for-write-back' not adjusting >> blank line indentation in some cases. > > I don't think that's the issue. In fact, applying your diff didn't > seem to solve the issue on my end. You are right. > To fix the original issue, you can set =3Dindent-tabs-mode=3D to =3Dnil= =3D in > your org files, or possibly set =3Dorg-preserve-indentation=3D to =3Dt=3D > (untested). Sure. Or passing -i switch. But that's wrong, IMHO. Org mode files should be portable. We are aiming for universal Emacs-independent markup. The value of `indent-tabs-mode' must not affect Org markup - third party apps should be able to read src block code without knowledge about Emacs minor modes being active when the Org file is created. And Org files should not be broken for other users with different settings for indent-tabs-mode. > Generally, if you edit the given yaml in a =3DC-c C-'=3D buffer and go > back to the org buffer with the default configuration, spaces will be > converted to tabs, because =3Dindent-tabs-mode=3D is =3Dt=3D in the org b= uffer. > > I don't think there's much that we can do about it. We could try to > read the value of =3Dindent-tabs-mode=3D in the native buffer and preserve > it in the org buffer, but then the org buffer would have mixed > indentation all over, and that's exactly what the current code tries to > avoid. I think that mixed indentation in the Org buffer is fine. In particular, in verbatim-type environments. Let me demonstrate another related problem that manifests more clearly: 1. emacs -Q /tmp/bug.org (new file) 2. C-c C-, s python :results output 3. M-x whitespace-mode 4. if True: 5. if True: 6. print("Yes") 7. Observe tab in front of print("Yes") 8. M-: (require 'ob-python) 9. C-c C-c yes 10. Observe python error File "", line 3 print("yes") TabError: inconsistent use of tabs and spaces in indentation [ Babel evaluation exited with code 1 ]=20=20=20=20 We can, indeed, fix this problem as well by re-indenting the src code body. But that is (1) awkward; (2) will not work if there happen to be a language that actually uses mixed indentation - by converting tabs to spaces we are ultimately using the original info about src body. I feel that we will be getting various edge cases like the original report and like the one I made up above if we keep trying to convert tabs/spaces. Just retaining the original code indentation will be much more robust, IMHO. > - =3Dpreserve-fl=3D is an isolated issue, and only concerns LaTeX > fragments. I will attach a test with the issue it solves with > multiline LaTeX fragments. I think LaTeX fragments are particular > because in the org buffer they do not need to start at the > beginning of a line. > ... "- Item $abc\n efg$" Shouldn't newlines be removed completely before editing the body here? Just like what we do for inline src blocks. See `org-babel--normalize-body'. > Here are three patches attached. > 1. Two tests : about editing LaTeX fragments, and preserving empty > lines. LGTM. > 2. Renaming of =3Dpreserve-blank-line=3D, for clarity. My concern is for `newline-and-indent'. Current line is _previous_ line in such scenario, not the newly inserted line. > 3. Two more tests testing the behaviour of =3Dorg-return=3D and > indentation, with the default configuration. When writing these, I > found the behaviour was buggy in one case, and modified > =3Dorg-indent-line=3D to fix it. Let's discuss indent-tabs-mode first. I do not yet have a clear picture about the best Org behaviour. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at