Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-03 Thread Jens Schmidt
On 2023-09-03 08:53, Ihor Radchenko wrote: > Jens Schmidt writes: > >> Implemented in the next version of the patch, please check. >> > > Applied, onto main. Thanks!

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-03 Thread Ihor Radchenko
Jens Schmidt writes: > Implemented in the next version of the patch, please check. > > From 11dc3ac4ff060f1ffb9dae7b35eabe526bbbc572 Mon Sep 17 00:00:00 2001 > From: Jens Schmidt > Date: Thu, 24 Aug 2023 22:38:02 +0200 > Subject: [PATCH] org-make-tags-matcher: Re-add quoting of property names

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-02 Thread Ihor Radchenko
Jens Schmidt writes: > TL;DR: > > - I think we cannot make "&" mandatory because of backward compatibility. Sorry for the confusion. I did not mean that "&" should be mandatory, just that "&" might make it easier to avoid a need to escape things. So, it could be used _instead_ of escaping. > -

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-01 Thread Tom Gillespie
Ignore the previous message. I see that this was about matching tags not about specifying them. Best, Tom

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-01 Thread Tom Gillespie
Without wading too far into this, why do we need escape syntax for this? The only character that might need an escape would be colon :, but my reading of the syntax doc is that colo : will immediately terminate the property, so we would update the doc to make it clear that property names cannot

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-09-01 Thread Jens Schmidt
On 2023-08-27 09:43, Ihor Radchenko wrote: > Samuel Loury writes: > >> IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that >> & and | are forbidden to say anything else than AND and OR and people >> would be ok with that. > > Actually, explicit & or | might be an easier way

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-31 Thread Jens Schmidt
On 2023-08-31 10:08, Ihor Radchenko wrote: > Jens Schmidt writes: > >>> Implemented in the next version of the patch, please check. >> >> Gentle ping ... > > I was waiting for your comment on > https://list.orgmode.org/orgmode/874jklhqw2.fsf@localhost/ Ah, ok, sorry. I will give that branch

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-31 Thread Ihor Radchenko
Jens Schmidt writes: >> Implemented in the next version of the patch, please check. > > Gentle ping ... I was waiting for your comment on https://list.orgmode.org/orgmode/874jklhqw2.fsf@localhost/ -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-30 Thread Jens Schmidt
On 2023-08-26 14:54, Jens Schmidt wrote: > On 2023-08-26 14:22, Ihor Radchenko wrote: >> Looks good to me. > > Implemented in the next version of the patch, please check. Gentle ping ...

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-27 Thread Ihor Radchenko
Samuel Loury writes: > IMHO, "-tag&-todo=TODO" is totally ok. I even imagine we could say that > & and | are forbidden to say anything else than AND and OR and people > would be ok with that. Actually, explicit & or | might be an easier way to not worry about escaping things. Except escaping &

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-27 Thread Samuel Loury
I have a dumb question. IIUC, it needs a lot of effort to deal with implicit & correctly. I initially used it because de manual said it was ok, but I would have used explicit & if the manual had said so. I wonder if we could just stop saying that & is optional and have a simpler parsing. IMHO,

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Jens Schmidt
On 2023-08-26 14:22, Ihor Radchenko wrote: > Jens Schmidt writes: >> #+begin_example >> boss\-prio="C" >> boss\:prio="C" >> boss\\prio="C" >> #+end_example > > Looks good to me. Implemented in the next version of the patch, please check. From 11dc3ac4ff060f1ffb9dae7b35eabe526bbbc572 Mon Sep

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Ihor Radchenko
Jens Schmidt writes: >> That's partially what I meant. >> It would help to provide a simpler example first. > > How about a series of simpler examples then, like this: > > #+begin_example > boss\-prio="C" > boss\:prio="C" > boss\\prio="C" > #+end_example Looks good to me. -- Ihor Radchenko //

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Jens Schmidt
On 2023-08-26 14:00, Ihor Radchenko wrote: > Jens Schmidt writes: >> On 2023-08-26 12:16, Ihor Radchenko wrote: >>> This actually feels rather cubersome. >> >> [...] I can >> provide a simpler example in the manual, but that's probably not >> what you meant :-) > > That's partially what I

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Ihor Radchenko
Jens Schmidt writes: > On 2023-08-26 12:16, Ihor Radchenko wrote: >> Jens Schmidt writes: >>> #+begin_example >>> -+-long-and-twisted-property-name-="foo" >>> +\-long\=and\\twisted\:property\.name\*="foo" >>> #+end_example >> >> This actually feels rather cubersome. > > That particular

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Jens Schmidt
On 2023-08-26 12:16, Ihor Radchenko wrote: > Jens Schmidt writes: >> #+begin_example >> -+-long-and-twisted-property-name-="foo" >> +\-long\=and\\twisted\:property\.name\*="foo" >> #+end_example > > This actually feels rather cubersome. That particular example looks awkward, but pls don't

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-26 Thread Ihor Radchenko
Jens Schmidt writes: >> IOW, backslash quotes everything except whitespace, which by definition >> cannot be part of a property name. >> >> Will start on this, but with tests and documentation this might take >> some time. > > Here comes a first patch ... please check. Thanks! >

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-25 Thread Jens Schmidt
On 2023-08-24 10:52, Jens Schmidt wrote: > On 2023-08-24 09:32, Ihor Radchenko wrote: >> I prefer (B). And we will need to allow escaping of the "\" itself. Like >> \\. > > OK. Since backslash is not used yet in the rest of the regexp, (B) > should be rather edge-case-free. So the

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-24 Thread Jens Schmidt
On 2023-08-24 09:32, Ihor Radchenko wrote: > Jens Schmidt writes: >> Some obvious choice would be a simpler single backslash >> >> (B) "\-" => "-" > > I prefer (B). And we will need to allow escaping of the "\" itself. Like > \\. OK. Since backslash is not used yet in the rest of the

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-24 Thread Ihor Radchenko
Jens Schmidt writes: >> When "TAG1-TAG2" is an actual tag name with dash, we may allow escaping. > > But I'd like to clarify that. From the Org syntax > > https://orgmode.org/worg/org-syntax.html#Headings > > I understood that tag names cannot contain minus characters, > and `org-tag-re' does

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-24 Thread Ihor Radchenko
Jens Schmidt writes: > Yet another edge-case: In the Org syntax definition a property > name is really delimited by a "colon-whitespace" sequence. This > takes out the ambiguity whether a property name is defined > non-greedily > > :[^[:space:]]+?: > > or greedily > > :[^[:space:]]+: > >

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-23 Thread Jens Schmidt
On 2023-08-23 16:00, Jens Schmidt wrote: > Given the property name syntax in > > https://orgmode.org/worg/org-syntax.html#Node_Properties > > the subre in `org-make-tags-matcher' to match property names > should then look similar to > > "\\(?5:[[:alnum:]_]+\\|:[^[:space:]]+?:\\)" > > ,

Re: [RFC] Quoting property names in tag/property matches [Was: [BUG?] Matching tags: & operator no more implicit between tags and special property]

2023-08-23 Thread Jens Schmidt
> On 2023-08-23 12:31, Ihor Radchenko wrote: > >> Jens, we got an edge case with "-", after all. >> >> What is happening here is that the new parser >> (https://orgmode.org/list/9132e58f-d89e-f7df-bbe4-43d53a236...@vodafonemail.de) >> treats the above match string as >> >> property "tag-TODO"