Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

> Ihor Radchenko  writes:

> No further votes.
> I am thus leaving the current behavior.
> Closed, poll.
> Canceled, bug.

Understood, thank you very much for the consideration. I’m training my fingers
to the current behavoir.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Upon seeing the manual, I am inclined to keep the current behaviour,
> unless we have other voices supporting the change.

No further votes.
I am thus leaving the current behavior.
Closed, poll.
Canceled, bug.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[Ihor Radchenko]

John Wiegley  writes:

> Since the documentation also mentions that space means “any tag”, I guess now
> it’s a design question: Should  mean “no tags” or “any tag”? I feel
> like it should mean “no tag” only because you also use space to clear all tags
> in the agenda after pressing “:”.
>
> If the decision is “desired behavior”, then the muscle memory needed is
> ‘\ - ‘ rather than ‘\ ‘. Still feels odd for space to mean
> anything rather than nothing, though… I mean, space is empty, right? :)

Yeah. I checked the manual, and we have SPC being "any tag at all" since
the very beginning of the git history:

  #+findex: org-agenda-filter-by-tag
  Filter the agenda view with respect to a tag.  You are prompted for
  a tag selection letter; {{{kbd(SPC)}}} means any tag at all.

Upon seeing the manual, I am inclined to keep the current behaviour,
unless we have other voices supporting the change.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

> "IR" == Ihor Radchenko  writes:

IR> It would be nice to bisect down to the commit that changed the behaviour.
IR> As it usually goes with agenda, consequences of some changes are not
IR> always straightforward.

I have found the cause of the change in behavior:

  (org-agenda-filter-make-matcher '("+" . nil) 'tag)
=> 8.2.4: (and (not tags))
=> 9.6.6: (and (or tags))

This occurred during the refactoring in:

  commit 6c6ae990c10dbe7f96b24fccf840fe9f6d81a3b8
  Author: Gustav Wikström 
  Date:   Sat Jan 24 02:47:35 2015 +0100
  
  org-agenda: Filtering in the agenda on grouptags

  […]
  
  * lisp/org-agenda.el (org-agenda-filter-make-matcher): new optional
argument EXPAND and refactoring.

The change was released in 8.3, which is why I never noticed it, because I
upgraded from 8.2.4 directly to 9.6.

Since the documentation also mentions that space means “any tag”, I guess now
it’s a design question: Should  mean “no tags” or “any tag”? I feel
like it should mean “no tag” only because you also use space to clear all tags
in the agenda after pressing “:”.

If the decision is “desired behavior”, then the muscle memory needed is
‘\ - ‘ rather than ‘\ ‘. Still feels odd for space to mean
anything rather than nothing, though… I mean, space is empty, right? :)

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

> "IR" == Ihor Radchenko  writes:

IR> Are you sure?
IR> I can see 124017b6d that changes

IR> (setq org-agenda-tag-filter
IR> (cons (concat (if exclude "-" "+") tag)
IR>   current))

IR> to

IR> (setq org-agenda-tag-filter
IR> (cons (concat (if exclude "-" "+") tag)
IR>   (if accumulate current nil)))

IR> The former would leave the current filter unchanged.

IR> It would be nice to bisect down to the commit that changed the behaviour.
IR> As it usually goes with agenda, consequences of some changes are not
IR> always straightforward.

Since my data should all still be compatible with the old version I was using,
I’ll see if I can bisect this. I know I was used to that binding, but I’m not
100% certain it wasn’t due to extenuating factors in my configuration.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[Ihor Radchenko]

John Wiegley  writes:

>> Ihor Radchenko  writes:
>
>> Changing the current behaviour will be a breaking change.
>>
>> I am inclined to change the current behaviour and document it, unless there
>> are objections.
>
> I would also note that in Org-mode 8 and earlier, ‘/ ’ would limit to
> all untagged entries, which is why I had that expectations.

Are you sure?
I can see 124017b6d that changes

(setq org-agenda-tag-filter
(cons (concat (if exclude "-" "+") tag)
  current))

to

(setq org-agenda-tag-filter
(cons (concat (if exclude "-" "+") tag)
  (if accumulate current nil)))

The former would leave the current filter unchanged.

It would be nice to bisect down to the commit that changed the behaviour.
As it usually goes with agenda, consequences of some changes are not
always straightforward.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[John Wiegley]

> Ihor Radchenko  writes:

> Changing the current behaviour will be a breaking change.
>
> I am inclined to change the current behaviour and document it, unless there
> are objections.

I would also note that in Org-mode 8 and earlier, ‘/ ’ would limit to
all untagged entries, which is why I had that expectations.

-- 
John Wiegley  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com  60E1 46C4 BD1A 7AC1 4BA2

[POLL] [BUG] Inverse behavior from \ [9.6.4 (release_9.6.4-1-g76cf21 @ /Users/johnw/.emacs.d/lisp/org-mode/lisp/)]

[Ihor Radchenko]

"John Wiegley"  writes:

> When I type ‘\ c’, the agenda view limits to my (c)all tags. This is what I
> expected to see.
>
> When I type ‘\ ’, however, it limits to every tag *but* the empty tag.
> This is the opposite of what I expect to see.

Confirmed.

In `org-agenda-filter-by-tag',

((or (eq char ?\s)
  (setq a (rassoc char alist))
  (and tag (setq a (cons tag nil
  (org-agenda-filter-show-all-tag)
  (setq tag (car a))
  (setq org-agenda-tag-filter
(cons (concat (if exclude "-" "+") tag)
  (if accumulate current nil)))
  (org-agenda-filter-apply org-agenda-tag-filter 'tag expand))

"\ " will call

(org-agenda-filter-make-matcher '("+") 'tag nil) ; => (and (or tags))

which matches entries with tags, not the entries without tags.

But  is actually not documented, so I am not sure if it is a bug.
I can see logic with  being "any tag" (it appears alongside other
tag shortcuts), and I can see logic with  being "no tag"
(consistent with `org-set-tags-command').

Changing the current behaviour will be a breaking change.

I am inclined to change the current behaviour and document it, unless
there are objections.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at