Re: On removing sequence_number from window structure

[martin rudalics]

> This is just 10 lines of code:

Not counting those we'd need for print.c.  Look at the checks for
printing frame names.

> (defvar window-identification-count 0)

This is the global variable I'd have to maintain externally.

> (defvar window-identification-table (make-hash-table :weakness 'key :test 
'eq))

OT1H you propose using a hash table ...

> (defun window-identification-update ()
>   (walk-windows (lambda (w) (or (gethash w window-identification-table)
>                            (puthash w (setq window-identification-count (1+ 
window-identification-count)) window-identification-table)))))

... and OTOH you simply increment `window-identification-count' as in
the sequence numbers approach which makes this unsuitable for users who
wanted to use window ids as prefix arguments for window selection.

> (add-hook 'window-configuration-change-hook 'window-identification-update)

Just that if I run something on `window-configuration-change-hook'
before `window-identification-update' I'm lost.  And anything I run in
between `split-window-internal' and
`run-window-configuration-change-hook' doesn't have the new numbers yet.

But I think we could unify your approach with sequence numbers: If the
customizble function `set-window-id' is not set, use classic sequence
numbers with their C counter.  This would be useful for debugging and
with emacs -Q.

For getting a useful prefix argument (which should never change for one
and the same window) `set-window-id' would use the first unassigned key
(this is not suitable for debugging since since if GC happens in the
middle of a trace, you could get the impression that two windows are the
same whereas the first of them has been deleted before the GC and the
second one has been created after it).  Obviously, if GC is rare, window
ids might grow large but if we don't assign low numbers to internal
windows this should be less critical.

martin