Stefan Monnier wrote: > So it might seem too early to document them in the Emacs manual.
I think the main reason why they're unused is that they're completely undocumented. I'd love to see some rough documentation for it. In the patches I sent, I provided documentation in the buffers created by `custom-create-theme'. If people decide that after my patches it works reliably enough for their purposes to be ready to be documented in the Emacs manual, I could document it there. Probably most people will only test my patches _after_ they are applied, so I would propose to apply them rather soon. I will at least wait until Richard has had time to comment. It will hopefully help us all better understand the feature and improve it (especially the UI part). I believe my patches add some improvement to the UI part. But I believe that there also is the problem of bugs in the basic code. I think even a somewhat incorrect documentation would be a good thing because it would hopefully give us bug-reports that'll help us improve both the code and the doc. The bugs seem numerous and the basic philosophy behind Custom Themes is not clear. I believe that the present code is the result of two people _independently_ porting XEmacs code. The result looks like three superimposed implementation philosophies fighting with each other. In the text accompanying my patch, I pointed out two bugs remaining after my patches. I can easily fix at least one of the two, but not without adding a fourth conflicting implementation philosophy, which I want to avoid. I only fixed the bugs I believed I could fix without doing that. I do not understand at all the philosophy behind using a `require' type interface to adding themes rather than an unconditional load type philosophy. If I had to implement themes from scratch, my philosophy would be that if two loaded themes conflict, then the most recently added one takes precedence. If you remove the most recently added theme, then the theme added just before that one becomes "top dog". This would seem simple and intuitive. This requires unconditional loading as the basic theme adding operation. But the current code desperately seems to want to implement something else. I have no idea why or what the "something else" could possibly be. I do not use XEmacs and I do not know whether the XEmacs version is actually in active use and works according to some consistent philosophy. I do not know how important compatibility with XEmacs in the Emacs Custom Themes implementation. My patches mainly improve the UI. They avoid touching the basic implementation philosophy (which I do not understand, assuming there is one). Hence, they can not fix the bugs in that implementation. Sincerely, Luc. _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
