joh

Members
  • Content Count

    33
  • Joined

  • Last visited

About joh

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. A small issue. If when browsing in group By feed you click on an individual feed, the options menu indicates that it has temporally defaulted to None grouping (which makes sense), as shown by the tick. However the Mark below as read option is not available and you have to click on None grouping (despite it appaently already being selected) in order to see the option for Mark below as read. cheers, joh P.S. Please add option to mark above section as read in group by feed for tags and searches. Also add Mark below as read.
  2. Grouping by feed does work for tags and searches, it just doesn't have the mark above section as read button. Why not? I understand this but it is inconsistent with still having a mark above as read option, since this marks all above as read regardless of feed (when using group by feed). I could paraphrase you: "There is no "mark above" as read since you might have multiple feeds (sorted that way) above. This is implemented intentionally since you might want to see the unread items in the other feeds too (you are using group by feed)." What's the difference? Anyway, for the reason you state, this would not be as useful for me so please add the mark above section as read button to tags and searches! Please! cheers, joh
  3. Hi, I just noticed this reply. Thanks, yes, that is exactly what I would like, however it is not available within tags or active searches, which is why I didn't see it. Can you please add this feature within tag and search "folders"? (Also when grouped by feed, it only possible to mark above as read, without the mark below as read option that is available otherwise.) cheers, joh
  4. joh

    Rule/search matching issues

    Hello again. After looking through my tags and searches now after about two weeks, I'm pretty sure this is completely resolved. Good work! ActualIy at first it seemed that is was still randomly failing in some cases, but this turned out to be due to some subtle syntax issues, as I will now tediously explain. Firstly I had a search and rule looking for a particular surname. The search missed one instance (compared to the rule) for no apparent reason. However it was because it was in the article as "Forename Surname" rather than "Forename Surname". The character in the former case is not a normal space, so the search was treating it all as one word and not matching. [Okay, after copying it here, it seems to have been converted to a normal space automatically, but copying it into Notepad++ I can see that it's not, so I don't know how to show you it. Perhaps you know what character it is, looks like a normal space, but isn't.] Secondly I had one search that seemed to still fail a lot. It was looking for multiple terms separated by ORs, something like: aacc OR aa(bb)cc OR bbcc Well on investigation, it seems a term like that with parentheses (perhaps just when combined with the OR statements?) causes many failures. For example for some reason it was not matching an article that had term 1. If I removed term 2, or just the parentheses, it found the missed article due to term 1. Putting quotes around term 2, i.e. "aa(bb)cc" also resolved the problem, so I guess the parentheses are special characters in this case. Anyway after redoing the search with the quotation marks and saving, the results matched those of my equivalent rule. Note: When the active search is saved, the quotation marks are removed from the search title, but looks like the proper search term is maintained. cheers, joh
  5. I'll just make the suggestion that it might be good to add icons to collapsed items in list view to show whether they have been tagged/active searched/highlighted. So the tag symbol if a non-folder non-active-search tag has been applied (e.g. by a rule), a magnifying glass if the item has been captured by an active search, and a marker or something to show whether a word in the title or contents has been highlighted. This way items of potential interest will be more easily spotted when browsing feeds. I guess they could be added on the LHS by the star, or on the RHS. cheers, joh
  6. Hello, Would it be possible to add the ability to export the URLs of Starred items as a bookmarks html file, so that they could be then imported into a browser as bookmarks? I don't mean exporting/importing as feed items, but exporting/importing the web page URLs that the feed items link to? cheers, joh
  7. joh

    Rule/search matching issues

    Okay that's great. I will keep an eye on it. The most recent failure I can see is from about 12h ago, which is probably before you made the change. It seems that a bunch of items posted at once by the same feed were all missed -- perhaps this fits in with your truncated index explanation? As for your statement that it should be a very rare occurence, I don't know what that quantitatively means, but I would say that the incidence of missed items was at least in the single figure percent range, although hard to say exactly given the differences also arising due to syntax. I will see how it goes now. Despite my persistence on this issue, rules work better for me, primarily because they are editable and generally more versatile, and so I now only really have active searches as a backup/test of the rules. Similar to your issue with the tokens, I noticed that sometimes my active searches were picking up items my rules missed, due to the fact the active searches seemed to treat hyphens and en dashes equivalently (perhaps also equivalently to spaces) -- I guess because it breaks everything into tokens as you described. Well anyway my rules were missing items because I only specified the compound word case with hyphens, so when an occurence used en dashes, it was not picked up. Perhaps (as in your token solution) some equivalency could be made (optionally) between frequently interchanged symbols, such as the different types of apostrophe (and quotes, and prime), or the many different types of hyphen/dashes, within the rule options. But this is just a syntax issue that can be dealt with at the user end in other ways. cheers, joh
  8. joh

    Rule/search matching issues

    As you can probably appreciate it would be quite a lot of work for me to gather the details of all of these occurences. Luckily there is a clear example from the last day or two. I have an active search, which searches title and contents for the term "purcell", and a rule matching the term "purcell" in title or contents: In the last few days these have produced the following: As you can see the rule has matched one more than the search, and the item that the search missed is identical to a different one that it did match, albeit from a different feed. Here are the two items from the two feeds expanded so you can play spot the difference: As you can see they are identical, at least at the user end. Also the one that was missed by the active search is missing another tag "photon*" which corresponds to another active search I have. So this item seems to not have been active searched at all. The feed details are here: Although from the same website, I am getting them through slightly locations it seems, although my problem isn't restricted to this one feed, as far as I can tell missed items can be from any feed, it is just more obvious when I see a case like this with identical items. Hopefully you are now at least convinced that my query has nothing to do with syntax. cheers, joh
  9. joh

    Rule/search matching issues

    Yes, and even before you said that, I had already explained in this thread, and have now done so several times, that while differences arise due to syntactic differences between rules and searches, the differences are not entirely due to syntax. I gave the example of the active searches missing one of two identical feed items, when identical items are posted, and when rules catch both. I also mentioned that highlighters show the flagged criteria in the item that the searches missed. It has been quite clear from my first post and susbequent posts that I am aware of the syntactic differences, and that the whole point is that this is not my issue. If it is too much trouble for you or your team to look into this issue by creating some syntactically simple active searches and rules, and observing the differences that arise, and seeing if in all cases it is explained by syntax or not, then so be it, but please stop giving such useless and repetitive responses that are completely ignorant of what the (paying) user is saying. I wouldn't mind if you didn't wait nine days to give a stupid one-line response which is a quote of a previously useless response, I mean cheers, joh
  10. joh

    Rule/search matching issues

    OK, I haven't really been bothered to try and gather the evidence, but I can say that I have approx. 25 rules, and 25 active searches, which should be the same, and which sometimes look for very general words like "updated", and sometimes specific terms like "resonance fluorescence", but in all cases the rules capture more items than the searches. So I can't imagine this observation isn't easily replicated for anyone else. Have you tried creating "identical" active searches and rules, and see what is captured after a few days or weeks? You don't see any differences? Cheers, joh
  11. Yes, when viewing unread articles sorted by feed, it would be very helpful to have a button in the feed title banner to mark as read all items from that feed in the folder/tag. Cheers, joh
  12. joh

    Rule/search matching issues

    While this is true, it is not the answer to my query. While I have observed differences between rules and searches that are not related to syntax, I will for the sake of argument assume I keep missing something obvious. Okay. However, even comparing active searches of identical items, as in my example, items are missed. This shows that it is nothing to do with syntax, but apparently (frequent) random failure to match criteria. I'll repeat again that some of the items that are missed are identical to those that are matched, but just in a different subscription that is working and successfully matched on other occasions. Additionally rules and highlighters are both flagging the criteria successfully, when I look at the missed item. cheers, joh
  13. joh

    Rule/search matching issues

    As further proof that this is a real issue: I have two subscriptions that sometimes post the exact same item. When this occurs, sometimes the active search picks up both items, and sometimes just one. Thus it seems to be entirely random whether an active search misses a match. Rules seem to be more successful for me. Perhaps you can comment on why active search might randomly miss items, and why there is a difference between active search and rule matching. cheers, joh
  14. I have noticed that rules capture many items that apparently equivalent active searches do not. I don't know how this fits in with this recent issue: Secondly, a rule can look for any incidence of the string, whereas the active search seems limited to whole words. This is great, since it solves the issue I had with lack of wildcard prefix, so I have switched my active searches to rules that match content and add a tag. This does not on its own seem to explain the differences I have seen between search and rule matching. joh
  15. Actually, this isn't correct. It's just showing a tag icon for the active searches, instead of the magnifying glass icon for some reason. Perhaps this can be changed.