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