>>>>> Joost Kremers writes: > In two recent threads, one here ("Window splitting issues with margins") and > one on bugs.gnu.emacs (bug 22009), some issues were discussed with window > margins that could stand improvement. Two issues specifically came up[...] Hi Joost, I appreciate your willingness to grapple with this problem. Something feels overly complex, however, about trying to satisfy the needs of various modes (linum, darkroom, etc) in this way. It sounds you are trying to adapt an existing mechanism to a specific need, but this will lead to both a more complex mechanism, and more unmet needs in future. This all makes me wonder whether our notion of "window" has become outdated, based on what new authors are trying to make Emacs do. Richard has long wanted better WYSIWYG behavior from Emacs, and these issues seem to underscore our lack of support for such behavior. Perhaps what we need is a richer notion of "window", with multiple sub-areas, some for content, some for positioning, etc. This would make it possible to define exactly what the appearance of a window should be, at a pixel level. Given such a mechanism, fringes and margins would be distinguished merely as different display areas within a window, rather than being the first-class entities they are now. (For example, variables like `fringes-outside-margins' would not be necessary, if one were able to manipulate such display areas in a general fashion). I strongly want to avoid extending the APIs of long-standing capabilities -- such as windows and frames -- just to make new features possible, or to enable cooperation among non-core modes. If we're going to submit to that sort of pain, it's worth considering what sort of design we'd if we had the freedom to do it all over again. Then we can think of how to adapt such a clean-slate approach into our existing environment. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2