emacs-map

Bug

I encountered this bug:

a (re) MapWindow-ed emacs frame (for example on returning to a workplace) contains the previous content, before being (immediately) redrawn.

How to reproduce:

Best seen w/ Colors buffer. I have a fix: emacs distinguishes de-iconifying and some other state from which it could be remapped.

Initial hypothesis

I think that a bug I see w/ cvs emacs depends on the WM behaviour

But ICCM does not talk about any other state which the WM can set!

notes (from IRC)

we talk about src/xterm.c:

my WM unmaps the X window (when it leaves the workspace). And the UnmapNotify does: if (FRAME_VISIBLE_P (f) OR ...) f->async_iconified = 1;
now I see how f->async_visible is a "forerunner" of ->visible. case UnmapNotify: sets async_visible = 0, and then tests FRAME_VISIBLE_P (which uses ->visible which is still 1), so this happens:
```
 f->async_iconified=1
```

Before searching for a way to detect properly

that I don't iconify (and avoid this async_iconified=1), I would like to understand the comment in the case MapNotify: why " If we were iconified ...we should not set garbaged" ? What is the difference between simple reMapping and deiconifying?

But, w/ my new patch, emacs thinks that the only frame in a Sawfish desktop/workspace

CVS Emacs tries to be smarter than Sawfish: it warns about the only mapped frame, when it is the only frame in a Sawfish's "workplace". This is because sawfish does not "iconify" the window, but simply unmaps, and I had to remove code from emacs which equates "iconified" = "unmapped". I had to remove it, b/c emacs does not set frame_garbagged when an iconified window is uniconified, so

Updated: 2006-02-01

Home / Index Agenzia matrimoniale Maruska google rev