rename-window bugs

[Teika Kazura <teika lavabit com>]

(For the record. I don't work on this immediately, but this is a
blocker for the next release.)

rename-window has worsened by our last edit.

Abbervs:
WN   = WM_NAME
NWN  = _NET_WM_NAME
NWVN = _NET_WM_VISIBLE_NAME

"Google code search" shows many applications indeed respect NWVN, as
it should be, while Chris has indicated well known pagers don't.

Ewmh (tacitly) implies pagers and trayers has to check NWVN, NWN, and
WN in this order. Sawfish's rename now changes all of these three.
Strictly speaking it doesn't comply with ewmh to change the latter two,
but as a practical measure, it doesn't seem bad.

Bug 1.
Sawfish sets the window's internal name from NWN and WN only, but it
should consider NWVN, too.

Suppose, Sawfish changes the name, so NWVN is set. Then the client
changes the name, then only NWN is updated. Following this event, 
an (ewmh compliant) pager shows NWVN, but Sawfish sets its internal
name to NWN.

Bug 2.
Window rules -> "window name" is intended to override the windows
name permanently. This is useful for web browsers which changes its
name frequently.
Simple fix of the bug-1 disables this permanent change. But don't stop
here, either.

Bug 3-a.
There's also "uniquify-name" in Sawfish. Internally, uniquify-name
doesn't use rename-window, which was introduced recently.

Bug 3-b.
uniquify-name is, if ever, meaningful for names which change often (I
recommend rename-window + -title command line option). This means
rename-window has to support both permanent and temporary change.

Regards,
Teika (Teika kazura)