Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entry filters #6

Open
tilboerner opened this issue Jul 10, 2013 · 5 comments
Open

Entry filters #6

tilboerner opened this issue Jul 10, 2013 · 5 comments
Labels

Comments

@tilboerner
Copy link
Owner

Some feeds regularly contain entries that are not very interesting. There should be per-feed filters for entries whose text matches a certain regex. Matches are automatically marked as read and also get a filtered (or filtered-by) attribute set.

Use case from the Github Blog: /is a GitHubber!/, /(?<!Berlin )Drinkup/.

@devsnd
Copy link
Collaborator

devsnd commented Jul 11, 2013

It's nice to have regex, but also more simple filters like: containsAny('foo','bar','baz') or containsAll('bambie','is','dead') would probably be more than enough. Because those filters suck to create using regexes

Or even a little more OO:
title.containsAny('foo','bar','baz') and body.containsAll('bambie','is','dead')

@tilboerner
Copy link
Owner Author

Right, filters like these should also make for better usablility.

That raises the problem of filter UI, though. Any ideas? I'm not too big a fan of radio buttons and comboboxes like

Filter: 
    select[ entry | title | body | ... ] select[has all | has any | startswith | ... ] textfield[   ]

I'd hate using those. How about a mini-Domain Specific Language (if you can call it that) with keywords

  • title,
  • body,
  • and (implied),
  • or,
  • (...),
  • [starts|ends]with(...)?

I'd still like to have regexes, though, because I really want that negative lookbehind assertion there. You never know. 🍻

@tilboerner
Copy link
Owner Author

    filter = ε | expr

    expr = wordlist | op | scope
    wordlist = word (word)*
    word = WORDCHARS+ - <keywords> | '"' MORECHARS+ '"'

    op = and_op | or_op | not_op
    and_op = expr AND expr
    or_op = expr OR expr
    not_op = NOT expr

    scope = blank_scope | named_scope
    blank_scope = "(" expr ")"
    named_scope = [location "."] predicate blank_scope
    location = ENTRY | TITLE | BODY | TEXT
    predicate = CONTAINS | IS | (STARTS|ENDS) WITH

    // whitespace separates tokens but counts as empty
    // syntax errors: treat expression as plaintext or something ><'

Muhahaha! 👹 :neckbeard: 😻

@devsnd
Copy link
Collaborator

devsnd commented Jul 12, 2013

NO PLEASE MAX! I'M SORRY, I DIDN'T MEAN TO! 🔫

Please don't invent YADSL. Can't you just go with a subset of Ruby commands? In python there's a module called ast, which parses python code for you and gives you the abstract tree syntax. This makes it very easy to restrict the language. There must be an equivalent in ruby.

@tilboerner
Copy link
Owner Author

Hehehe. Yeah, after writing out that pseudo-grammar I didn't seriously consider doing that anymore. It's the nucular option! 💣

Using the Ruby parser like you suggest is a very interesting idea. For later reference, here's a link to look into: http://www.igvita.com/2008/12/11/ruby-ast-for-fun-and-profit/ .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants