On removing sequence_number from window structure

On removing sequence_number from window structure

[martin rudalics]

I'm afraid this change

   * window.h (struct window): ...
   Remove sequence_number member. ...
   * window.c (sequence_number): Remove.
   * print.c (print_object): Follow the printed representation of
   frames and print window pointer to distinguish between windows.

will make debugging window code rather unpleasant.  It's much simpler to
think of windows in terms of sequence numbers than in terms of pointers.

martin

Re: On removing sequence_number from window structure

[Dmitry Antipov]

On 02/02/2013 12:50 PM, martin rudalics wrote:

> I'm afraid this change
>
>    * window.h (struct window): ...
>    Remove sequence_number member. ...
>    * window.c (sequence_number): Remove.
>    * print.c (print_object): Follow the printed representation of
>    frames and print window pointer to distinguish between windows.
>
> will make debugging window code rather unpleasant.  It's much simpler to
> think of windows in terms of sequence numbers than in terms of pointers.

Why? The only reason I can imagine is age tracking (e.g. the window with
smaller sequence number is always created before the window with the larger
one); is that so important? Are there other reasons?

Dmitry

Re: On removing sequence_number from window structure

[martin rudalics]

 > Why? The only reason I can imagine is age tracking (e.g. the window with
 > smaller sequence number is always created before the window with the larger
 > one); is that so important? Are there other reasons?

