From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms8.migadu.com with LMTPS id CFP1J3J89WUODAAA62LTzQ:P1 (envelope-from ) for ; Sat, 16 Mar 2024 12:03:14 +0100 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id CFP1J3J89WUODAAA62LTzQ (envelope-from ) for ; Sat, 16 Mar 2024 12:03:14 +0100 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VHNHycmx; 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=1710586994; 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=TTwsJenCGcpyH9rOi8ICstDVExKUXQimYDAPOScAKIU=; b=ui/cv94EZ6OKXw3n3LXE3xX0cWOR9HXxnr92Du7Lu7pl/Nh7lZ3NeNj/LLvkP8g0mgNflV Tje+4fTgaob5ahMO/5FobwBVvk4T0deF46pcc5cu4gbWZLYBtjXfajhb+GuGeE7/MEh0HU o/COc8huHeJwKDiheWT2LbPqHUfsSdVoH+8/xKN5ToI15E05J4lFYrcMoIZU324Uu+SK0C uYVDW7hLYoMFs4dqD06XugJZc8vkgc6ANeZ7LSUZB+5kn8dD0Doo/UL4GkaBEPcLs1ADmz gNpg6y6vCT3i0soEE6n/Op37/LwUD+nVJmphwMRU+vGPpbx9pq7udFFM3wlQ5w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=VHNHycmx; 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=1710586994; a=rsa-sha256; cv=none; b=DLaJ6hYbruBxqgvH+zqJdEH+iu6LOG9VThnxHKZWPcTgxj+FAlRdzX/R/VL53m+NlSWBQ+ 4TxdBs8RlkKyZDrZ8Tlu26fM50ekU8dukD6VjR98h4Y97DCOsRd/7HQ2X3mgCGv9cA1TFU zB4GP8/YieFU85N1Zsk1OtCBeh0al/lCBCmDDEERGNxI8twaus16wI6W1esVQBhT+FfOz+ 6uIg/DLNMEX0I9ZmbwaSYsrGw28LXs9P/P6UMcFO9ui/7d60kkThLmV/0zbLQeTsm1j23Q vuUkRREZln8GtrpfXnjLZejcR17jAqLqXh5SJj0857P/BIBvhcjAMMbpDFXkoA== 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 616FC1611D for ; Sat, 16 Mar 2024 12:03:14 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rlRnw-0008Sn-Ey; Sat, 16 Mar 2024 07:02:20 -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 1rlRns-0008Sb-Qw for emacs-orgmode@gnu.org; Sat, 16 Mar 2024 07:02:17 -0400 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 1rlRnp-0006mi-Ni for emacs-orgmode@gnu.org; Sat, 16 Mar 2024 07:02:16 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id BCD53240028 for ; Sat, 16 Mar 2024 12:02:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1710586930; bh=bJeZ6EoYy1BPV5XP0pH7+Rw9OhjftgWVj95X+Twi9LE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=VHNHycmxPkq5gn4CoI4wazyZk6RTNLc55vKgQUs+5R6PdjHgMxcwfBap2Y/xSQmOJ 2tFDz0kjOwn+uiGFCX3iGnfviaqdqfQ+6UGA/03fdQdTp7Ewcf99C4q6PQS1lZ9dj6 8KNG3O3skzGCUT/nohVGlKENIzamF10YfML6GFQO+JprG94a41cuO+ibpByULKkiNk VJ6/xxzBFnbdUI63IKtUJFKCyCF3+zvCWG6KaoSYLl7lZQ0kRaCkA34hwc5qXLt3E8 hp+MMMP45Vjk23A+2D12I98uc0IBFHrEbirBfhTwrT601sZskZMZC9ZQjejnGt2rOA CK/DWe2bewr2g== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4TxdVV00Rsz6tm8; Sat, 16 Mar 2024 12:02:09 +0100 (CET) From: Ihor Radchenko To: Rudi C Cc: emacs-orgmode@gnu.org Subject: Re: Forcing tab-width to be 8 makes using Python source blocks very difficult In-Reply-To: References: <871q8ajyxq.fsf@localhost> Date: Sat, 16 Mar 2024 11:02:06 +0000 Message-ID: <87jzm2ignl.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, RCVD_IN_MSPIKE_H3=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: -9.49 X-Spam-Score: -9.49 X-Migadu-Queue-Id: 616FC1611D X-Migadu-Scanner: mx13.migadu.com X-TUID: MA32f6lsYeOB Rudi C writes: > ... runs `evil-shift-right`, which > indents the selected region by the `evil-shift-width` amount. > `evil-shift-width` is set based on `tab-width`. Are you sure? I am looking at https://github.com/emacs-evil/evil/blob/master/evil-vars.el#L175 and it appears that `evil-shift-width' has nothing to do with `tab-width'. It is a customization with default value of 4. Also, do note that `evil-shift-width' in python code blocks may break things when the code block itself is also indented. Org mode normally discards this common indentation and takes care about distinguishing (and not merging!) the tabs belonging to the code itself and the tabs/spaces that are used to indent the whole code block: This whole code block is indented #+begin_src python def foo(): if True: return 1; #+end_src Indentation in Org mode blocks can be tricky and generic editing commands may not cut it. Org mode itself does the indentation using the code block's major mode in a separate buffer in order to keep things consistent. > ... I solved this specific > problem by overriding `evil-shift-width` using a timer in an org-mode hook. > The delay introduced by the timer was necessary, as something kept > overriding my settings. Perhaps the magic machinery that sets `tab-width` > in the source blocks can also set `evil-shift-width`. The best-case > scenario would be to have a list of variables that need to be set from > their major-mode buffer in the source blocks. Why not simply setting `evil-shift-width' to 4? >> May you please provide a detailed example where 8 spaces causes issues? > > My lists are still indenting with 2 spaces, so I am not actually seeing 8 > spaces. I have no idea why that is, but I very much like the 2-space > indentation. > > ``` > - a > - b > ``` > > I see 4 spaces in numerical lists, which again, I have no idea about: > > ``` > 1. hi > 2. hi > 3. hi > ``` Org mode aligns child sub-lists with parent item text. So, "-" is right below "a" and "2." is right below "hi". List depth is not defined by the absolute number of spaces/tabs. See https://orgmode.org/manual/Plain-Lists.html -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at