From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id aJG0BgdqqWU5kgAAe85BDQ:P1 (envelope-from ) for ; Thu, 18 Jan 2024 19:12:23 +0100 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2.migadu.com with LMTPS id aJG0BgdqqWU5kgAAe85BDQ (envelope-from ) for ; Thu, 18 Jan 2024 19:12:23 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qjBFLB4P; 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=1705601543; 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=Yc4wX0leJ6eV+vX/hB8Jz8crHS6b2CUf0vGVhcq7Xa8=; b=hx31vJAXNzYKtFr6C+AZhwkdkEiu8e6xLorpP5h0S5epqsM7UcCmsgWl2EYobB5cYSyEOi sRETPgBRj6B+D9OWck7BO+jXzKqdGHIjjYV1dx7O9pMyoqZx8PiM3hAcwjBP/6wHqp5rqL c/quDjlq2C3IDCm67yqrGlIGgFG41esc8y2FZTZhBUV15TFsfq+lO3All8YeTWKFhs3WaO E3a7vaI+iHoC53xAur4lrprVSvljMqoWNGYWYd11mTyvTNV9Q+43EuTQZ4Df8AfaCdGdNn TPwNXIPIQQc4Bkzl8qhh5XBxH9Ce91SlXCK12UYJsCwUqtVZdNTgdjf9J1cSsQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=qjBFLB4P; 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=1705601543; a=rsa-sha256; cv=none; b=pVH3k7NRGWIirfEkm/HXTlnHzmhxVDi4T2fT71Jp1CSLbxxutoQJKjhyWh4dAqX2td7N4G smtO7rjlt9r8z0zvYNF4aFbX71d9WnxxBTmzERhSkxZXdwWNV+1xNZz5jQZIJ9rYuNbpdK 61Hi4I4P6CXEcfe7BD/4mR7Lj+zf6nHqdDFBZyAmQjCfLyGSA073XSzNLfECJwBD+PFFA6 8LzXyT7YWwR1XiSCtQlQotNCSNGFzKSri7NC6NYNBKwpDryYiES+aC/8pK8Q0oD15TKkF0 AEr4q2J2yOAeI3+qG2KqN8+ZBcZTRAP4wwGCgbGGyGzZUBXn3TFPA741Op1ohQ== 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 99E996C16E for ; Thu, 18 Jan 2024 19:12:22 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rQWrS-000133-KH; Thu, 18 Jan 2024 13:11:30 -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 1rQWrR-00012k-PH for emacs-orgmode@gnu.org; Thu, 18 Jan 2024 13:11:29 -0500 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 1rQWrP-0005Dl-I2 for emacs-orgmode@gnu.org; Thu, 18 Jan 2024 13:11:29 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A9001240104 for ; Thu, 18 Jan 2024 19:11:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1705601483; bh=s2+UWbjS70nB8moagXU4fKMbHVxxAB6SBX/avzpNkVQ=; h=MIME-Version:Content-Type:Content-Transfer-Encoding:Date:From:To: Cc:Subject:Message-ID:From; b=qjBFLB4PliKTlUaaux3Mne5z1M1XbjPzdAf9kifQ5OfL2gy+gJUO3lQeF6JTZF3Pe BWTG/kaZkep9cRy38r/V8+aMKQbSWJC/NGRspbcaVkkDtf1O8VG0aH+OuX8j2OsF6y fpWL6dN3t3cmROwy5HWmDui2rribh3bqhhpf+VOBcx5AN1+k8ZwdYj0bvRnrxFhAbP /PI1vlDwykV1YZ53Vho2U+qnLgS8cGhWQoGcbqRHn5KVHh4+1oSwCjYpmL7Fd/+XnZ 9oHA2dmL8nrLGqDsVEW697aTlvDij/mBEoaOHE3qc8XM+JCJX0TYY3ld4pKPlKEl+6 52yXaCfjnEaaQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TG9mW19bSz6txS; Thu, 18 Jan 2024 19:11:23 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jan 2024 18:11:23 +0000 From: gerard.vermeulen@posteo.net To: sebastien.miquel@posteo.eu Cc: Ihor Radchenko , emacs-orgmode@gnu.org, emacs-orgmode-bounces+gerard.vermeulen=posteo.net@gnu.org Subject: Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers In-Reply-To: References: <878r4makff.fsf@localhost> Message-ID: Received-SPF: pass client-ip=185.67.36.66; envelope-from=gerard.vermeulen@posteo.net; helo=mout02.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: -6.39 X-Migadu-Queue-Id: 99E996C16E X-Spam-Score: -6.39 X-Migadu-Scanner: mx11.migadu.com X-TUID: pKqxynKtLFk0 On 18.01.2024 17:45, S=C3=A9bastien Miquel wrote: > Ihor Radchenko writes: >>> If I recall correctly, in order to fix this, in =3Dorg-indent-line=3D, >>> before calling =3DTAB=3D in the native buffer, one should check the >>> current line indentation and if it is less than =3Dblock-content-ind=3D= , >>> start by adding this much indentation to the current line. >>>=20 >>> This could be a bit fragile, and in particular it assumes that the >>> rest of the block has this =3Dblock-content-ind=3D, which might not be= =20 >>> the >>> case. One could possibly at least check that the first line of the >>> block does have this much indentation. If it doesn't, just do >>> whatever. >> What about a simpler approach - indent the line at point to block's >> expected indentation (if it is not yet there) and then rely upon the >> code block's major mode to do the right thing? >=20 > I cannot think of any common use where the two approches differ, and > it is indeed simpler. The possibility that the block does not have the > common indentation still stands. As far as I understand, the effect also occurs when the block has a common indentation. Below are the steps: With this settings: #+begin_src emacs-lisp -i :results silent (setopt org-adapt-indentation nil org-src-preserve-indentation nil org-edit-src-content-indentation 2) #+end_src And with POINT after "?" and typing ENTER (wait more than 1 second for automatic indenting of 2 spaces), I can type parentheses with some sort of common indentation like below: #+begin_src emacs-lisp ;; common indentation? (()) (()) (()) #+end_src When I place POINT in the middle of the lowest parentheses and type ENTER, then everything moves 2 spaces to the right like below: #+begin_src emacs-lisp ;; common indentation? (()) (()) (( )) #+end_src I think, this is different of what you are saying. Looking at the code, I inferred that I can kill this behavior with the `-i' switch, and that works. Regards -- Gerard