arbtt ideas Was: ZuriHac: possible cooperation

[Joachim Breitner]

Hi Sergey,

Am Mittwoch, den 17.03.2010, 19:05 +0100 schrieb 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.?

Yes, this indeed looks strange. The reason is that the current on the
LHS modifies the whole expression, while on the RHS it is part of the
variable name. Any specific ideas how to improve that?

> * "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.

This is an interesting idea and probably not hard to implement. Care to
write a patch (including updated documentation, of course)?

> * Is trailing coma really necessary? The rule should end exactly one 
> literal after the "tag".

It is not necessary if I remember correctly, but it’s optional – I don’t
like how in Haskell you cannot have such trailing separators. Perl etc.
don’t care.

> Some other issues I have with current configuration implementation. Not 
> really syntax issues:
> 
> * Unicode in regex patterns does not match $title.

Good point. We currently use pcre-simple. We need to see what other
regex library is available that works better with UTF8.

> * I have seen match failures with multi-group regexes.

Do you have an example?

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

I think that’s possible, see this line from the example config file:
current window $program == "evolution" &&
any window ($program == "evolution" && $title =~ /^(.*) \([0-9]+/)
  ==> tag Evo-Folder:$1,

Only group matches ($1...) work at the moment, support for $& is not available.


>   >> * 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.

You mean arbtt should perform a statistical analysis of the words
occuring in titles and automatically create rules for them? It’s still
not clear to me what you are aiming for, but I’m eager to hear more
about it.

> >> * 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.

Yes, I concur.

> 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.

If anything, it would be used for presentation. Martin has looked at it
recently, maybe he can tell us more.


Greetings,
Joachim

PS: I wonder at what point we need a mailing list for arbtt.

-- 
Joachim "nomeata" Breitner
  mail: mail at joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C
  JID: nomeata at joachim-breitner.de | http://www.joachim-breitner.de/
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.nomeata.de/pipermail/arbtt/attachments/20100317/7141f0ec/attachment.asc>