From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
Cc: help-gnu-emacs@gnu.org, michael@cadilhac.name
Subject: Re: MY window tree!
Date: Tue, 16 Jan 2007 01:14:44 +0100 [thread overview]
Message-ID: <45AC18F4.4@gmail.com> (raw)
In-Reply-To: <45AC03E2.5080109@gmx.at>
martin rudalics wrote:
> > If not so, then do I not have to look at all overlays in all buffers?
>
> You should look only at the overlays of buffers whose windows have
> "changed". That is, all buffers where a ovlwin-window association
> exists such that window displays the buffer.
>
> I think that after running winsav to its end you have four cases:
>
> The window existed before and exists now. Ignore it. It's the same
> window and any overlays referencing it before still reference it.
>
> The window did not exist before but exists now. Since you do not
> arbitrarily create new windows there must be a ovlwin-window
> association and the associated buffer's overlays may have to be
> updated.
>
> The window existed before and doesn't exist now (probably because it
> was discarded during splitting). Ignore it. Any overlay referencing
> that window won't be displayed in any other window.
>
> The window didn't exist before and doesn't now. Ignore it trivially.
Maybe you are saying something that I am missing, but I believe I am
doing what you propose already. Some questions/points to see if we agree:
1) I think I must search all buffers
2) I must check all overlays in these buffers
3) The only thing I have to check in the overlays is the 'window prop
4) I only have to care if the prop value is a window in the saved tree
5) If that window is not on a frame any more I just replace the value
6) Otherwise I make a new overlay -- seldom
The above is what I am doing. Is any of those points incorrect in your
opinion? Here is the code:
(dolist (buf (buffer-list))
(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.
(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.
> Initially you didn't want to bother about overlays at all, now you want
> to check overlays in all buffers.
True, I was not aware of that they could point to windows.
> Initially you wanted to convince me
> that you can do it in Lisp, now that you have nearly done it, you favor
> a solution in C.
In the short term I think this solution is good enough. And it actually
can do a bit more than a solution in C that gives handles to manipulate
the internal C window tree.
> Alas, this will be hardly ever done in C, the window
> related code is too hairy.
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).
> Yours could be perfect (if you just removed
> the make-overlay stuff).
It could be Good Enough ;-)
next prev parent reply other threads:[~2007-01-16 0:14 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) [this message]
2007-01-16 7:46 ` martin rudalics
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=45AC18F4.4@gmail.com \
--to=lennart.borgman@gmail.com \
--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).