ZuriHac: possible cooperation

[Sergey Astanin]

Joachim Breitner:
> I think a lot can be done by exploiting more parsec features. I’d prefer
> to use a ready parser library rather than writing a new one from
> scratch.
> 
> I’m open how to improve the config format. What exactly do you mean by
> more regular? I think it would be possible to allow editing it, or a
> subset of it, by GUI already.

Let's take a simple rule:

current window $program == "Navigator" ==> tag web:$current.title,

* Why is not used $current.program on the l.h.s. as well as as 
$current.title on the r.h.s.?
* "Current window" is used the most, but takes a lot to type. Why not 
default to "current window" unless "any" quantor is given explicitly? 
Then $program, $title may refer to the current program and the current 
title, but "any ( expression with $title or $program )" to replace "any 
window expr". Semantics of $time, $idle and $sampleage is unaffected.
* Is trailing coma really necessary? The rule should end exactly one 
literal after the "tag".

Some other issues I have with current configuration implementation. Not 
really syntax issues:

* Unicode in regex patterns does not match $title.
* I have seen match failures with multi-group regexes.

I suspect these may be regex library issues.

 From my wishlist:

* Refer to group matches on the r.h.s of the rule ($&, $1, $2, ...?)

  >> * I have lots of entries like "web:hamsterdb embedded database: foss
>> exceptions - Iceweasel", it would be nice to think of a way to deal
>> with such entries in a more or less automatic way (groupping by common
>> substrings, common subsequences of strings?)
> 
> I’m not exactly sure what you mean here, can you elaborate?

I use few programs, like web browser or text editor, with a wide variety 
of window titles. Sometimes writing regex rules for all such titles is 
not possible.

Example: one searches something on the web, e.g. by googling for 
"keywordA OR keywordB"; then he reads some pages, e.g. "Introduction to 
keywordA", "KeywordB - Wikipedia, the free encyclopedia", "Manual to 
KeywordB", "KeywordA vs KeywordB. The shootout". I suppose that it might 
be possible to cluster such titles automatically together as

"... KeywordA ... KeywordB ..."
"... KeywordA ..."
"... KeywordB ..."

I suppose this may be a frequent situation, when one browse many pages, 
and their titles have something in common.

>> * an optional charting facility (arbtt-chart) may be useful too, but I
>> think we should stick to the unix way.
> 
> A graphical statistics GUI is definitely wanted. It’s not clear whats
> best: Implement it in Haskell, directly or using Chart (maybe after
> extending Chart as needed), or implement it in python to re-use the
> widgets created for hamster.

I would maintain graphical part as separated as possible, probably as a 
separate command line tool, and I would try to do it in Haskell. There 
are some nice libraries around (Chart and Diagrams), it would be shame 
not to try them.

I don't know much about hamster. Even if it is used as a built-in 
storage, it makes me uneasy to couple storage and representation 
together. If it used only for storage, then it would be relatively easy 
to change storage in the future.

S.