[bug] select TODO items and unexpected behaviour

[bug] select TODO items and unexpected behaviour

[Mario Frasca]

when I select subsequent TODO items, whole lines, and I do M-<right>, 
they get demoted by one star, so something like

* header
<point>* a1
* a2
* a3
<mark>* header

after I hit M-<right> will become

* header
<point>** a1
** a2
** a3
<mark>* header

which is what I expected, even if I would not expect the region to be 
deactivated.

but if I now reactivate the region, andhit S-<right> (that's 
shift-right), the effect is only at the <point>, not on the selection:

* header
<point>** TODO a1
** a2
** a3
<mark>* header

I would have expected all lines to get the TODO.Same effect, if I hit 
C-c C-t: only the line at the point gets the TODO status rotated.

looks like a bug to me, but I would not know where to start looking for 
how to fix this.

Mario

Re: [bug] select TODO items and unexpected behaviour

[Mario Frasca]

this behaviour comes after somehow my 
`org-loop-over-headlines-in-active-region' became nil.

if I set it back to t, I get the message "Symbol's value as variable is 
void: right".

I had enabled debugging, and my guess is that this might have left the 
value of `org-loop-over-headlines-in-active-region' at the 
"inside-looping" setting.  just guessing.

On 27/06/2020 16:16, Mario Frasca wrote:
> when I select subsequent TODO items, whole lines, and I do M-<right>, 
> they get demoted by one star, so something like
>
> * header
> <point>* a1
> * a2
> * a3
> <mark>* header
>
> after I hit M-<right> will become
>
> * header
> <point>** a1
> ** a2
> ** a3
> <mark>* header
>
> which is what I expected, even if I would not expect the region to be 
> deactivated.
>
> but if I now reactivate the region, andhit S-<right> (that's 
> shift-right), the effect is only at the <point>, not on the selection:
>
> * header
> <point>** TODO a1
> ** a2
> ** a3
> <mark>* header
>
> I would have expected all lines to get the TODO.Same effect, if I hit 
> C-c C-t: only the line at the point gets the TODO status rotated.
>
> looks like a bug to me, but I would not know where to start looking 
> for how to fix this.
>
> Mario
>

Re: [bug] select TODO items and unexpected behaviour

[Mario Frasca]

if I change those 'right and 'left, to :right and :left, the handling 
them over and over as symbols will not start confusing them as 
variables, and keep them as symbols.

On 27/06/2020 16:43, Mario Frasca wrote:
> this behaviour comes after somehow my 
> `org-loop-over-headlines-in-active-region' became nil.
>
> if I set it back to t, I get the message "Symbol's value as variable 
> is void: right".
>
> I had enabled debugging, and my guess is that this might have left the 
> value of `org-loop-over-headlines-in-active-region' at the 
> "inside-looping" setting.  just guessing.
>
> On 27/06/2020 16:16, Mario Frasca wrote:
>> when I select subsequent TODO items, whole lines, and I do M-<right>, 
>> they get demoted by one star, so something like
>>
>> * header
>> <point>* a1
>> * a2
>> * a3
>> <mark>* header
>>
>> after I hit M-<right> will become
>>
>> * header
>> <point>** a1
>> ** a2
>> ** a3
>> <mark>* header
>>
>> which is what I expected, even if I would not expect the region to be 
>> deactivated.
>>
>> but if I now reactivate the region, andhit S-<right> (that's 
>> shift-right), the effect is only at the <point>, not on the selection:
>>
>> * header
>> <point>** TODO a1
>> ** a2
>> ** a3
>> <mark>* header
>>
>> I would have expected all lines to get the TODO.Same effect, if I hit 
>> C-c C-t: only the line at the point gets the TODO status rotated.
>>
>> looks like a bug to me, but I would not know where to start looking 
>> for how to fix this.
>>
>> Mario
>>

Re: [bug] select TODO items and unexpected behaviour

[Kyle Meyer]

Mario Frasca writes:

> this behaviour comes after somehow my 
> `org-loop-over-headlines-in-active-region' became nil.

Perhaps not the "somehow" but the default value of this option is
different between the last release and master.  It changed from nil to t
in e360cd8f3 (Change the default values for several options,
2020-02-21).

> if I set it back to t, I get the message "Symbol's value as variable is 
> void: right".

Thanks for reporting.  Looks like org-todo's call to org-map-entries has
been broken since its introduction in 7.8.05.  Should be fixed with
8a2eb7d1b.

Re: [bug] select TODO items and unexpected behaviour

[Mario Frasca]

the "somehow", I can confirm it happened in the same session.  it was 
left like that when I ran toggle-debug-on-error and landed in the debugger.

I also noticed that the behaviour on the selection is only implemented 
for some actions, not all.

if you select items, then S-<up> (to raise priority), the result is … 
difficult to describe, non-selected parts of the buffer disappear, I am 
asked about a Tag, for whatever reason, at this point I hit C-g, and the 
raise-priority is applied, but only on the line containing the point.

went looking in the code for these functions, and the leading test, 
recursively implementing the action on the selected lines, I only saw it 
repeated with variations in a couple such functions. as said, 
org-priority does not have it.  I think the block could better be 
generalized, my guess is by defining a well suited macro.

regards, MF

On 28/06/2020 01:32, Kyle Meyer wrote:
> Mario Frasca writes:
>
>> this behaviour comes after somehow my
>> `org-loop-over-headlines-in-active-region' became nil.
> Perhaps not the "somehow" but the default value of this option is
> different between the last release and master.  It changed from nil to t
> in e360cd8f3 (Change the default values for several options,
> 2020-02-21).
>
>> if I set it back to t, I get the message "Symbol's value as variable is
>> void: right".
> Thanks for reporting.  Looks like org-todo's call to org-map-entries has
> been broken since its introduction in 7.8.05.  Should be fixed with
> 8a2eb7d1b.

Re: [bug] select TODO items and unexpected behaviour

[Mario Frasca]

On 28/06/2020 01:32, Kyle Meyer wrote:
> Thanks for reporting. Looks like org-todo's call to org-map-entries has
> been broken since its introduction in 7.8.05.  Should be fixed with
> 8a2eb7d1b.

3ed035ce3

with this patch, you don't need to locally redefine the 
org-loop-over-headlines-in-active-region variable, do you?

Re: [bug] select TODO items and unexpected behaviour

[Kyle Meyer]

Mario Frasca writes:

> On 28/06/2020 01:32, Kyle Meyer wrote:
>> Thanks for reporting. Looks like org-todo's call to org-map-entries has
>> been broken since its introduction in 7.8.05.  Should be fixed with
>> 8a2eb7d1b.
>
> 3ed035ce3
>
> with this patch, you don't need to locally redefine the 
> org-loop-over-headlines-in-active-region variable, do you?

What have you tried on your end to answer that?  Here are some
approaches:

  * Read the commit message in 3ed035ce3 (org.el: Clarify argument in
    org-todo's call to org-map-entries).  Does its explanation fit with
    your understanding?  Perhaps it's wrong or not written clearly, but
    it seems like a good starting point.

  * Drop the let-binding of org-loop-over-headlines-in-active-region in
    org-todo, and try it out.  Does it work as before?  Better yet, step
    through the call of the function, comparing the behavior before and
    after.

  * Drop the let-binding and run the test I added in 8a2eb7d1b (org.el:
    Fix org-todo argument handling when looping over region).

Re: [bug] select TODO items and unexpected behaviour

[Kyle Meyer]

[ Please don't drop the list in your replies. ]

Mario Frasca writes:

> if we were using self-evaluating symbols, the issue would vanish, and 
> the code might result easier to read.

The "loop over headline" code in org-todo needs to be able to handle
every argument that org-todo accepts, including prefix arguments.  A
wholesale rewrite of all of its arguments isn't an option.

> On 28/06/2020 01:32, Kyle Meyer wrote:
>> Should be fixed with
>> 8a2eb7d1b.
>
> I have an extra doubt on this feature.  in fact, the completely 
> independent rotation of status is not what I would expect.  what I would 
> expect is more like having several 3-way switches next to each other, 
> and I pull them all together to a common position, stepwise … like, 
> imagine the status is 1-2-0…
>
> times I activate the tool ->
>
> 0 1 2 3 …
> -----------
> 0 1 2 0
> 1 1 2 0
> 2 2 2 0
> 1 1 2 0
> 0 1 2 0
> 2 2 2 0
>
> now what happens is:
>
> 0 1 2 3 …
> -------------
> 0 1 2 0
> 1 2 0 1
> 2 0 1 2
> 1 2 0 1
> 0 1 2 0
> 2 0 1 2

This is orthogonal to the fix in 8a2eb7d1b.  I do not have an opinion,
at least at the moment.  Perhaps others that are interested will weigh
in.

Re: [bug] select TODO items and unexpected behaviour

[Russell Adams]

On Sat, Jun 27, 2020 at 04:16:53PM -0500, Mario Frasca wrote:
> when I select subsequent TODO items, whole lines, and I do M-<right>,
> they get demoted by one star, so something like
>
> * header
> <point>* a1
> * a2
> * a3
> <mark>* header
>
> after I hit M-<right> will become
>
> * header
> <point>** a1
> ** a2
> ** a3
> <mark>* header
>
> which is what I expected, even if I would not expect the region to be
> deactivated.

I thought shift-meta-right added a shift to subtrees in addition to the current
headline.

You expected it to work with the region? I always use multiple-cursors mode for
that...

https://orgmode.org/org.html#Structure-Editing

This doesn't mention working on the region. Did you read that somewhere?

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3