search

orgzly / orgzly-android

Outliner for taking notes and managing to-do lists
https://www.orgzly.com
GNU General Public License v3.0
2.7k stars 304 forks source link

Allow searching for notes without scheduled time #70

Closed MackieLoeffel closed 7 years ago

MackieLoeffel commented 7 years ago

I would like to be able to search for all todos, which don't have a scheduled time. But it is currently only possible to search for notes, which have a scheduled time (for example with i.todo s.100y).

https://github.com/orgzly/documentation/blob/master/searching-proposal.org mentions the idea of s.none, which matches notes with no scheduled time. Another idea would be to simply use s. for a note with any scheduled time and .s. for a note without one. Which of these two options would you prefer?

nevenz commented 7 years ago

I know I suggested s.none in that proposal, but I think I prefer s.any now. I think it makes more sense and is easier to read? Especially due to double negation in .s.none.

mkaito commented 7 years ago

s.any suggests to me that it would match anything, including undefined but also any other value. I like s.none for this.

El 2 de mayo de 2017 4:10:55 GMT+01:00, Neven notifications@github.com escribió:

I know I suggested s.none in that proposal, but I think I prefer s.any now. I think it makes more sense and is easier to read? Especially due to double negation in .s.none.

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

nevenz commented 7 years ago

s.any suggests to me that it would match anything, including undefined but also any other value. I like s.none for this.

What about s.* ?

I'm fine with only s.none for now BTW, even if something else is supported in the future, nothing wrong with having it too.

mkaito commented 7 years ago

What about s.* ?

Same as above. It suggests to me that it matches anything, including but not limited to the absence of a value.

If what you are trying to specify is the explicit absence of a scheduled date, I think s.none is about as good as you will get it. And that kind of double negative is pretty common in most programming languages. Even in SQL, you will very often see IS NOT NULL when you are trying to negate the absence of value. I think it's not only acceptable, but correct.