Feature request: Option "whole word" for filter criterias

Request new functionality here
User avatar
HeikoAdams
Bear Rating Master
Bear Rating Master
Posts: 101
Joined: 19 Mar 2013, 00:17

Feature request: Option "whole word" for filter criterias

Postby HeikoAdams » 29 Aug 2013, 12:28

Hello,
it would be good if the filter criterias could be extended by an option to define if the criteria should be handled as a whole word or not. Currently, if I define i.e. a filter to label all article which contain the name of the business network "Xing" the filter matches all articles regardless if "Xing" is a whole word or just part of words like "fixing". So this option would be very usefull to prevent false positives.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Feature request: Option "whole word" for filter criteria

Postby fox » 29 Aug 2013, 12:48

http://lmgtfy.com/?q=regular+expression+word+boundary

e: depending on how terrible regexp support in the sql server is, filter testing for this might not work

User avatar
davidm
Plays it by ear
Posts: 115
Joined: 29 Mar 2012, 20:10
Contact:

Re: Feature request: Option "whole word" for filter criteria

Postby davidm » 30 Aug 2013, 22:56

May I suggest adding a page on regex syntax to the wiki (copying it from any free manual around) and then adding a help link to that in the filter dialog?

In my case, I wouldn't even know that "boundary" is the correct term for this concept. It took me a long time to find the right info about regex, I didn't even know which particular syntax tt-rss uses.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: Feature request: Option "whole word" for filter criteria

Postby fox » 02 Sep 2013, 13:54

>May I suggest adding a page on regex syntax to the wiki (copying it from any free manual around) and then adding a help link to that in the filter dialog?

I've added the necessary details to the wiki page, including a note re: filter testing. I'll add a link to the rule edit dialog.

>In my case, I wouldn't even know that "boundary" is the correct term for this concept. It took me a long time to find the right info about regex, I didn't even know which particular syntax tt-rss uses.

Well, now you know. And knowing is half the battle, etc.

User avatar
NykO18
Bear Rating Trainee
Bear Rating Trainee
Posts: 1
Joined: 25 May 2014, 17:29

Re: Feature request: Option "whole word" for filter criteria

Postby NykO18 » 25 May 2014, 17:45

I'm digging back this post just to warn you about the broken support of word boundaries in TTRSS. Using the MySQL adapter, the word boundaries in REGEXP are defined as follow:
[[:<:]], [[:>:]]
These markers stand for word boundaries. They match the beginning and end of words, respectively. A word is a sequence of word characters that is not preceded by or followed by word characters. A word character is an alphanumeric character in the alnum class or an underscore (_).
https://dev.mysql.com/doc/refman/5.1/en/regexp.html

Unfortunately, the filter field where you type your regexp in TTRSS is broken and doesn't correctly escape the characters < and >. Maybe you could add a htmlspecialchars() before you output it to the browser, because it effectively prevents any use of word boundaries.
Last edited by NykO18 on 01 Jun 2014, 22:04, edited 1 time in total.

dajhorn
Bear Rating Trainee
Bear Rating Trainee
Posts: 4
Joined: 07 Jul 2013, 13:47

Re: Feature request: Option "whole word" for filter criteria

Postby dajhorn » 31 May 2014, 06:01

(I recently had this problem, and this thread is at the top of a web search for troubleshooting hints.)

The best way to match word boundaries in TT-RSS is to use the \y constraint escape with Postgresql 9 on the back end.

This posix(ish) regex:

Code: Select all

[[:<:]]An Article Filter[[:>]]


Or this PCRE expression:

Code: Select all

\bAn Article Filter\B


Becomes:

Code: Select all

\yAn Article Filter\y


This comes from the Postgresql Pattern Matching documentation and is incompatible with MySQL. I didn't get expected behavior with other constraint escapes like \m or \M.


Return to “Feature requests”

Who is online

Users browsing this forum: No registered users and 2 guests