Re: [Pan-users] Filtering

[Duncan]

Jim Henderson posted on Tue, 27 Sep 2016 20:30:55 +0000 as excerpted:

> On Tue, 27 Sep 2016 19:29:01 +0000, Dave wrote:
> 
>> On Tue, 27 Sep 2016 18:19:33 +0000, DLSauers wrote:
>> 
>>> Hopefully maybe some one will work on the scoring features to improve
>>> them for non regex speaking users.
>> 
>> Back in the days when I used Windows, the GUI filtering for Foret Agent
>> was OK but it was very much worthwhile learning at least the basics of
>> regex to get the full benefit, especially if one had more complex
>> requirements.
> 
> FWIW, I would agree with this assessment.  The regex requirements for
> this are simpler than full JavaRE (for example), because we're not doing
> replacements, which is where a lot of regex complexity comes in - so
> grouping and forward/backwards references aren't needed.

But... some people's minds simply don't wrap around regex.  I get that.

FWIW my mind doesn't wrap around sports.  Luckily for me, not much I 
really want to do involves sports, so I don't have to worry about it 
/too/ much.

But it would have been /nice/ had I had just enough more "common sense" 
in the area to realize, at one point many years ago, that footballs 
aren't "Nerf" inside -- they're inflated.  As it happens I was /way/ 
short on sleep that day and that probably had something to do with it as 
well, but...  I was working dorm reception that day at college, and 
someone came in to drop off a football for someone, and I *stapled* the 
guy's name to it! =:^(

So yeah, I definitely understand not "getting it" with regard to some 
element of something that's just assumed to be common sense knowledge... 
it _might_ be "common sense" within that domain, but that's the point, 
not everybody has that sort of domain knowledge, or even cares to have it.

OTOH, it could be argued that there are simply certain things that you 
can't do if you don't know how, that they /do/ require some level of 
domain knowledge, and that it's simple fact, not /bad/, that it is so.  
That both allows and encourages people to specialize, and ideally, to 
help each other.

Which is what I'm going to try to do here, devising a set of scores and 
actions to allow DLS to do what he set out to do.

But I believe I'm going to punt for a few days and will have to come back 
to it, for reasons I'll put in a different, somewhat OT, post, following 
up on a thread from a few months ago...  IRL has me pretty busy ATM and 
I'm afraid I can't properly focus on this ATM, but it's a /good/ busy. 
=:^)

So DLS, please followup with a reminder in a couple weeks if I've not 
gotten back to this by then (and if no one else has beat me to it), as I 
still think it's possible, but I just can't think about it that hard ATM 
as there's too much else going on IRL.

> But a switch to go between simple wildcard settings and full regex would
> be nice.   Similarly, tools that would enable/disable regex flags
> (another area that can get confusing for novices) would be good - so
> case sensitivity can be enabled/disabled using a checkbox rather than
> having to remember to prepend (?i) to the expression.


This bit doesn't require thinking so hard, tho, so...

* FWIW, pan scoring is case insensitive by default, and I'd consider that 
a good thing.  No having to set that specifically. =:^)

* Keep in mind that at least some of the reason pan's scoring works the 
way it does is because of the common slrn scorefile format Charles chose 
to use for it.  Since that's a format common to multiple clients, it's 
worth keeping, and at least here, I'd find it a sad day if pan were to 
move away from that format, because there *is* value in keeping to a 
common format like that.

* Which means if the tools are adjusted to make more advanced usage 
simpler for those who don't know regex, it'll have to be the GUI front-
end only -- they'll have to do the translating to the common format, 
including regex, as appropriate, and store the score in the same common 
format they do now.

* Which brings up another point -- those regex helping tools don't 
necessarily have to be part of pan itself.  And indeed, qt, for instance, 
and I'd imagine gtk as well, I'm just not familiar enough with it to be 
sure, has regex editing tools.  In qt4/kde4 era, I believe they were 
actually in kde4, but in the current qt5/kde5/plasma5/frameworks5 era, it 
took some time to bring them back, but I believe they're available now 
and are no longer quite so kde dependent, they're more qt-generic now, 
altho they may still require a kde framework or two.

* More generically, I haven't googled it, but I'd be /very/ surprised if 
there weren't regex translation websites out there, that allowed you to 
plug in conditions via some GUI, and spit out the regex as output.


-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman