From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.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 oHDTKoxf1WKqWwAAbAwnHQ (envelope-from ) for ; Mon, 18 Jul 2022 15:26:36 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YLzWKoxf1WIPSgAAauVa8A (envelope-from ) for ; Mon, 18 Jul 2022 15:26:36 +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 5663B3649F for ; Mon, 18 Jul 2022 15:26:36 +0200 (CEST) Received: from localhost ([::1]:45724 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oDQlf-0002Cx-HA for larch@yhetil.org; Mon, 18 Jul 2022 09:26:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42986) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oDQkT-0002Bu-Li for emacs-orgmode@gnu.org; Mon, 18 Jul 2022 09:25:21 -0400 Received: from mail-pl1-x630.google.com ([2607:f8b0:4864:20::630]:45635) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oDQkR-0005xL-4u for emacs-orgmode@gnu.org; Mon, 18 Jul 2022 09:25:21 -0400 Received: by mail-pl1-x630.google.com with SMTP id w7so8987968ply.12 for ; Mon, 18 Jul 2022 06:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=QbnDke5oaGTmsez0YEw21ESxobfk5ZADXWED+i+Wc7c=; b=FdtfHHOVSOGsmVzOPxSwDJNtMtMWL1GxkeklJDNRZo1DPEIC+KkjPEsQ/WQ8uNwoRd a6HQoFvcCm22gQUeAUaNaWmHrEbtJ5GmHO/DupB9HTjj6Ij/+Q3L8RpQr2V8nKFIJ6+7 4mympUj/ZjJgTHwa/8NCYVets2h36SvSlCd+fHLZHd46y6j0m81hIbBP8Jsw0uSmtqq+ g4ZFpzA/2Tvkup3ykZYz01JPWwy0XpXLcsAQ6IuXVagU8eQqthpWXJ1cQwV4lDGKFpl7 PG1OGLy3QU9DJs9GHmqulwpDRJBt6Dd8Cugu6QuRq5WkphBMzqV1Ey8MhF88pv6JBUXu kFWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=QbnDke5oaGTmsez0YEw21ESxobfk5ZADXWED+i+Wc7c=; b=g631RziubZVNlAAKWB/REJ2wQpQeIvBY1dGQ60nCbryghW++LAhkUgoINBep0c+H+m TMddJP5JAB/zWJBRS40EkBXF6h261zs5zvfve10y96GQh9BVzpUcCUuZWrmxi3oiK0gK LYMWUkrDwQcAwwNkhEA3dio2MkEBU5u9AWswelcppcWIVCQNpXiBLwEAoTQG6b9rueO3 TujjV3zNoD+Lq1B/tL6zz0B38lQN4yQqJlqLCIuH6wrqbE9cSZKLPEL2ckwEkmurskiz SYGCw5sD8KizagBWu5UIY0kEhjNakraKkkh2vHDyXSV82V/KnspA9pMZOAspRRaswX9Y 5URw== X-Gm-Message-State: AJIora+/l/o+39z8fLBjGYxW+Bz2Nhfpo3rmiLfmd/ClMqUN0HJnt3YA 5GTr2w3TUcDfygkcMc6OjE9gGqJpyTpqoQJc X-Google-Smtp-Source: AGRyM1sF3NMJZj+mVbxFKsCfc6dx79M60bv6fqSu3zNmK2n+3VJmgECG1xih32hvncelRc6Ybh6yQw== X-Received: by 2002:a17:902:e88d:b0:16c:d47e:62bb with SMTP id w13-20020a170902e88d00b0016cd47e62bbmr13754520plg.151.1658150717370; Mon, 18 Jul 2022 06:25:17 -0700 (PDT) Received: from localhost ([2409:8a70:2bd:4d0:8ec6:81ff:fe70:339d]) by smtp.gmail.com with ESMTPSA id qe10-20020a17090b4f8a00b001ecd954f3b6sm11577314pjb.7.2022.07.18.06.25.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 18 Jul 2022 06:25:16 -0700 (PDT) From: Ihor Radchenko To: Valentin Lab Cc: emacs-orgmode@gnu.org Subject: Re: [feature] Consistent fixed indentation of headline data In-Reply-To: References: <2fcae365-97cf-ccc4-23f0-2fc5c110dd69@kalysto.org> <87v8s9urvg.fsf@localhost> Date: Mon, 18 Jul 2022 21:26:19 +0800 Message-ID: <87cze2h7r8.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::630; envelope-from=yantar92@gmail.com; helo=mail-pl1-x630.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1658150796; 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=QbnDke5oaGTmsez0YEw21ESxobfk5ZADXWED+i+Wc7c=; b=DKkIEOsOfdM/q4gFdq4jbxeY4OqafjbUSYcgDLOyy+yjzrRghoq+48TRgb5YLFPfCA79N1 /D32eEJnHPy+wlWgxWCncjetuRyoYpp74QvkIX+SX1wPq+sdhxug75PCqbGfzGJF8HGLU7 21/r2eg1ke85WKmb507+atvY5WQz9LPCaz8PjISSfqGkx75DwTuAjEa31ASaRQRbtzPV4q VxSv4d1QDsFN3TnVPKEXFzNR0HzkPwysP4iQLPAZ9pt1Wqah016T/Gdj9d2tccxXTuct1Q +W8jVPyXrw+gK00Gp/xyUkTmlzqLygwHZ8c5Nyr25bBxHGnV91KRvKwyAynhIA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1658150796; a=rsa-sha256; cv=none; b=ZoB+w9qbn4jJGLHIqfKtadRzXGa0vp5L67lBLyK2QKqoHBLthpGKnptoO/fgfakn9dlowy NRx61DSF5u4dGQomcEzhPQUyggASQnL2NMy8e1rSZ9rn62UPACnD764+9atHVvvXNuTla6 kwghTAL6L3DbcQxjeRAz28Ppty7rC/tMRz0n4NH7do+lj++fwmBSiXlPLJodgXbSG4JGUA 9YN1ppUmxA4gRdaCe99rYXLjkZW6Ik+I7FhUVkSr6TBEJs54lDpm7xe2aELYxjvjuBltCN fYowc2x6xaYIyBrn/W03+v9ajWqUjkZRqcoo5I4IM51JT+4Oiv8mLrgk4SERiw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=FdtfHHOV; dmarc=pass (policy=none) header.from=gmail.com; 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=gmail.com header.s=20210112 header.b=FdtfHHOV; dmarc=pass (policy=none) header.from=gmail.com; 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: 5663B3649F X-Spam-Score: -3.43 X-Migadu-Scanner: scn1.migadu.com X-TUID: obD4/7hTceBH Valentin Lab writes: >> Also, I am not sure if we really need a new custom variable. We already >> have many. What about simply allowing an integer value of >> org-adapt-indentation? >> > > Well, my guess was that the "adapt" word in `org-adapt-indentation' was > referring to adaptive (in other words: "changing") indentation depending > on the depth of the outline. It seemed at first un-natural to force a > fixed behavior here. This is why I went with a sub-behavior of when > `org-adapt-indentation' was set to nil, a way to tell that we didn't > want adaptive indentation. It also had the advantage to separate the > implementation and help writing code that would not break the existing > behaviors. > > Of course, I'm completely okay to go with your suggestion. Although, I'm > at a lack of inspiration about what would be the best option here: > wouldn't a simple integer as you suggest hide the fact that this will > target only the headline data ? Could we think of more structured value, > perhaps like a cons =(`headline-data . 2)= ? I'm afraid these additions > could be seen as bringing some unwanted complexity. > > Although I'm expressing some doubts, I'm ready to implement it using an > integer on `org-adapt-indentation' as you suggest. Just wanted to make > sure it seem sound to everyone before committing to a change that is not > that trivial (well, compared to actual changes). Your doubts make sense. In fact, I somehow missed that you only offered to indent the headline data to fixed indentation. Now, after more thinking and thoughtfully reading the relevant code, I find a new variable more reasonable. However, I do not think that the new variable should be `org-headline-data-fixed-indent-level'. Instead, we can offer something like `org-indent-level' with default value 'auto referring to (1+ (org-current-level)) and possible value of integer - what you propose. Then, org-adapt-indentation will control the indentation as usual, but the actual indentation will be calculated depending on the `org-indent-level' value. As an added bonus, users will also be able to set fixed indentation using the combination of org-adapt-indentation=t and org-indent-level=some-number. Not that I find it useful, but it will be consistent. Moreover, the implementation will be nothing but changing the calculation of headline contents indentation from (1+ (org-current-level)) to a slightly more complex branching. >> Note that your patch is _not_ a tiny change (not <15 LOC). >> See https://orgmode.org/worg/org-contribute.html#first-patch and >> https://orgmode.org/worg/org-contribute.html#copyright >> Would you consider signing the copyright assignment papers with FSF? > > Ok, I was not sure about that (counting the actual functional code > change was still under 15LOC, but I guess test counts also). I'm in the > process of signing the copyright assignment papers. Note that FSF should reply within 5 working days. If they don't, let us know. >>> @@ -18371,6 +18386,9 @@ ELEMENT." >>> ;; a footnote definition. >>> (org--get-expected-indentation >>> (org-element-property :parent previous) t)))))))))) >>> + ((and (not (eq org-headline-data-fixed-indent-level nil)) >>> + (memq type '(drawer property-drawer planning node-property clock))) >>> + org-headline-data-fixed-indent-level) >>> ;; Otherwise, move to the first non-blank line above. >> >> Why clock? It does not belong to property drawers. >> > > I probably lack some important knowledge here to understand your point. > Here's what I understand: `clock' type targets the 'CLOCK:' keyword (and > not direct timestamps, I added a test to make sure). AFAIK, these > 'CLOCK:' lines are made with 'C-c C-x C-i/o' and usually appears in > between a ':LOGBOOK:' drawer. However older implementation of org-mode > did not include these 'CLOCK: ...' lines in logbook drawers. My > intention here, was to make sure that even these orphaned 'CLOCK: ...' > lines, when appearing before any content, would be considered as > headline data, and as such, be indented by the fixed amount. > > I definitively consider the logbook (and clock out of logbooks), > property drawer, and planning info ("SCHEDULED", "DEADLINE") as headline > data and are all targeted for indentation. In my code, if I remove > `clock' in the list of types, the intended test about 'CLOCK:' fails... AFAIU, the correct test is the one used inside org-indent-line: (and (eq org-adapt-indentation 'headline-data) (not (or (org-at-clock-log-p) (org-at-planning-p))) (save-excursion (beginning-of-line 1) (skip-chars-backward "\n") (or (org-at-heading-p) (looking-back ":END:.*" (point-at-bol))))) (inverse of) Best, Ihor