Re: AW: AW: Bug in function window-list

Klaus> No, here i do not agree with you and Stephen. Reasons: Klaus> - Changing current `window-list' so it always returns a somehow canonical Klaus> ordered list is very simple and has really no disadvantage (at least as fas Klaus> i can see) Klaus> >Yes, it has, namely that people tend to then rely on that canonical Klaus> >order, even though it's not part of the natural specification---this Klaus> >makes it impossible to change later, should it become opportune to do Klaus> >so. (If it's one thing XEmacs history has taught us, then that's it, Klaus> >thank goodness.) Klaus> Hmm, IMHO a somehow "contructed" argument and disadvantage. Nonsense. Klaus> "`next-window' is a built-in function Klaus> (next-window &optional WINDOW MINIBUF WHICH-FRAMES WHICH-DEVICES) Klaus> Documentation: Klaus> Return the next window after WINDOW in the canonical ordering of windows. Klaus> If omitted, WINDOW defaults to the selected window. Klaus> ..." Klaus> You see the word "canonical"??!! Yes, I do. You see that word somewhere in the documentation or name for `window-list'? Klaus> If i understand you right then you say it is best to make no Klaus> specification for API-functions on which programmers can rely Klaus> because maybe someone wants to change it later and then all Klaus> already existing code fails or has to be rewritten, right? No, you didn't understand me right. I didn't say anything of the sort. `window-list' already has a specification, and there's no good reason to change it, because there's no existing code that assumes a different specification from it. If you want a function with a different behavior, by all means write it and give it a name indicative of what it does. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla