Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/elpa/org-20170210/)]

Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/elpa/org-20170210/)]

[Titus von der Malsburg]

In the example below, when I place the cursor on “Item 2” and then do
(org-end-of-item-list), the cursor is correctly placed at the beginning
of line 4.  However, when I then say (org-in-item-p), I get something
non-nil.  When I move the cursor to the beginning of line 5, I still get
non-nil for (org-in-item-p).  The expected result is nil on line 4 and
5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
obviously not moved us to the end of the list.  I think
(org-end-of-item-list) is doing the right thing but (org-in-item-p)
doesn’t.

#+BEGIN_EXAMPLE
- Item 1

- Item 2


** Some headline
#+END_EXAMPLE

I’m using a recent development version of Emacs and Org-Mode from
MELPA.  Tested with emacs -q.  Until a couple of weeks ago, this problem
didn’t occur.  I can’t pin down when exactly this happened for the first
time.

Emacs  : GNU Emacs 25.0.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
 of 2016-05-14
Package: Org-mode version 8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)

current state:
==============
(setq
 org-tab-first-hook '(org-hide-block-toggle-maybe
		      org-babel-hide-result-toggle-maybe
		      org-babel-header-arg-expand)
 org-speed-command-hook '(org-speed-command-default-hook
			  org-babel-speed-command-hook)
 org-occur-hook '(org-first-headline-recenter)
 org-metaup-hook '(org-babel-load-in-session-maybe)
 org-confirm-shell-link-function 'yes-or-no-p
 org-after-todo-state-change-hook '(org-clock-out-if-current)
 org-src-mode-hook '(org-src-babel-configure-edit-buffer
		     org-src-mode-configure-edit-buffer)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-babel-pre-tangle-hook '(save-buffer)
 org-mode-hook '(#[0 "\300\301\302\303\304$\207"
		   [org-add-hook change-major-mode-hook org-show-block-all
		    append local]
		   5]
		 #[nil "\300\301\302\303\304$\207"
		   [org-add-hook change-major-mode-hook
		    org-babel-show-result-all append local]
		   5]
		 org-babel-result-hide-spec org-babel-hide-all-hashes)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-ctrl-c-ctrl-c-hook '(org-babel-hash-at-point
			  org-babel-execute-safely-maybe)
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-hide-drawers
		  org-cycle-show-empty-lines
		  org-optimize-window-after-visibility-change)
 org-confirm-elisp-link-function 'yes-or-no-p
 org-metadown-hook '(org-babel-pop-to-session-maybe)
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 )

Re: Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/elpa/org-20170210/)]

[Nicolas Goaziou]

Hello,

Titus von der Malsburg <malsburg@posteo.de> writes:

> In the example below, when I place the cursor on “Item 2” and then do
> (org-end-of-item-list), the cursor is correctly placed at the beginning
> of line 4.  However, when I then say (org-in-item-p), I get something
> non-nil.  When I move the cursor to the beginning of line 5, I still get
> non-nil for (org-in-item-p).  The expected result is nil on line 4 and
> 5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
> obviously not moved us to the end of the list.  I think
> (org-end-of-item-list) is doing the right thing but (org-in-item-p)
> doesn’t.

I don't see any bug. Blank lines after a plain list still belong to the
plain list, so `org-in-item-p' is correct.

Indeed, `org-end-of-item-list' moves to the end of the last item instead
of the very end of the list, but I consider it to be a feature, e.g.,
when you need to exchange two items in the list.

You may want to explain what is bothering you in this results. Also,
I suggest to use `org-element-at-point' instead.

Regards,

-- 
Nicolas Goaziou

Re: Bug: Bug: org-in-item-p indicates point is in list when it isn't [8.3.3 (release_8.3.3-529-gfed40e @ /home/malsburg/usr/share/emacs/site-lisp/org/)] [9.0.5 (9.0.5-elpa @ /home/malsburg/.emacs.d/elpa/org-20170210/)]

[Titus von der Malsburg]

On 2017-05-21 Sun 12:57, Nicolas Goaziou wrote:
> Hello,
>
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> In the example below, when I place the cursor on “Item 2” and then do
>> (org-end-of-item-list), the cursor is correctly placed at the beginning
>> of line 4.  However, when I then say (org-in-item-p), I get something
>> non-nil.  When I move the cursor to the beginning of line 5, I still get
>> non-nil for (org-in-item-p).  The expected result is nil on line 4 and
>> 5.  If (org-in-item-p) gives non-nil, (org-end-of-item-list) has
>> obviously not moved us to the end of the list.  I think
>> (org-end-of-item-list) is doing the right thing but (org-in-item-p)
>> doesn’t.
>
> I don't see any bug. Blank lines after a plain list still belong to the
> plain list, so `org-in-item-p' is correct.
>
> Indeed, `org-end-of-item-list' moves to the end of the last item

No, it does not move us to the end of the item.  That’s precisely the
problem.  org-in-item-p returns non-nil even for positions after the point
to which org-end-of-item-list takes us.

> instead
> of the very end of the list, but I consider it to be a feature, e.g.,
> when you need to exchange two items in the list.
>
> You may want to explain what is bothering you in this results.

The documentation of org-end-of-item-list says:

  Go to the end of the current list or sublist.

However, when I call this function and then move the point one line
further down in the example, org-in-item-p still says I’m in the
list.  It logically follows that org-end-of-item-list did not take me to
the end of the list, contrary to what the documentation says.

It may be convenient that org-end-of-item-list doesn’t take us to the
very end of the list (in my use case it’s not), but that behavior is
clearly neither consistent with the name of the function nor with its
documentation.  According to the documentation, org–end-of-item-list
should take us to the last position where org-in-item-p returns
non-nil.  Since it doesn’t, there is a bug, either in the implementation
or in the documentation.

> Also, I suggest to use `org-element-at-point' instead.

Thanks.  In the meantime, I had found org-list-struct which also solves
my problem.

  Titus