In my modeline I display windows as

			     (concat		; WINDOW
			      (replace-regexp-in-string
			       ">" ""
			       (replace-regexp-in-string
				" on.+" ""
				(replace-regexp-in-string
				 "#<window " "#" (format "   %s" (selected-window)))))

because so far I was too lazy to write a Fwindow_number function.  When
debugging, windows are usually young, and I normally have to look at two
digits at most.  For me a thing like #<frame *scratch* 0369A690> isn't
readable and hardly something I could memoize while debugging.

martin

Re: On removing sequence_number from window structure

[Juri Linkov]

> It's much simpler to think of windows in terms of sequence numbers
> than in terms of pointers.

Are window sequence numbers necessary from the user's point of view?

For frames simple sequence numbers are necessary on terminals
where creating new frames increments the frame number starting from 1
to give frame names like "F1", "F2", "F3" displayed on the modeline.
It's important for the users to know which frame is current by number.
Is the same true for windows?

For frames these sequence numbers are included in frame names.
Should windows have names that could include sequence numbers
like "W1", "W2", "W3"?

Please address these questions as a user since as a developer
you can add something like this for debugging purposes:

(set-window-parameter nil 'window-number (incf global-window-counter))

to a hook run during window creation.

Re: On removing sequence_number from window structure

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 08 Feb 2013 10:17:30 +0200
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > It's much simpler to think of windows in terms of sequence numbers
> > than in terms of pointers.
> 
> Are window sequence numbers necessary from the user's point of view?

They are no more necessary than the pointer to the window object we
are showing now instead of the sequence.

> Please address these questions as a user since as a developer
> you can add something like this for debugging purposes:
> 
> (set-window-parameter nil 'window-number (incf global-window-counter))
> 
> to a hook run during window creation.

That'd be a nuisance.  Emacs already has several features whose sole
purpose is to aid in debugging; I don't see why we should break that
tradition in this particular case.

Re: On removing sequence_number from window structure

[martin rudalics]

 > Are window sequence numbers necessary from the user's point of view?

No.

 > For frames simple sequence numbers are necessary on terminals
 > where creating new frames increments the frame number starting from 1
 > to give frame names like "F1", "F2", "F3" displayed on the modeline.
 > It's important for the users to know which frame is current by number.
 > Is the same true for windows?
 >
 > For frames these sequence numbers are included in frame names.
 > Should windows have names that could include sequence numbers
 > like "W1", "W2", "W3"?

I suppose that (1) the gaps in such numbers due to internal windows and
(2) the fact that windows hidden within saved window configurations use
up numbers but are not visible anywhere, would be only disorienting.

 > Please address these questions as a user since as a developer
 > you can add something like this for debugging purposes:
 >
 > (set-window-parameter nil 'window-number (incf global-window-counter))
 >
 > to a hook run during window creation.

No, since the parameter would not be used as the printed representation
of the value of a function that returns a window.

martin

Re: On removing sequence_number from window structure

[Stefan Monnier]

> I suppose that (1) the gaps in such numbers due to internal windows and
> (2) the fact that windows hidden within saved window configurations use
> up numbers but are not visible anywhere, would be only disorienting.

IIRC, there's a package somewhere that tries to provide numbers to
windows so the user can select windows by number... oh yes I see:

   http://nschum.de/src/emacs/window-numbering-mode/
and
   http://www.emacswiki.org/emacs/download/window-number.el

These packages try to solve the above problem.  But they don't relate to
how a window object gets printed, sadly.


        Stefan

RE: On removing sequence_number from window structure

[Drew Adams]

> IIRC, there's a package somewhere that tries to provide numbers to
> windows so the user can select windows by number... oh yes I see:
> http://nschum.de/src/emacs/window-numbering-mode/
> and http://www.emacswiki.org/emacs/download/window-number.el

FWIW, `icicle-select-window-by-name' does something similar: lets you choose a
window by buffer name, with [N] (N=2,3...) appended as needed for unique names.
http://www.emacswiki.org/emacs-en/download/icicles-cmd1.el

Re: On removing sequence_number from window structure

[Juri Linkov]

>> you can add something like this for debugging purposes:
>>
>> (set-window-parameter nil 'window-number (incf global-window-counter))
>>
>> to a hook run during window creation.
>
> No, since the parameter would not be used as the printed representation

Can't you then use the new window parameter for the modeline like below
instead of hacking on the internal representation:

   (concat            ; WINDOW
    "   #" (format "%s" (window-parameter (selected-window) 'window-number)))

Re: On removing sequence_number from window structure

[martin rudalics]

 > Can't you then use the new window parameter for the modeline like below
 > instead of hacking on the internal representation:
 >
 >    (concat            ; WINDOW
 >     "   #" (format "%s" (window-parameter (selected-window) 'window-number)))

Sure.  But it wouldn't be of any help when the value of a function
returning a window prints differently.

martin

Re: On removing sequence_number from window structure

[Stefan Monnier]

>> Can't you then use the new window parameter for the modeline like below
>> instead of hacking on the internal representation:
>> 
>> (concat            ; WINDOW
>> "   #" (format "%s" (window-parameter (selected-window) 'window-number)))
> Sure.  But it wouldn't be of any help when the value of a function
> returning a window prints differently.

Of course we could incorporate this property in the
#<window...> printout.


        Stefan

Re: On removing sequence_number from window structure

[martin rudalics]

 > Of course we could incorporate this property in the
 > #<window...> printout.

I'm not convinced.  Pointer addresses have the clear disadvantage that
two runs of Emacs will give different results for the same sequence of
window configuration changes.  Window parameters mean that one has to
externally manage some sort of mechanism to assign unique identifiers
(strings or numbers) and run on `window-configuration-change-hook' first
a function to detect for each split the new parent window and the new
live window and assign them the appropriate values.  Clearly nothing for
emacs -Q.

martin, who'd never use %p in print.c if he had the choice

Re: On removing sequence_number from window structure

[Juri Linkov]

> Window parameters mean that one has to externally manage some sort of
> mechanism to assign unique identifiers (strings or numbers) and run on
> `window-configuration-change-hook' first a function to detect for each
> split the new parent window and the new live window and assign them
> the appropriate values.

This is just 10 lines of code:

(defvar window-identification-count 0)
(defvar window-identification-table (make-hash-table :weakness 'key :test 'eq))
(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)))))
(add-hook 'window-configuration-change-hook 'window-identification-update)

(defun mode-line-window-control () (format "-W%s  " (or (gethash (selected-window) window-identification-table) "")))
(defvar mode-line-window-identification '(:eval (mode-line-window-control)))
(put 'mode-line-window-identification 'risky-local-variable t)
;; Insert between mode-line-frame-identification and mode-line-buffer-identification
(setcdr (nthcdr 6 mode-line-format) (cons 'mode-line-window-identification (nthcdr 7 mode-line-format)))

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