From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AMpCIOYrjWERvwAAgWs5BA (envelope-from ) for ; Thu, 11 Nov 2021 15:42:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id YKALHOYrjWF9HAAA1q6Kng (envelope-from ) for ; Thu, 11 Nov 2021 14:42:46 +0000 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 B0CD818B0D for ; Thu, 11 Nov 2021 15:42:45 +0100 (CET) Received: from localhost ([::1]:55086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mlBHo-00063j-7f for larch@yhetil.org; Thu, 11 Nov 2021 09:42:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44524) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mlB8V-0007AN-3V for emacs-orgmode@gnu.org; Thu, 11 Nov 2021 09:33:07 -0500 Received: from [2a00:1450:4864:20::12e] (port=43640 helo=mail-lf1-x12e.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mlB8S-0000os-RX for emacs-orgmode@gnu.org; Thu, 11 Nov 2021 09:33:06 -0500 Received: by mail-lf1-x12e.google.com with SMTP id b40so14630211lfv.10 for ; Thu, 11 Nov 2021 06:33:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=vvyJG7NaSmPmV9jymPgJ4MoMTU0HcnBE1x5Iyf+vyRI=; b=YhFvVokd9XCQ+eTC+OH6j6s5NgjUsGBX2UbcfsqQBbr2c5JXf6yTmKFT30YW4KHP8+ s7ZWiesKaIJnMf7ARF1ERz2jSEcHwscXq+B9M8bH7Qv5jH+v0XkG+hiKm9NDBvVazXUL H/JYHDjQxhjIlA70eyfoOoW3HjfMoQeV14Ooh/zfw+VkwSLcM/yVQna5CZsJjxmWb+Ej LNqLFE4Htb0MM+aUM9u+cnjg+zza3vNa+Wafu2VKz6Zx3e3QIuXIXeg4bm7pS8L+DoXG /5Fm2a6qBuUZjZWCLq+w5bdmHrVObtiuK3/rgN2P7sT5PDt4uh76i+J7LTLbZG3oVU7u alDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vvyJG7NaSmPmV9jymPgJ4MoMTU0HcnBE1x5Iyf+vyRI=; b=xKgSoXwzucAYBnzDDpxTQok/bZS0i0NEMcYaCnQz480eFUk9aUHZsYzovybLKdPqfL nLP1eSL7nU5xV9MeMKOWhddNebck7EaTzBDchG8OfrxQICjT6/egJBUoDBXk9D2hjZ4C q0f5rviOZ1FwHYyeoqyGqnCeyEeL2QsOnLQc8JPuYmugUiehfK50Hli00QAWIxMs5oG0 Ms40i0Dpfh5QGk7QdAOX6w/SrJ/pv5NyFIDPf0KRC2iKqsQLCNdOmkf9htmEmVL+0TDL /TTV5cOMfZBgyMfW7USbN2cgN9Yws+tecOxdCBmfWe7UcnA8aikdw9kATPHzQRkIO1kO nDyQ== X-Gm-Message-State: AOAM530K9GBTfjdlVwbwVXmhGMBEwrDEWNPc1p2mmk/EeRkC5tQVRWkX rzOd4eF0sznCOkCbH0XCua44JcMX7ltGui3Tu7pFaQgwJ8VM5g== X-Google-Smtp-Source: ABdhPJx8c5GSG/LgIse/kjsmWrVzfW3YwkPzoiakIo4Hdi+5WrP0IP6dB16GHnCjbl5mFY3ZQxof+I8OGKxwuSD2R3k= X-Received: by 2002:ac2:4bc1:: with SMTP id o1mr7203411lfq.520.1636640682508; Thu, 11 Nov 2021 06:24:42 -0800 (PST) MIME-Version: 1.0 From: tony aldon Date: Thu, 11 Nov 2021 15:24:31 +0100 Message-ID: Subject: when ellipsis are "removed", org-cycle doesn't work "correctly" on list To: emacs-orgmode@gnu.org Content-Type: multipart/mixed; boundary="00000000000081ab0e05d0841a69" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::12e (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::12e; envelope-from=tony.aldon.adm@gmail.com; helo=mail-lf1-x12e.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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_FROM=0.001, HTML_MESSAGE=0.001, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1636641765; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=sWfFFocx0YzjyMvdp6P66MyTi9UpUn/VuroikMxyvts=; b=anYyBDq85yEO1LgOnX7fMpFaI0L0OPj0c79HEdIilfXJOtoDNgWZDZtF9+7EV0ujU5Zxbf kVDj4fGw4lakrDqc9NhVsIusNes0ott2qO/ddfgTlEUHUhtmvUWmT7z5LTzvhF8bDo0GP/ 14BxFCHG0H/gPVcw+k2oZaJGIXi7wWWwONpztfD0+kr2FofQHrD/+ZoJrG+bbPiAYlNkHo VGN5yMrnCCTZeAE/zpoDXvzgNbZLyPjUcDxgzQdP2kCVx5ZHGPI2SATEly6dcvlKaAZKu8 8RVj7cJPSalm3xLDXsGZUfrZLvZQPPXMLx8ZyrfXsBKoSxLEEL8lKEZ/Siw/sg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1636641765; a=rsa-sha256; cv=none; b=mWy+iVnZuVe2P0uQQpm2iYPEd/gJxV8V92JnHgX7TNn1BoapNVYhHfdVqXRCoYiVhS130+ Gensqi3ni9U8UmhaGyDydMxJyHBcpH6GoiDuHBJGjRVQzq7h08Q98+/Tf72/A3SdKrBHn8 el8SvbnSGZQ5WAQc+L8jfYM+RLopnJ8xpgi/9eiIq1YqRIF+7SfVTU3PXa6T2GLVILqyx7 JNOWuWmFX+XUktDvR+zfmMzum6zuGDdtMe6VfRjYcZFG7On8KXqQ6OJcTG8OgYtVpG2ZZa qyFA48+cajkkNLuTcjJD2bf6WYTYFqe+WT0oe01IidzDph3390337snzanGutA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20210112 header.b=YhFvVokd; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Spam-Score: -0.63 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20210112 header.b=YhFvVokd; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Migadu-Queue-Id: B0CD818B0D X-Spam-Score: -0.63 X-Migadu-Scanner: scn1.migadu.com X-TUID: 0rLsw5KFL8Tz --00000000000081ab0e05d0841a69 Content-Type: multipart/alternative; boundary="00000000000081ab0c05d0841a67" --00000000000081ab0c05d0841a67 Content-Type: text/plain; charset="UTF-8" ** when ellipsis are "removed", org-cycle doesn't work "correctly" on list Hey everyone, This is my first communication on this mailing list and I hope I'll do it well. 1) The "bug" (I'm not sure if it is a bug): When you modify the `buffer-invisibility-spec` replacing `'(outline . t)` by `'outline` (in order to remove the `...` when headlines, list, etc are collapsed) by evaluating the following form: (remove-from-invisibility-spec '(outline . t)) (add-to-invisibility-spec 'outline) `org-cycle` stopped working "correctly" on lists. You still can collapse lists but you can get them to show the list content again. For instance, with the following list (and the ellipsis removed), with the point on the first item (- something), press TAB (`org-cycle`): - something - a - b - c - something else You'll obtain the first item collapsed: - something - something else but if you hit TAB (`org-cycle`) again, you won't see the content (a, b, c), the first item will stay collapsed. note-1: I don't know if it can be considered as a "bug" because I imagine that most org-mode users won't remove the visual feedback offered by the ellipsis. note-2: This "bug" was reported as an issue on github (https://github.com/tonyaldon/org-bars/issues/5) by jonathanmfung, regarding a section on the README where I wrote how to remove the ellipsis, knowing that `org-bars` offers dynamic stars that inform the visibility of subtrees. Maybe it wasn't a good idea. 2) a fix of the "bug" I was really interested in knowing why changing the `buffer-invisibility-spec` in the way previously described has an impact on `org-cycle`. I added a small patch (that modifies `org-list-struct`) to this email that makes `org-cycle` work with `buffer-invisibility-spec` changed in order to remove ellipsis. The outline of the patch is as follow: The command `org-cycle`, when in an item list, calls `org-cycle-internal-local`. And `org-cycle-internal-local` computes the local var `eos` (end of subtree or item) via the call of the function `org-list-struct`. (defun org-cycle-internal-local () ;;... (let ((goal-column 0) eoh eol eos has-children children-skipped struct) (save-excursion (if (org-at-item-p) (progn (beginning-of-line) (setq struct (org-list-struct)) (setq eoh (point-at-eol)) (setq eos (org-list-get-item-end-before-blank (point) struct)) (setq has-children (org-list-has-child-p (point) struct))) ;; ... ) ;;... ))) And the problem comes from the use of the function `current-indentation` in `org-list-struct` that doesn't compute correctly in that context the indentation when ellipsis are removed. The patch replaces this specific call of `current-indentation`. note-3: I don't understand why the function `current-indentation` doesn't compute "correctly" the indentation in that context. note-4: In a default org buffer, with the items either collapsed or not, with the following content and point on the first item, - [X] first item 1. sub-item 1 5. [@5] sub-item 2 some other text belonging to first item - last item + tag :: description evaluating `(org-list-struct)` gives the following structure (as written in the docstring): ((1 0 \"- \" nil \"[X]\" nil 97) (18 2 \"1. \" nil nil nil 34) (34 2 \"5. \" \"5\" nil nil 55) (97 0 \"- \" nil nil nil 131) (109 2 \"+ \" nil nil \"tag\" 131)) But if you removed the ellipsis (as specified previously), and you collapse the first item, evaluating `(org-list-struct)` with point on the first item gives you: ((1 0 "- " nil "[X]" nil 18) (18 0 "1. " nil nil nil 34) (34 0 "5. " "5" nil nil 55)) 3) Thank you for all your work on org-mode, I enjoy using it every day :) Have a nice day, Tony Aldon Done with: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.30, cairo version 1.15.10) of 2021-06-09 --00000000000081ab0c05d0841a67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
** when ellipsis are "removed", org-cycle doesn&= #39;t work "correctly" on list

Hey everyone,

This i= s my first communication on this mailing list and I hope I'll do
it = well.

1) The "bug" (I'm not sure if it is a bug):
<= br>When you modify the `buffer-invisibility-spec` replacing
`'(outli= ne . t)` by `'outline` (in order to remove the `...` when
headlines,= list, etc are collapsed) by evaluating the following form:

(remove-= from-invisibility-spec '(outline . t))
(add-to-invisibility-spec = 9;outline)

`org-cycle` stopped working "correctly" on list= s.

You still can collapse lists but you can get them to show the lis= t
content again.

For instance, with the following list (and the e= llipsis removed), with
the point on the first item (- something), press = TAB (`org-cycle`):

- something
=C2=A0 - a
=C2=A0 =C2=A0 - b=C2=A0 - c
- something else

You'll obtain the first item col= lapsed:

- something
- something else

but if you hit TAB (`= org-cycle`) again, you won't see the content (a,
b, c), the first it= em will stay collapsed.

note-1: I don't know if it can be consid= ered as a "bug" because I
imagine that most org-mode users won= 't remove the visual feedback
offered by the ellipsis.

note-2= : This "bug" was reported as an issue on github
(https://github.com/tonyaldon/= org-bars/issues/5) by jonathanmfung,
regarding a section on the READ= ME where I wrote how to remove the
ellipsis, knowing that `org-bars` off= ers dynamic stars that inform
the visibility of subtrees.=C2=A0 Maybe it= wasn't a good idea.

2) a fix of the "bug"

I wa= s really interested in knowing why changing the
`buffer-invisibility-spe= c` in the way previously described has an
impact on `org-cycle`.

= I added a small patch (that modifies `org-list-struct`) to this email
th= at makes `org-cycle` work with `buffer-invisibility-spec` changed
in ord= er to remove ellipsis.

The outline of the patch is as follow:
The command `org-cycle`, when in an item list, calls
`org-cycle-interna= l-local`.=C2=A0 And `org-cycle-internal-local` computes
the local var `e= os` (end of subtree or item) via the call of the
function `org-list-stru= ct`.

(defun org-cycle-internal-local ()
=C2=A0 ;;...
=C2=A0 (l= et ((goal-column 0) eoh eol eos has-children children-skipped struct)
= =C2=A0 =C2=A0 (save-excursion
=C2=A0 =C2=A0 =C2=A0 (if (org-at-item-p)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (progn
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 (beginning-of-line)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (setq struct (org-list-struct))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 (setq eoh (point-at-eol))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 (setq eos (org-list-get-item-end-before-blank (point) struct))
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (setq has-children (org-list-has-chi= ld-p (point) struct)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; ...
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 ;;...
=C2=A0 =C2=A0 =C2=A0 )= ))


And the problem comes from the use of the function
`curren= t-indentation` in `org-list-struct` that doesn't compute
correctly i= n that context the indentation when ellipsis are removed.

The patch = replaces this specific call of `current-indentation`.

note-3: I don&= #39;t understand why the function `current-indentation`
doesn't comp= ute "correctly" the indentation in that context.

note-4: I= n a default org buffer, with the items either collapsed or
not, with the= following content and point on the first item,

- [X] first item
= =C2=A0 1. sub-item 1
=C2=A0 5. [@5] sub-item 2
=C2=A0 some other text= belonging to first item
- last item
=C2=A0 + tag :: description
<= br>evaluating `(org-list-struct)` gives the following structure (as
writ= ten in the docstring):

((1 0 \"- \" =C2=A0nil \"[X]\&= quot; nil 97)
=C2=A0 (18 2 \"1. \" =C2=A0nil nil nil 34)
= =C2=A0 (34 2 \"5. \" \"5\" nil nil 55)
=C2=A0 (97 0 = \"- \" =C2=A0nil nil nil 131)
=C2=A0 (109 2 \"+ \" n= il nil \"tag\" 131))

But if you removed the ellipsis (as s= pecified previously), and you
collapse the first item, evaluating `(org-= list-struct)` with point on
the first item gives you:

((1 0 "= ;- " nil "[X]" nil 18) (18 0 "1. " nil nil nil 34)= (34 0 "5. " "5" nil nil 55))

3) Thank you for a= ll your work on org-mode, I enjoy using it every day :)


Have a n= ice day,
Tony Aldon

Done with: GNU Emacs 28.0.50 (build 1, x86_64= -pc-linux-gnu, GTK+
Version 3.22.30, cairo version 1.15.10) of 2021-06-0= 9
--00000000000081ab0c05d0841a67-- --00000000000081ab0e05d0841a69 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-lisp-org-list.el-modify-current-indentation-calculat.patch" Content-Disposition: attachment; filename="0001-lisp-org-list.el-modify-current-indentation-calculat.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kvv1l0rv0 RnJvbSAwNjYzNmY0YjE0YjEzOGEzZDZjYTUzNjZhZjNiNTc0NGYwNmQ5YzU1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiB0b255IDx0b255LmFsZG9uLmFkbUBnbWFpbC5jb20+CkRhdGU6 IFRodSwgMTEgTm92IDIwMjEgMTI6MDA6MDcgKzAxMDAKU3ViamVjdDogW1BBVENIXSBsaXNwL29y Zy1saXN0LmVsOiBtb2RpZnkgY3VycmVudCBpbmRlbnRhdGlvbiBjYWxjdWxhdGlvbiBpbgogb3Jn LWxpc3Qtc3RydWN0CgoqIGxpc3Avb3JnLWxpc3QuZWwgKG9yZy1saXN0LXN0cnVjdCk6ICBEb24n dCB1c2UgYGN1cnJlbnQtaW5kZW50YXRpb25gCiAgdG8gY29tcHV0ZSB0aGUgY3VycmVudCBpbmRl bnRhdGlvbiBpbiB0aGUgbG9vcCB0aGF0IGNvbGxlY3RzIHRoZSBvcmcKICBsaXN0IGluZm9ybWF0 aW9ucy4KClRoaXMgY2hhbmdlIGlzIG5lY2Vzc2FyeSBvbmx5IGluIHRoZSBjYXNlIHdoZXJlIHlv dSBtb2RpZnkgdGhlCmBidWZmZXItaW52aXNpYmlsaXR5LXNwZWNgIHJlcGxhY2luZyBgJyhvdXRs aW5lIC4gdClgIGJ5CmAnb3V0bGluZWAgKGluIG9yZGVyIHRvIHJlbW92ZSB0aGUgYC4uLmAgd2hl biBoZWFkbGluZXMsIGxpc3QsIGV0YyBhcmUKY29sbGFwc2VkKSBieSBldmFsdWF0aW5nIHRoZSBm b2xsb3dpbmcgZm9ybToKCihyZW1vdmUtZnJvbS1pbnZpc2liaWxpdHktc3BlYyAnKG91dGxpbmUg LiB0KSkKKGFkZC10by1pbnZpc2liaWxpdHktc3BlYyAnb3V0bGluZSkKLS0tCiBsaXNwL29yZy1s aXN0LmVsIHwgOSArKysrKysrKy0KIDEgZmlsZSBjaGFuZ2VkLCA4IGluc2VydGlvbnMoKyksIDEg ZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9saXNwL29yZy1saXN0LmVsIGIvbGlzcC9vcmctbGlz dC5lbAppbmRleCBiMDhlNzJlYjIuLjAyNWFlMDA4NiAxMDA2NDQKLS0tIGEvbGlzcC9vcmctbGlz dC5lbAorKysgYi9saXNwL29yZy1saXN0LmVsCkBAIC02ODQsNyArNjg0LDE0IEBAIEFzc3VtZSBw b2ludCBpcyBhdCBhbiBpdGVtLiIKICAgICAgIDs7ICAgIHBvc2l0aW9uIG9mIGl0ZW1zIGluIEVO RC1MU1QtMi4KICAgICAgIChjYXRjaCAnZXhpdAogCSh3aGlsZSB0Ci0JICAobGV0ICgoaW5kIChj dXJyZW50LWluZGVudGF0aW9uKSkpCisJICAobGV0KiAoKGN1cnJlbnQtaW5kZW50YXRpb24KKyAg ICAgICAgICAgICAgICAgIChzYXZlLWV4Y3Vyc2lvbgorICAgICAgICAgICAgICAgICAgICAoc2F2 ZS1tYXRjaC1kYXRhCisgICAgICAgICAgICAgICAgICAgICAgKGlmIChib2xwKQorICAgICAgICAg ICAgICAgICAgICAgICAgICAocmUtc2VhcmNoLWZvcndhcmQgIl5bWzpibGFuazpdXSoiKQorICAg ICAgICAgICAgICAgICAgICAgICAgKHJlLXNlYXJjaC1iYWNrd2FyZCAiXltbOmJsYW5rOl1dKiIp KQorICAgICAgICAgICAgICAgICAgICAgICgtIChtYXRjaC1lbmQgMCkgKHBvaW50LWF0LWJvbCkp KSkpCisgICAgICAgICAgICAgICAgIChpbmQgY3VycmVudC1pbmRlbnRhdGlvbikpCiAJICAgIChj b25kCiAJICAgICAoKD49IChwb2ludCkgbGltLWRvd24pCiAJICAgICAgOzsgQXQgZG93bndhcmQg bGltaXQ6IHRoaXMgaXMgZGUgZmFjdG8gdGhlIGVuZCBvZiB0aGUKLS0gCjIuMTcuMQoK --00000000000081ab0e05d0841a69--