From: martin rudalics <rudalics@gmx.at>
Cc: help-gnu-emacs@gnu.org, michael@cadilhac.name
Subject: Re: MY window tree!
Date: Tue, 16 Jan 2007 08:46:25 +0100 [thread overview]
Message-ID: <45AC82D1.1050609@gmx.at> (raw)
In-Reply-To: <45AC18F4.4@gmail.com>
> 1) I think I must search all buffers
No. Only the buffers that have an ovlwin-window association.
> 2) I must check all overlays in these buffers
Yes (unfortunately) but _only_ in the buffers mentioned above.
> 3) The only thing I have to check in the overlays is the 'window prop
Yes.
> 4) I only have to care if the prop value is a window in the saved tree
Yes.
> 5) If that window is not on a frame any more I just replace the value
Together steps 1) and 4) assert that the window is not on a frame any
more, hence, you don't have to check this.
> 6) Otherwise I make a new overlay -- seldom
_Never_ make a new overlay.
> The above is what I am doing. Is any of those points incorrect in your
> opinion? Here is the code:
>
> (dolist (buf (buffer-list))
`buffer-list' is bad. I'd use something like
(dolist (buf (let (buffer buffers)
(dolist (win win-list buffers)
;; I presume cadr refers to the "new" window.
(setq buffer (window-buffer (cadr win)))
(unless (memq buffer buffers)
(setq buffers (cons buffer buffers))))))
...
> (with-current-buffer buf
> (save-restriction
> (widen)
> (dolist (overlay (overlays-in (point-min) (point-max)))
> (when (setq ovlwin (car (memq (overlay-get overlay 'window)
> oldwins)))
> (setq window (cadr (assoc ovlwin win-list)))
> ;; If the old window is still alive then copy overlay,
> ;; otherwise change the 'window prop.
This should be something along the (100% incorrect)
(dolist (overlay (overlays-in (point-min) (point-max)))
(when (setq window (cadr (assoc (overlay-get overlay 'window))
win-list))
(overlay-put overlay 'window window)))
If the old window is still alive don't do anything. Windows that
survived the reconfiguration should not be on `win-list'.
> (if (not (and (window-live-p ovlwin)
> (window-frame ovlwin)))
> ....
>
> `oldwins' is a list with the old windows, ie the windows in the saved tree.
> I believe it would be possible to right code to manipulate the internal
> tree as above. A solution building on that would probably use the
> resizing part from my elisp solution (or something similar).
The only time and space consuming operation is finding the overlays and
changing their property. There's nothing you can do about that. Note
that current solutions (like `edebug-current-windows') ignore overlays
(and many other things like dedicated windows) completely. This could
be corrected with your algorithm, provided the save/restore step occurs
smoothly.
For `desktop-save', on the other hand, you should think of an option to
ignore overlays, though. Storing overlays on disk is hardly conceivable
as long as we don't even bother to save text properties.
next prev parent reply other threads:[~2007-01-16 7:46 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-13 10:11 MY window tree! martin rudalics
2007-01-14 9:35 ` Lennart Borgman (gmail)
2007-01-14 11:26 ` martin rudalics
2007-01-14 11:45 ` Lennart Borgman (gmail)
2007-01-14 15:03 ` Juanma Barranquero
2007-01-14 15:29 ` Lennart Borgman (gmail)
2007-01-14 17:41 ` martin rudalics
2007-01-14 17:56 ` Lennart Borgman (gmail)
2007-01-14 21:35 ` Lennart Borgman (gmail)
2007-01-14 22:57 ` Juanma Barranquero
2007-01-14 23:15 ` Lennart Borgman (gmail)
2007-01-15 7:27 ` martin rudalics
2007-01-15 13:07 ` Lennart Borgman (gmail)
2007-01-15 13:50 ` Juanma Barranquero
2007-01-15 14:09 ` Lennart Borgman (gmail)
2007-01-15 14:33 ` Juanma Barranquero
2007-01-15 14:41 ` Lennart Borgman (gmail)
2007-01-15 14:56 ` Juanma Barranquero
2007-01-15 16:32 ` Lennart Borgman (gmail)
2007-01-15 17:33 ` martin rudalics
2007-01-15 17:47 ` Lennart Borgman (gmail)
2007-01-15 17:58 ` martin rudalics
2007-01-15 18:16 ` Lennart Borgman (gmail)
2007-01-15 18:44 ` martin rudalics
2007-01-15 18:52 ` Lennart Borgman (gmail)
2007-01-15 17:26 ` martin rudalics
2007-01-15 17:56 ` Lennart Borgman (gmail)
2007-01-15 18:33 ` martin rudalics
2007-01-15 18:14 ` Lennart Borgman (gmail)
2007-01-15 19:22 ` martin rudalics
2007-01-15 20:26 ` Lennart Borgman (gmail)
2007-01-15 22:44 ` martin rudalics
2007-01-16 0:14 ` Lennart Borgman (gmail)
2007-01-16 7:46 ` martin rudalics [this message]
2007-01-16 10:32 ` Lennart Borgman (gmail)
2007-01-16 14:23 ` martin rudalics
2007-01-16 17:59 ` Lennart Borgman (gmail)
2007-01-16 18:32 ` martin rudalics
2007-01-16 18:57 ` Lennart Borgman (gmail)
2007-01-16 21:57 ` martin rudalics
2007-01-16 22:32 ` Lennart Borgman (gmail)
2007-01-17 6:36 ` martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2007-01-13 0:17 Michaël Cadilhac
2007-01-13 0:33 ` Lennart Borgman (gmail)
2007-01-13 0:46 ` Michaël Cadilhac
2007-01-13 1:24 ` Lennart Borgman (gmail)
[not found] ` <mailman.3023.1168651462.2155.help-gnu-emacs@gnu.org>
2007-01-13 6:17 ` Stefan Monnier
2007-01-13 9:20 ` Michaël Cadilhac
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45AC82D1.1050609@gmx.at \
--to=rudalics@gmx.at \
--cc=help-gnu-emacs@gnu.org \
--cc=michael@cadilhac.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).