Re: Project idea on "Big one hook"

[Teika Kazura <teika lavabit com>]

Hi, thanks Jeremy and Timo. Glad two savants are interested.

What Jeremy recalls is this. I'll add it to the faq in 1.6:
------------------------------------------------------------------------
Q:
I wrote a code to hack focus / window stacking, but it doesn't work!
It seems quite unlikely. Why?

A:
It's one of the trickiest subjects, mainly due to the timing.
You have to understand the entire procedure in which your code
lies. For example, suppose you'd like some fix when a window
appears. Most commonly, before-add-window-hook, add-window-hook,
after-add-window-hook, and map-notify-hook are called, in this
order. Many functions are put there. (Evaluate each hook, and you can
guess the rough meaning of each from their name.) Pay attention to
their order, check the variables values, and you will probably come up
with the way out.

Yes, it's too complicated. Sorry for that. It may be improved.
------------------------------------------------------------------------
I fear that my draft is not good enough.

Now an example of this kind:

On Fri, 26 Dec 2008 20:34:20 -0800, Ian Zimmerman wrote:
> I added the following to my .sawfishrc.  It didn't change anything!  Why?
> It's as if W-Tab cycling didn't count as focus change :-(
> 
> (defun my-focus-hook (w mod)
>   (warp-pointer-if-necessary w))
> 
> (add-hook 'focus-in-hook my-focus-hook)

This is before warp is added in Sawfish-1.5.

I myself have experienced similar at least three times, both in focus
and stacking. Isn't it a problem or what? :)

It's true that evaluation of the hook gives hints. Actually it's the
only way. But it requires each user, each time they'd like a hack.
Then you plunge into the sea of git-grep / ack. For layman like me,
it's quite a workload, and sometimes I fail to read off the program
intention. It hinders Sawfish progress. And don't assume anyone
knows ack. (Until GSR (?) told in this mailing list, I've been using
for i in `find...` ; do str=`grep... Headaches. ;)

It's unsound that no one knows exactly what happens internally,
especially when a window is added and mapped. Doc (notes) may
suffice. Easiest way to maintain is to attach inline comments into the
code, though. (Separate docs are often left untouched after
enhancements in codes.) Yet, its anticipated difficulty discourages
me. Doc is easier, but at least one is desired.

Let me add some points.
1. It is better if hooks provide an easy way to hack, not requiring
rewritement of the core code as far as possible. Anyway, user
should be able to understand which is needed. Currently not.

2. On order in add-hook. My words were curt. I mean, you can't tell
if it should come earlier or later if you don't understand what's
exactly hooked in, is it?

> And order isn't supposed to matter in a hook;

It should be so, but many are thrown into hooks. So I guess it does
matter. (For example, it must be likely that someone wants to override
matcher's action. Then it must be done *after* matcher.)

And it may be inevitable. If you move the poiter in a hook, it can
send some events, resulting in another call hook, erasing previous
effect.  (I don't understand X, so not sure.)

> Personally, I like hooks.  Hooks make the code much more extensible
> by the end user, and ideally more modular as well.  I can add to a
> hook in the module that needs that hook, so if the module isn't
> loaded that code never gets run.  Or I could add a hook in my
> .sawfishrc file if it's just a quick hack.

I don't deny use of hooks by core codes, especially for optional
features, like tab or infinite-desktop. What I want is to glue
all-time hooked in (= "main") functions together. But we can reduce to
make things transparent.

Hook use by contributed scripts or users are encouraged. In fact, I
aim to make them possible, like quoted case by Ian Zimmerman's, by
simplifying system-side hook dependence.

On Sun, 27 Sep 2009 14:35:20 +0300, Timo Korvola wrote:
> On Saturday 26 September 2009 07:38:24 Teika Kazura wrote:
>> Currently, each module independently puts their functions on hooks.
>> So, it is quite obscure both for users and developers what is
>> processed, e.g., when a window is mapped.
> 
> This is unavoidable in modular code, where different modules will need 
> to react to the same events.

It's true for modules which provide optional functionalities, but not
for mandatory codes?

> Does Rep have a function that would return the structure (module) where 
> a given closure is defined?

I don't know most of you don't know. ;)

On Sat, 26 Sep 2009 12:13:50 -0500, Jeremy Hankins wrote:
>> There's nicety in Sawfish initialization; some open/require can break
>> Sawfish,
> 
> Can you give an example of this? 

Add to wm/windows.jl "open sawfish.wm.menus". IIRC Chris recently said
opening sawfish.wm.util.prompt triggered a bomb. (I mean, your sawfish
won't run.) That's why some functions have inline 'require', loading
but avoiding breakage.

> Some of this may indicate bugs that should be fixed.

I was about to ask if someone knows the mechanism :) It's not good,
but in fact JS Harper seems to have known it. I guess that's why in
lisp/sawfish/wm.jl, intern-structure is used before open-structure.

What's `intern-structure'? Let me quote from require() in
librep/src/structures.c:
------------------------------------------------------------------------
/* Need to do all this locally, since the file providing the
  feature/module has to be loaded into the _current_ structure
  (in case it contains bare code). %intern-structure OTOH
  always loads into *root-structure*, since it's often called
  with only the %meta structure imported */
------------------------------------------------------------------------
I don't understand. Maybe Timo does.

Regards,
Teika (Teika kazura)