when ellipsis are "removed", org-cycle doesn't work "correctly" on list

when ellipsis are "removed", org-cycle doesn't work "correctly" on list

[tony aldon]

[-- Attachment #1.1: Type: text/plain, Size: 3934 bytes --]

** 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

[-- Attachment #1.2: Type: text/html, Size: 4733 bytes --]

[-- Attachment #2: 0001-lisp-org-list.el-modify-current-indentation-calculat.patch --]
[-- Type: text/x-patch, Size: 1590 bytes --]

From 06636f4b14b138a3d6ca5366af3b5744f06d9c55 Mon Sep 17 00:00:00 2001
From: tony <tony.aldon.adm@gmail.com>
Date: Thu, 11 Nov 2021 12:00:07 +0100
Subject: [PATCH] lisp/org-list.el: modify current indentation calculation in
 org-list-struct

* lisp/org-list.el (org-list-struct):  Don't use `current-indentation`
  to compute the current indentation in the loop that collects the org
  list informations.

This change is necessary only in the case where 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)
---
 lisp/org-list.el | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/org-list.el b/lisp/org-list.el
index b08e72eb2..025ae0086 100644
--- a/lisp/org-list.el
+++ b/lisp/org-list.el
@@ -684,7 +684,14 @@ Assume point is at an item."
       ;;    position of items in END-LST-2.
       (catch 'exit
 	(while t
-	  (let ((ind (current-indentation)))
+	  (let* ((current-indentation
+                  (save-excursion
+                    (save-match-data
+                      (if (bolp)
+                          (re-search-forward "^[[:blank:]]*")
+                        (re-search-backward "^[[:blank:]]*"))
+                      (- (match-end 0) (point-at-bol)))))
+                 (ind current-indentation))
 	    (cond
 	     ((>= (point) lim-down)
 	      ;; At downward limit: this is de facto the end of the
-- 
2.17.1

[BUG] Re: when ellipsis are "removed", org-cycle doesn't work "correctly" on list

[Ihor Radchenko]

tony aldon <tony.aldon.adm@gmail.com> writes:

> This is my first communication on this mailing list and I hope I'll do
> it well.

Thanks for reporting and welcome to the mailing list!

> 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.

Confirmed

Steps to reproduce:

1. emacs -Q
2. M-x org-mode
3. Insert

- something
  - a
    - b
  - c
- something else

4. M-: (remove-from-invisibility-spec '(outline . t)) <RET>
5. M-: (add-to-invisibility-spec '(outline)) <RET>
6. Move point to "something"
7. <TAB> <TAB> the item is folded but not unfolded

The bug is triggered by incorrect result of org-list-struct.
In org-list-struct with the above invisibility settings,
current-indentation incorrectly returns 0 on "a", "b", and "c" items. I
suspect Emacs bug.

Best,
Ihor

Re: [BUG] Re: when ellipsis are "removed", org-cycle doesn't work "correctly" on list

[Ihor Radchenko]

Ihor Radchenko <yantar92@gmail.com> writes:

> The bug is triggered by incorrect result of org-list-struct.
> In org-list-struct with the above invisibility settings,
> current-indentation incorrectly returns 0 on "a", "b", and "c" items. I
> suspect Emacs bug.

After discussion with Emacs devs [1], I have found where the problem is
coming from. `current-indentation' used by Org parser returns the
_visible_ indentation and has undefined behaviour when the line is
invisible. This undefined behaviour worked in older versions of Emacs,
but not newer.

Fixed.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9db57aee3e86dc47771840d21a19dc2e21e52299

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56837

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>