* IRC Client for Emacs @ 2002-08-24 4:32 Jonathan Walther 2002-08-24 5:11 ` Damien Elmes ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Jonathan Walther @ 2002-08-24 4:32 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 757 bytes --] Please consider this my vote for the ERC irc client. I've been using it for more than 6 months now, and love it. I have found it easy to use with no special configuration; (require 'erc) is all I needed to do. Never could wrap my head around ZenIRC May I also take this time to ask that color-theme.el be added to the Emacs distribution. Jonathan -- Geek House Productions, Ltd. Providing Unix & Internet Contracting and Consulting, QA Testing, Technical Documentation, Systems Design & Implementation, General Programming, E-commerce, Web & Mail Services since 1998 Phone: 604-435-1205 Email: djw@reactor-core.org Webpage: http://reactor-core.org Address: 2459 E 41st Ave, Vancouver, BC V5R2W2 [-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --] ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRC Client for Emacs 2002-08-24 4:32 IRC Client for Emacs Jonathan Walther @ 2002-08-24 5:11 ` Damien Elmes 2002-08-24 16:50 ` color-theme.el Alex Schroeder 2002-08-25 5:27 ` IRC Client for Emacs Richard Stallman 2 siblings, 0 replies; 28+ messages in thread From: Damien Elmes @ 2002-08-24 5:11 UTC (permalink / raw) Jonathan Walther <krooger@debian.org> writes: > Please consider this my vote for the ERC irc client. I've been using it > for more than 6 months now, and love it. I have found it easy to use with > no special configuration; (require 'erc) is all I needed to do. Never > could wrap my head around ZenIRC > > May I also take this time to ask that color-theme.el be added to the > Emacs distribution. Make that another vote for ERC and color-theme :-) -- Damien Elmes ^ permalink raw reply [flat|nested] 28+ messages in thread
* color-theme.el 2002-08-24 4:32 IRC Client for Emacs Jonathan Walther 2002-08-24 5:11 ` Damien Elmes @ 2002-08-24 16:50 ` Alex Schroeder 2002-08-26 12:45 ` color-theme.el Per Abrahamsen 2002-08-25 5:27 ` IRC Client for Emacs Richard Stallman 2 siblings, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-08-24 16:50 UTC (permalink / raw) Jonathan Walther <krooger@debian.org> writes: > May I also take this time to ask that color-theme.el be added to the > Emacs distribution. A long time ago, I tried fiddling with the source Jan Vroonhofer wrote for XEmacs in order to integrate "themes" with custom. I also sent the code to Dave Love at the time. My color-theme.el does not use this custom theme stuff, it implements themes by just redefining faces, frame parameters, etc. And I don't feel like getting the custom-theme stuff to work anymore. As far as I am concerned, these last years have shown that there is just no need for that. One minor problem that remains unsolved (but which I do not care about) is non-perfect "undoing". "undoing" the installation of a theme happens by storing away snapshots of the faces and frame parameters currently defined. Invariably, this leads to small inconsistencies. Example: Emacs starts, n faces are defined. When install a color-theme, this creates a snapshot with n faces and installs the new theme. This theme probably defines m faces, where m > n. When we uninstall the theme, n faces are reset (because only n are stored in the snapshot). The new faces (m - n) remain as defined in the theme. Anyway, that is the current situation. As to the paperwork, I have the email addresses of all theme authors on file, so I could arrange the paperwork. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-24 16:50 ` color-theme.el Alex Schroeder @ 2002-08-26 12:45 ` Per Abrahamsen 2002-08-27 19:05 ` color-theme.el Richard Stallman 2002-08-27 23:18 ` color-theme.el Alex Schroeder 0 siblings, 2 replies; 28+ messages in thread From: Per Abrahamsen @ 2002-08-26 12:45 UTC (permalink / raw) Alex Schroeder <alex@emacswiki.org> writes: > And I don't feel like getting the custom-theme stuff to work > anymore. As far as I am concerned, these last years have shown that > there is just no need for that. I think there is plenty of need, but nobody both able and willing to do the work. I tried to re-sync custom with the XEmacs version a couple of years ago (which would have got us themes), and quickly burned out. So while I believe color-theme.el is the wrong solution, it is better than the alternative, which is no solution. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-26 12:45 ` color-theme.el Per Abrahamsen @ 2002-08-27 19:05 ` Richard Stallman 2002-08-28 14:19 ` color-theme.el Per Abrahamsen 2002-08-27 23:18 ` color-theme.el Alex Schroeder 1 sibling, 1 reply; 28+ messages in thread From: Richard Stallman @ 2002-08-27 19:05 UTC (permalink / raw) Cc: emacs-devel So while I believe color-theme.el is the wrong solution, it is better than the alternative, which is no solution. What do you think is the right solution? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-27 19:05 ` color-theme.el Richard Stallman @ 2002-08-28 14:19 ` Per Abrahamsen 2002-08-28 23:33 ` color-theme.el Richard Stallman 0 siblings, 1 reply; 28+ messages in thread From: Per Abrahamsen @ 2002-08-28 14:19 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > So while I believe color-theme.el is the wrong solution, it is better > than the alternative, which is no solution. > > What do you think is the right solution? Integrate real themes, a.la. Jan Vroonhofs work. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 14:19 ` color-theme.el Per Abrahamsen @ 2002-08-28 23:33 ` Richard Stallman 2002-08-29 11:55 ` color-theme.el Per Abrahamsen 2002-08-29 17:14 ` color-theme.el Alex Schroeder 0 siblings, 2 replies; 28+ messages in thread From: Richard Stallman @ 2002-08-28 23:33 UTC (permalink / raw) Cc: emacs-devel Integrate real themes, a.la. Jan Vroonhofs work. What is better about that? Would it provide more features (which), work more reliably, be less code, or what? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 23:33 ` color-theme.el Richard Stallman @ 2002-08-29 11:55 ` Per Abrahamsen 2002-08-29 17:14 ` color-theme.el Alex Schroeder 1 sibling, 0 replies; 28+ messages in thread From: Per Abrahamsen @ 2002-08-29 11:55 UTC (permalink / raw) Cc: emacs-devel Richard Stallman <rms@gnu.org> writes: > Integrate real themes, a.la. Jan Vroonhofs work. > > What is better about that? Would it provide more features (which), > work more reliably, be less code, or what? See my answer to Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 23:33 ` color-theme.el Richard Stallman 2002-08-29 11:55 ` color-theme.el Per Abrahamsen @ 2002-08-29 17:14 ` Alex Schroeder 2002-08-30 19:17 ` color-theme.el Richard Stallman 1 sibling, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-08-29 17:14 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > Integrate real themes, a.la. Jan Vroonhofs work. > > What is better about that? Would it provide more features (which), > work more reliably, be less code, or what? There are two main advantages. Here is how it basically works: A setting is tagged as coming from a theme. The settings currently loaded from .emacs or similar would be tagged as coming from the "user" theme, and the standard values would be tagged as coming from the "standard" theme. Authors could now write additional themes. Anytime a variable is set via custom or themes, this is recorded. Advantage 1: When you customize variabes that where set via a theme, the custom buffer could offer more information. I faintly remember that it currently just says that it was set using a theme. But it could name the theme, or even all the installed themes that tried setting the variable (and the current value would be from the last theme installed). Advantage 2: When you undo a theme, custom can set the variable to something else than the standard value or the saved (user) value. It can set it to the second-to-last installed theme, for example. Or, putting it another way, assume a variable foo with a default value of A. The user customizes it to B and saves this. In his .emacs, the user then loads two themes, "theme 1" and "theme 2". The first sets foo to C, the second sets foo to D. The value of foo is now D. When "theme 2" is undone, the value will be C. Currently (and if we followed my much simple suggestions), the same situation would result in a different end: When Emacs starts, foo is eventually set to D. If you want to go back to the second-to-last value (C), you might want to undo "theme 2". But there is no way to undo "theme 2", except to install "theme 1" again. Custom would only know the current value (D), the saved value (B) and the standard value (A). My position is that this is no great loss. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-29 17:14 ` color-theme.el Alex Schroeder @ 2002-08-30 19:17 ` Richard Stallman 2002-08-31 11:38 ` color-theme.el Alex Schroeder 0 siblings, 1 reply; 28+ messages in thread From: Richard Stallman @ 2002-08-30 19:17 UTC (permalink / raw) Cc: emacs-devel It sounds like the big difference is that "real" themes handle customizable variables (and face attributes?), whereas color-theme.el just handles themes. Is that a correct description? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-30 19:17 ` color-theme.el Richard Stallman @ 2002-08-31 11:38 ` Alex Schroeder 2002-09-01 13:14 ` color-theme.el Richard Stallman 0 siblings, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-08-31 11:38 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > It sounds like the big difference is that "real" themes handle > customizable variables (and face attributes?), whereas color-theme.el > just handles themes. Is that a correct description? Hm. Not really. Let me try to put it in your terms. "real" themes can set customizable variables and customizable face attributes, *plus* it can undo these settings when a theme is uninstalled. color-theme.el can set any variables, any face attributes, and frame parameters, but no undoing of themes. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-31 11:38 ` color-theme.el Alex Schroeder @ 2002-09-01 13:14 ` Richard Stallman 2002-09-01 16:07 ` color-theme.el Alex Schroeder 0 siblings, 1 reply; 28+ messages in thread From: Richard Stallman @ 2002-09-01 13:14 UTC (permalink / raw) Cc: emacs-devel "real" themes can set customizable variables and customizable face attributes, *plus* it can undo these settings when a theme is uninstalled. color-theme.el can set any variables, any face attributes, and frame parameters, but no undoing of themes. If that is the difference, then does the suggestion I sent in a previous message on Aug 31 take care of doing it? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-09-01 13:14 ` color-theme.el Richard Stallman @ 2002-09-01 16:07 ` Alex Schroeder 2002-09-07 14:15 ` color-theme.el Alex Schroeder 0 siblings, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-09-01 16:07 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > "real" themes can set customizable variables and customizable face > attributes, *plus* it can undo these settings when a theme is > uninstalled. > > color-theme.el can set any variables, any face attributes, and frame > parameters, but no undoing of themes. > > If that is the difference, then does the suggestion I sent in a previous > message on Aug 31 take care of doing it? The existing code takes care of theme undoing, just as your suggestion probably would. Neither of them can install frame parameters, however. Then again, I don't know wether there are any settings in Emacs 21 that can only be set via frame parameters. All the settings people use in color themes such as background-color, foreground-color, cursor-color, and font can be set via faces. The things we still cannot set via faces or variables are not significant for color-themes (frame sizes, for example). If you really want undoing of themes, then your best bet is to take the custom code that Dave Love has. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-09-01 16:07 ` color-theme.el Alex Schroeder @ 2002-09-07 14:15 ` Alex Schroeder 2002-09-09 0:21 ` color-theme.el Richard Stallman 0 siblings, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-09-07 14:15 UTC (permalink / raw) Alex Schroeder <alex@emacswiki.org> writes: > If you really want undoing of themes, then your best bet is to take > the custom code that Dave Love has. What is the current status of this? Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-09-07 14:15 ` color-theme.el Alex Schroeder @ 2002-09-09 0:21 ` Richard Stallman 0 siblings, 0 replies; 28+ messages in thread From: Richard Stallman @ 2002-09-09 0:21 UTC (permalink / raw) Cc: emacs-devel > If you really want undoing of themes, then your best bet is to take > the custom code that Dave Love has. What is the current status of this? I asked Dave to send it to me and to you. He responded "Alex who?" and told me how to get diffs from CVS myself. However, I have not been in a situation where I can stay on the net long enough to do that. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-26 12:45 ` color-theme.el Per Abrahamsen 2002-08-27 19:05 ` color-theme.el Richard Stallman @ 2002-08-27 23:18 ` Alex Schroeder 2002-08-28 14:37 ` color-theme.el Per Abrahamsen 1 sibling, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-08-27 23:18 UTC (permalink / raw) Per Abrahamsen <abraham@dina.kvl.dk> writes: > I think there is plenty of need, but nobody both able and willing to > do the work. I tried to re-sync custom with the XEmacs version a > couple of years ago (which would have got us themes), and quickly > burned out. Since RMS is interested, let me explain my position. I worked on porting the XEmacs code by Jan Vroonhof to Emacs, so I know something about the code. (I actually met him in person in Zuerich before doing it!) I think the code is complex. I really tried to make it happen. I even proposed a solution to make alists customizable. This was one of the open problems. And yet, I am convinced that we do not need this complexity. We should not bother. Why? First, let us look at the kind of effort involved in using cus-theme.el. To create a theme involves about as much work as writing a setq statement for all the variables, and giving this collection of settings a name. So for an author, there is no benefit compared to writing a defun. The defun has a name and can set tons of variables. The benefit for users is that undoing the theme is straightforward. Now, let us look at the scenarios where this is going to be used. One of the examples cited is that authors at big sites could prepare themes so that their users can selectively do and undo the site settings. But how many users are there that actually need this? Power users will skip the site code and do it all in their own .emacs file. Newbies will rely on the site code. In the few cases, where more choice is involved, big sites have already done the correct thing: They offer a collection of functions that users can call from their .emacs to selectively install parts of the site configuration. If this is the only benefit, however, then perhaps we are better off with another solution altogether: Let us create a new list of functions to call at startup. Let us call it `startup-functions'. Let us make this customizable. Now site authors can install a suitable default, and users can still customize it to their liking. The customizations will be saved to their .emacs file. Problem solved! And the solution was easy to understand. Now let us look at another problem. For example my problem <grin>: A color theme package. What is the requirement? People want to call a function that sets lots of faces and variables. People might want to undo this once or twice. Well, using the existing custom machinery, I was able to implement this easily! Problem solved! People do not want to do fancy stuff with themes. Just setting the variables is enough. And even simple undoing the settings is possible, because we have the normal custom stuff in place. Sure, this does not solve the problem of people installing themes A, B, and C, and then undoing the settings of B. What settings should be used now? Something equivalent to installing only A and C. But do users really want this? My claim is that they do not. cus-theme.el is going for the perfect solution, but nobody needs it enough to fix it. This holds, eventhough there is very little fixing to do. When I finished porting the code, it worked. All I asked for was some testing, and for some feedback for the alist customizing (I called them diff-lists at the time). It does not even matter wether Dave Love looked at the code or not -- nobody ever asked about it anyway! Thus I conclude that nobody is suffering from a problem. Note that the totally perfect solution would use cus-theme.el, and implemented some UI for theme authors. Currently nobody seems to have such ideas. I faintly remember that I used a widget for simple theme creation at the time. But nobody tested that, either. And guess what? My color-theme.el provides a possibility to save a snapshot of the current configuration. Thus M-x customize-faces suddenly is the interface to produce new themes. What else could a user possibly want. So not even that is really needed. Thus here is my opinion on the cus-theme.el efforts: Implementing the perfect solution took effort (cus-theme.el, my simple make-theme.el), still is not finished (a more elaborate UI might be required, real testing), is not required for power users, is not required for newbies, does not help site administrators, does not improve the color-theme.el experience, is not asked for in the newsgroups. "As far as I am concerned, these last years have shown that there is just no need for that." Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-27 23:18 ` color-theme.el Alex Schroeder @ 2002-08-28 14:37 ` Per Abrahamsen 2002-08-28 18:37 ` color-theme.el Alex Schroeder 0 siblings, 1 reply; 28+ messages in thread From: Per Abrahamsen @ 2002-08-28 14:37 UTC (permalink / raw) Cc: emacs-devel Alex Schroeder <alex@emacswiki.org> writes: > Per Abrahamsen <abraham@dina.kvl.dk> writes: > > First, let us look at the kind of effort involved in using > cus-theme.el. To create a theme involves about as much work as > writing a setq statement for all the variables, and giving this > collection of settings a name. So for an author, there is no benefit > compared to writing a defun. The defun has a name and can set tons of > variables. The benefit for users is that undoing the theme is > straightforward. Jan Vroonhofs code is only the first (Lisp) step, the second step would be to add theme commands to the customize UI, like "add setting to theme", and "save theme". This would allow users with no knowledge of Lisp to create and share customizations, and, in my opinion, give them a first taste of the free software culture of sharing. They already do this, but they share entire "customize-set-variables" sections, which we know doesn't work well. > If this is the only benefit, It isn't. Large packages like Gnus can offer "build-in" themes for e.g. slow and fast connections, and fancy and boring display (which in Gnus involves much more than just faces). Emacs itself could come with some themes, such as an "Emacs 20" theme for people who dislike the UI changes in Emacs 21. > however, then perhaps we are better off with another solution > altogether: Let us create a new list of functions to call at > startup. Let us call it `startup-functions'. Let us make this > customizable. Now site authors can install a suitable default, and > users can still customize it to their liking. The customizations > will be saved to their .emacs file. Problem solved! And the > solution was easy to understand. The problem is that any individual option set by "setq" from a funtion in such a list will overwrite the users individual customization of that item. With Jans themes it is the other way around, the explicit individual settings will overwrite the the settings. This benefit come both from package themes, other users themes, and site themes. They could all be done with functions and setq, but Jans themes makes it possible to prioritize them when they conflict, and overwrite individual options. > "As far as I am concerned, these last years have shown that there is > just no need for that." I don't think you can scale the experience gained from the existence of an unbundled package, to themes being integrated in Emacs. Hopefully, the later will mean many more themes will be available, with increasing need for conflict resolution and overwriting individual choises. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 14:37 ` color-theme.el Per Abrahamsen @ 2002-08-28 18:37 ` Alex Schroeder 2002-08-29 12:12 ` color-theme.el Per Abrahamsen 2002-08-31 16:58 ` color-theme.el Richard Stallman 0 siblings, 2 replies; 28+ messages in thread From: Alex Schroeder @ 2002-08-28 18:37 UTC (permalink / raw) Per Abrahamsen <abraham@dina.kvl.dk> writes: > Jan Vroonhofs code is only the first (Lisp) step, the second step > would be to add theme commands to the customize UI, like "add setting > to theme", and "save theme". I had a very simple UI that would allow me to specify the variables that are part of the theme, the name of theme, and a file name. It would then save the appropriate lisp code. It was trivial. > This would allow users with no knowledge of Lisp to create and share > customizations, and, in my opinion, give them a first taste of the > free software culture of sharing. They already do this, but they > share entire "customize-set-variables" sections, which we know > doesn't work well. I think we could write something like that without the need for cus-theme.el. A wizard using widget.el that lets you specify the variables that are part of the theme, the name of theme, and a file name. It would then save the appropriate lisp code -- a bunch of setq statements (in a defun, with appropriate call to `provide'). We would then modify the `startup-functions' idea I presented in an earlier mail: Let it be called `startup-requires'. Users could then save the file with the generated setq statements in their load-path, and customize `startup-requires' such that the appropriate theme is loaded, and the variables are set, at startup time. This would provide the user experience you describe, with very little work required. > Large packages like Gnus can offer "build-in" themes for e.g. slow > and fast connections, and fancy and boring display (which in Gnus > involves much more than just faces). Emacs itself could come with > some themes, such as an "Emacs 20" theme for people who dislike the > UI changes in Emacs 21. Sure -- but do we need the real theme code, with precedences, selective uninstalling, etc? Would a bunch of setq not do the job? You think it would not, I think it would. I don't think we can decide that at the moment. The only thing I know is that I have not seen any requests for it, in the limited time I spend on the newsgroups these days. > The problem is that any individual option set by "setq" from a funtion > in such a list will overwrite the users individual customization of > that item. With Jans themes it is the other way around, the explicit > individual settings will overwrite the the settings. If we want that, let the customization of `startup-requires' be the first thing acted upon when doing customization. Then individual settings will still overwrite stuff installed via startup-requires. > I don't think you can scale the experience gained from the existence > of an unbundled package, to themes being integrated in Emacs. Well, if I cannot generalize it from the existing themes I maintain, who is going to offer an opinion? Nobody else is maintaining anything like it. We could compare it to Gnus group parameters, perhaps. These are also settings saved outside of .emacs and custom. Or the .newsrc.el file. But I find it difficult to draw conclusions from it. It seems to me that my basis for prediction is small, but everybody else's basis is even smaller. > Hopefully, the later will mean many more themes will be available, > with increasing need for conflict resolution and overwriting > individual choises. I'm not sure how conflict resolution will actually improve. I think the user experience will turn out to be something like this: A: Why does this and that not work? B: What themes do you have installed? A: X and Y. B: Ah, these conflict, you must uninstall one of them. A: Oh. If so, then this user experience can be had using my simple idea I offered at the top, using a widget to save setq in files, take advantage of the require/provide conventions, introducing the new option startup-requires, which means adding a bit of code to the place where .emacs is read, and adding a bit of code to the place where customizations are saved. That seems to be far less than the entire cus-theme.el stuff. And I am saying these eventhough I ported Jan's code from XEmacs to Emacs! Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 18:37 ` color-theme.el Alex Schroeder @ 2002-08-29 12:12 ` Per Abrahamsen 2002-08-31 16:58 ` color-theme.el Richard Stallman 1 sibling, 0 replies; 28+ messages in thread From: Per Abrahamsen @ 2002-08-29 12:12 UTC (permalink / raw) Alex Schroeder <alex@emacswiki.org> writes: > Well, if I cannot generalize it from the existing themes I maintain, > who is going to offer an opinion? Everyone can offer an opinion, but nobody can do so based on realistic empirical data, as no such data exists. It is basically a question of intuition how popular themes are going to be, and what they will be used for. Your scheme won't integrate cleanly with customize (the option will be marked "rogue", i.e. "option is changed outside customize"), which is my major emotional problem with it. It will make customize less useful than now, when another major customization feature doesn't "play nice" with it. > And I am saying these eventhough I ported Jan's code from XEmacs to > Emacs! I did so too, at least the Lisp part. I remember writing ChangeLogs for them once. Unrelated to what is best, having different schemes for Emacs and XEmacs is certainly going to make them both much less useful. Especially for cross-platform packages like Gnus. But as I said before, if nobody is actually going to do the work of integrating Jan's themes in GNU Emacs, your stuff is better than nothing. And since I'm not volunteering (again) and you are, your opinion should carrry more weight. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-28 18:37 ` color-theme.el Alex Schroeder 2002-08-29 12:12 ` color-theme.el Per Abrahamsen @ 2002-08-31 16:58 ` Richard Stallman 2002-09-01 0:05 ` color-theme.el Alex Schroeder 2002-09-07 14:17 ` color-theme.el Alex Schroeder 1 sibling, 2 replies; 28+ messages in thread From: Richard Stallman @ 2002-08-31 16:58 UTC (permalink / raw) Cc: emacs-devel I think we could write something like that without the need for cus-theme.el. A wizard using widget.el that lets you specify the variables that are part of the theme, the name of theme, and a file name. It would then save the appropriate lisp code -- a bunch of setq statements (in a defun, with appropriate call to `provide'). We would then modify the `startup-functions' idea I presented in an earlier mail: Let it be called `startup-requires'. Users could then save the file with the generated setq statements in their load-path, and customize `startup-requires' such that the appropriate theme is loaded, and the variables are set, at startup time. This would provide the user experience you describe, with very little work required. This may not be a very large job, but the first part is not trivial--do you want to do it? As for the feature of using multiple themes, of being able to add and remove themes from the list and have the right thing happen, I think I see an easy way to add that. We just have to make sure that each theme function saves the old values of the variables that it sets, so that it can "turn itself off" later on. Then, when the user edits the list of currently enabled themes, here's what you do. You turn off all the themes in the list, in reverse order. You change the list. Then you turn on the themes that are now in the list. > The problem is that any individual option set by "setq" from a funtion > in such a list will overwrite the users individual customization of > that item. With Jans themes it is the other way around, the explicit > individual settings will overwrite the the settings. If we want that, let the customization of `startup-requires' be the first thing acted upon when doing customization. That would work at startup. To make it work right for editing the list later would take a little more. These theme functions could carefully avoid setting variables that are marked as customized. This probably means that instead of using setq directly, they should use a macro `theme-setq' to set each variable. The macro would take care of recording the old value, not setting variables that are customized, etc. Would this give equivalent benefits to cus-theme.el? Your scheme won't integrate cleanly with customize (the option will be marked "rogue", i.e. "option is changed outside customize"), which is my major emotional problem with it. Would it be difficult to create a new status value, "set by a theme"? theme-setq could mark the variable with this status. Meanwhile, would anyone be willing to step forward to integrate cus-theme.el into Emacs? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-31 16:58 ` color-theme.el Richard Stallman @ 2002-09-01 0:05 ` Alex Schroeder 2002-09-02 0:01 ` color-theme.el Richard Stallman 2002-09-07 14:17 ` color-theme.el Alex Schroeder 1 sibling, 1 reply; 28+ messages in thread From: Alex Schroeder @ 2002-09-01 0:05 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > This may not be a very large job, but the first part is not > trivial--do you want to do it? I might want to do this; however... > As for the feature of using multiple themes, of being able to add and > remove themes from the list and have the right thing happen, I think I > see an easy way to add that. We just have to make sure that each > theme function saves the old values of the variables that it sets, so > that it can "turn itself off" later on. If you want the feature, then we should test and use the cus-theme.el I sent to Dave Love some time ago. My argument was that we did not need the feature, therefore why bother with the code. If you want the feature, however, then there is no use in reinventing it. We might as well use the existing code. As to color-theme.el, I therefore propose not to add it until cus-theme.el is working. Then we can use color-theme.el as the first major test for the cus-theme.el code. > Your scheme won't integrate cleanly with customize (the option will be > marked "rogue", i.e. "option is changed outside customize"), which is > my major emotional problem with it. > > Would it be difficult to create a new status value, "set by a theme"? > theme-setq could mark the variable with this status. I think cus-theme.el does this, but I am not sure anymore. I currently do not have the code. I wiped my disk at Easter by accident and lost a lot of stuff. And I did not do backups. So I'd have to ask Dave Love for a copy, or find an archive of the custom mailing list. I will mail Dave to see wether he still has it. > Meanwhile, would anyone be willing to step forward to integrate > cus-theme.el into Emacs? The first step would be to install the code locally and play with it. The work has already been done. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-09-01 0:05 ` color-theme.el Alex Schroeder @ 2002-09-02 0:01 ` Richard Stallman 2002-09-02 20:37 ` color-theme.el Alex Schroeder 0 siblings, 1 reply; 28+ messages in thread From: Richard Stallman @ 2002-09-02 0:01 UTC (permalink / raw) Cc: emacs-devel > As for the feature of using multiple themes, of being able to add and > remove themes from the list and have the right thing happen, I think I > see an easy way to add that. We just have to make sure that each > theme function saves the old values of the variables that it sets, so > that it can "turn itself off" later on. If you want the feature, then we should test and use the cus-theme.el I sent to Dave Love some time ago. Are you saying that cus-theme.el is a simple implementation of this feature, and nothing more? If that's the case, then it does seem like this could be the code to use. However, the other things that have been said about cus-theme.el give the impression that it is not so simple. Could you tell me what you think on this particular question? Dave, could you email me the cus-theme.el file that Alex sent you, so I can take a look for myself? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-09-02 0:01 ` color-theme.el Richard Stallman @ 2002-09-02 20:37 ` Alex Schroeder 0 siblings, 0 replies; 28+ messages in thread From: Alex Schroeder @ 2002-09-02 20:37 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > Are you saying that cus-theme.el is a simple implementation of this > feature, and nothing more? cus-theme.el is an implementation of this complex feature. Every customizable variable has a property has an alist that associates themes with value like a history. > If that's the case, then it does seem like this could be the code to > use. However, the other things that have been said about > cus-theme.el give the impression that it is not so simple. Well, cus-theme.el implements a complex feature. I did not want to argue against cus-theme.el because its implementation was byzantine. I argued against cus-theme.el because it implements a feature that is useless to most if not all users. Other people such as Per seem to want this feature, and you offered an idea to implement this feature. If people want his feature, then cus-theme.el is the way to go. In fact, all other solutions will eventually do what cus-theme.el already does. Therefore I think cus-theme.el is our best bet -- *if* we want this feature. cus-theme.el will need some improvements eventually to be able to use this feature to its fullest. Integrating cus-theme.el will allow us to build on it, improve it, and use it for applications such as color-theme.el -- since I will switch to using cus-theme.el if and only if it is integrated into Emacs. Eventhough cus-theme.el is currently not perfect, it fails in ways that custom generally fails already: alists (default-frame-alist and friends in particular) are problematic, frame local variables are not supported, the only user interface that allows users to create themes without writing the elisp by hand is my make-theme, which is very simple, and there is currently no user interface (except for calling the relevant commands manually using M-x) to manage themes (installing and deinstalling them). > Dave, could you email me the cus-theme.el file that Alex sent you, so > I can take a look for myself? You will need all the other cus*.el files as well, because they are all affected. Remeber, all variables and faces now maintain an alist of theme-value associations. Alex. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-31 16:58 ` color-theme.el Richard Stallman 2002-09-01 0:05 ` color-theme.el Alex Schroeder @ 2002-09-07 14:17 ` Alex Schroeder 1 sibling, 0 replies; 28+ messages in thread From: Alex Schroeder @ 2002-09-07 14:17 UTC (permalink / raw) Richard Stallman <rms@gnu.org> writes: > I think we could write something like that without the need for > cus-theme.el. A wizard using widget.el that lets you specify the > variables that are part of the theme, the name of theme, and a file > name. It would then save the appropriate lisp code -- a bunch of setq > statements (in a defun, with appropriate call to `provide'). >> > This may not be a very large job, but the first part is not > trivial--do you want to do it? Sure. If we do not use cus-theme, that would be very handy for sharing settings. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRC Client for Emacs 2002-08-24 4:32 IRC Client for Emacs Jonathan Walther 2002-08-24 5:11 ` Damien Elmes 2002-08-24 16:50 ` color-theme.el Alex Schroeder @ 2002-08-25 5:27 ` Richard Stallman 2002-08-25 13:38 ` color-theme.el Alex Schroeder 2 siblings, 1 reply; 28+ messages in thread From: Richard Stallman @ 2002-08-25 5:27 UTC (permalink / raw) Cc: emacs-devel May I also take this time to ask that color-theme.el be added to the Emacs distribution. What does this do, and how can I talk with the author? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-25 5:27 ` IRC Client for Emacs Richard Stallman @ 2002-08-25 13:38 ` Alex Schroeder 2002-08-25 15:56 ` color-theme.el Eli Zaretskii 2002-09-02 0:02 ` color-theme.el Richard Stallman 0 siblings, 2 replies; 28+ messages in thread From: Alex Schroeder @ 2002-08-25 13:38 UTC (permalink / raw) Cc: krooger, emacs-devel Richard Stallman <rms@gnu.org> writes: > May I also take this time to ask that color-theme.el be added to the > Emacs distribution. > > What does this do, and how can I talk with the author? I am the author. :) Basically, it provides around 50 elisp functions that will change lots of faces, frame-parameters, and variables, such as to change the look of Emacs completely. Since all 50 functions redefine lots of faces, the source file is VERY large: ~/WWW/home/tuning $ ls -l ~/elisp/color-theme total 635 drwxrwxr-x 2 alex alex 4096 Aug 10 20:58 CVS -rw-rw-r-- 1 alex alex 4195 Apr 30 00:32 color-theme-maker.el -rw-rw-r-- 1 alex alex 634752 Aug 10 20:57 color-theme.el -rw-rw-r-- 1 alex alex 569761 Aug 25 15:31 color-theme.elc -rw-rw-r-- 1 alex alex 3097 Sep 1 2001 make-theme.el The color-theme-maker.el allows you to combine several color themes into new themes, by example taking all faces definitions of faces starting with "gnus-" from theme A and all other faces from theme B. make-theme.el allows you to split the color-theme.el file automatically into an "engine" and on file per theme function. We could make only the engine part of Emacs, and let people distribute themes by themselves. Here is a very short example -- my favorite theme. It installs color-theme-gnome2, and then it does some slight modifications. It also illustrates that many themes include faces for packages that are not part of Emacs. I would not go through the trouble of removing these, since I depend on theme contributions by users. (defun color-theme-robin-hood () "`color-theme-gnome2' with navajo white on green." (interactive) (color-theme-gnome2) (let ((color-theme-is-cumulative t)) (color-theme-install '(color-theme-robin-hood ((foreground-color . "navajo white") (background-color . "#304020")) ((CUA-mode-read-only-cursor-color . "white")) (default ((t (nil)))) (fringe ((t (:background "#003700")))) (header-line ((t (:background "#030" :foreground "#AA7")))) (ido-subdir-face ((t (:foreground "MediumSlateBlue")))) (menu ((t (:background "#304020" :foreground "navajo white")))) (modeline ((t (:background "dark olive green" :foreground "wheat")))) (semantic-dirty-token-face ((t (:background "grey22")))) (tool-bar ((t (:background "#304020" :foreground "wheat" :box (:line-width 1 :style released-button))))) (tooltip ((t (:background "lemon chiffon" :foreground "black")))))))) The color theme selection buffer looks something like this: [Reset] Undo changes, if possible. [Quit] Bury this buffer. Aalto Dark Jari Aalto <jari.aalto@poboxes.com> Aalto Light Jari Aalto <jari.aalto@poboxes.com> Alice Blue Girish Bharadwaj <girishb@gbvsoft.com> Arjen Arjen Wiersma <arjen@wiersma.org> Bharadwaj Girish Bharadwaj <girishb@gbvsoft.com> Billw Bill White <billw@wolfram.com> BlackOnGray Sudhir Bhojwani <sbhojwani@altoweb.com> Blipp Blopp Thomas Sicheritz-Ponten<thomas@biopython.org> Black Jonadab <jonadab@bright.net> Blue Mood Nelson Loyola <nloyola@yahoo.com> Blue Sea Alex Schroeder <alex@gnu.org> Cheap Goldenrod Alex Schroeder <alex@gnu.org> etc. As you can see, we would need assignments by all the authors. Since their email addresses are part of the source, however, this should be easy to get. Alex. PS: Here is the commentary of color-theme.el. ;;; Commentary: ;; Sharing your current color setup: ;; ;; Use `color-theme-submit'. If you have already invested time in ;; customizing Emacs faces, please consider sharing your current setup. ;; Make sure that color-theme.el is in your `load-path'. Type M-x ;; load-library RET color-theme RET to load all the functions. Type M-x ;; color-theme-submit RET and mail the result to the maintainer of this ;; package (see above for mail addres). ;; ;; If you want to make sure that all your customization was exported, ;; type M-x list-faces-display RET to get a list of all faces currently ;; defined. This is the list of faces that `color-theme-print' uses. ;; Installing a color theme: ;; ;; Make sure that color-theme.el is in your `load-path'. Type M-x ;; load-library RET color-theme RET to load all the functions. ;; ;; The main function to call is color-theme-select. Type M-x ;; color-theme-select RET. That creates a Color Theme Selection ;; buffer. Press RET or `i' on a color theme to install it for the ;; rest of your session. ;; ;; If you want to install the color theme as soon as Emacs is started ;; up, read the description of the theme you like and remember the ;; name of the color theme function. Press `d' on a color theme in ;; the Color Theme Selection buffer to read the description. Assuming ;; you like the Gnome2 theme, you'll find that the function to use is ;; called `color-theme-gnome2'. Add the following to the end of your ;; .emacs (removing the leading `;;'). ;; ;; (require 'color-theme) ;; (color-theme-gnome2) ;; Changing menu colors: ;; ;; In Emacs 21 on X, you can set the menu colors and font using the ;; menu face. Example for your .emacs file: ;; ;; (set-face-font 'menu "7x14") ;; (set-face-foreground 'menu "white"). ;; ;; If are using X, you can set the menu foreground and background using ;; a resource file, usually .Xdefaults or .Xresources. Usually ;; .Xdefaults is used when you start your session using a display ;; manager such as xdm or gdm. .Xresources is usually used when you ;; start X directly via a shell script such as startx. If you set ;; Emacs*Background and Emacs*Foreground in such a resource file, the ;; foreground and background of Emacs including the menu will be set. ;; If your .emacs then loads a color theme, the foreground and ;; background are changed -- with the exception of the menu. There is ;; no way to manipulate the menu foreground and background color from ;; elisp. You can also set more specific menu resources for Emacs in ;; the resource file. Here is a sample entry for your resource file: ;; ;; Emacs*Background: DarkSlateGray ;; Emacs*Foreground: wheat ;; Creating your own color theme: ;; ;; Use M-x customize-face and customize the faces. Make sure to "Set ;; for Current Session" -- you don't want to save these using custom! ;; When you are done, call M-x color-theme-print to produce the elisp ;; code required to recreate your theme. Better yet, use M-x ;; color-theme-submit to mail it to the maintainer. That way it will be ;; added to future versions of color-theme.el. ;; ;; For more information on the elisp format of a color theme, start with ;; the documentation of `color-theme-install' using C-h f ;; color-theme-install. ;; ;; When your color theme is just a variation of an existing color theme, ;; take a look at `color-theme-robin-hood' in order to see an example of ;; how to do it. Essentially you want to call all the parent color ;; themes before installing your changes. For all but the first parent ;; color theme, you need to make sure that `color-theme-is-cumulative' ;; is bound to t. If you don't do that, users that set ;; `color-theme-is-cumulative' to nil will only install your changes ;; without the parent color themes. ;; Making a color theme work for both Emacs and XEmacs: ;; ;; The most important thing is to add missing faces for the other ;; editor. These are the most important faces to check: ;; ;; In Emacs In XEmacs ;; `font-lock-builtin-face' `font-lock-reference-face' ;; `font-lock-doc-face' `font-lock-doc-string-face' ;; `font-lock-constant-face' `font-lock-preprocessor-face' ;; `modeline' `modeline-buffer-id' ;; `modeline' `modeline-mousable' ;; `modeline' `modeline-mousable-minor-mode' ;; `region' `primary-selection' ;; `region' `zmacs-region' ;; `font-lock-string-face' `dired-face-boring' ;; `font-lock-function-name-face' `dired-face-directory' ;; `default' `dired-face-executable' ;; `font-lock-warning-face' `dired-face-flagged' ;; `font-lock-warning-face' `dired-face-marked' ;; `default' `dired-face-permissions' ;; `default' `dired-face-setuid' ;; `default' `dired-face-socket' ;; `font-lock-keyword-face' `dired-face-symlink' ;; ;; Further comments: ;; ;; In Emacs 21 `modeline' is just an alias for `mode-line'. I recommend ;; the use of `modeline' until further notice. ;; ;; The support for :foreground and :background attributes works for ;; Emacs 20 and 21 as well as for XEmacs. :inverse-video is taken care ;; of while printing color themes. ;; ;; I don't recommend making font sizes part of a color theme. Most ;; users would be surprised to see their font sizes change when they ;; install a color-theme. Therefore, remove all :height attributes if ;; the value is an integer. If the value is a float, this is ok -- the ;; value is relative to the default height. One notable exceptions is ;; for a color-theme created for visually impaired people. These *must* ;; use a larger font in order to be usable. ;; ;; The tool-bar should not be part of the frame-parameters, since it ;; should not appear or disappear depending on the color theme. The ;; apppearance of the toolbar, however, can be changed by the color ;; theme. For Emacs 21, use the `tool-bar' face. The easiest way to do ;; this is to give it the default fore- and background colors. This can ;; be achieved using (tool-bar ((t (nil)))) in the theme. Usually it ;; makes more sense, however, to provide the same colors as used in the ;; `menu' face, and to specify a :box attribute. In order to alleviate ;; potential Emacs/XEmacs incompatibilities, `toolbar' will be defined ;; as an alias for `tool-bar' if it does not exist, and vice-versa. ;; This is done eventhough the face `toolbar' seems to have no effect on ;; XEmacs. If you look at XEmacs lisp/faces.el, however, you will find ;; that it is in fact referenced for XPM stuff. ;; ;; Similarly, the `fringe' face defines what the left and right borders ;; of the frame look like in Emacs 21. To give them default fore- and ;; background colors, use (fringe ((t (nil)))) in your color theme. ;; Usually it makes more sense to choose a color slightly lighter or ;; darker from the default background. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-25 13:38 ` color-theme.el Alex Schroeder @ 2002-08-25 15:56 ` Eli Zaretskii 2002-09-02 0:02 ` color-theme.el Richard Stallman 1 sibling, 0 replies; 28+ messages in thread From: Eli Zaretskii @ 2002-08-25 15:56 UTC (permalink / raw) Cc: krooger, emacs-devel > From: Alex Schroeder <alex@emacswiki.org> > Date: Sun, 25 Aug 2002 15:38:57 +0200 > > ~/WWW/home/tuning $ ls -l ~/elisp/color-theme > total 635 > drwxrwxr-x 2 alex alex 4096 Aug 10 20:58 CVS > -rw-rw-r-- 1 alex alex 4195 Apr 30 00:32 color-theme-maker.el > -rw-rw-r-- 1 alex alex 634752 Aug 10 20:57 color-theme.el > -rw-rw-r-- 1 alex alex 569761 Aug 25 15:31 color-theme.elc > -rw-rw-r-- 1 alex alex 3097 Sep 1 2001 make-theme.el If this package is added to Emacs, please rename color-theme-maker.el to some name whose first 8 characters are different from "color-th", to avoid file-name clashes in the 8+3-restricted DOS filesystems (which Emacs still supports). TIA ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: color-theme.el 2002-08-25 13:38 ` color-theme.el Alex Schroeder 2002-08-25 15:56 ` color-theme.el Eli Zaretskii @ 2002-09-02 0:02 ` Richard Stallman 1 sibling, 0 replies; 28+ messages in thread From: Richard Stallman @ 2002-09-02 0:02 UTC (permalink / raw) Cc: krooger, emacs-devel make-theme.el allows you to split the color-theme.el file automatically into an "engine" and on file per theme function. We could make only the engine part of Emacs, and let people distribute themes by themselves. I think that would be the right first step, if we decide to use this rather than cus-themes.el. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2002-09-09 0:21 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-08-24 4:32 IRC Client for Emacs Jonathan Walther 2002-08-24 5:11 ` Damien Elmes 2002-08-24 16:50 ` color-theme.el Alex Schroeder 2002-08-26 12:45 ` color-theme.el Per Abrahamsen 2002-08-27 19:05 ` color-theme.el Richard Stallman 2002-08-28 14:19 ` color-theme.el Per Abrahamsen 2002-08-28 23:33 ` color-theme.el Richard Stallman 2002-08-29 11:55 ` color-theme.el Per Abrahamsen 2002-08-29 17:14 ` color-theme.el Alex Schroeder 2002-08-30 19:17 ` color-theme.el Richard Stallman 2002-08-31 11:38 ` color-theme.el Alex Schroeder 2002-09-01 13:14 ` color-theme.el Richard Stallman 2002-09-01 16:07 ` color-theme.el Alex Schroeder 2002-09-07 14:15 ` color-theme.el Alex Schroeder 2002-09-09 0:21 ` color-theme.el Richard Stallman 2002-08-27 23:18 ` color-theme.el Alex Schroeder 2002-08-28 14:37 ` color-theme.el Per Abrahamsen 2002-08-28 18:37 ` color-theme.el Alex Schroeder 2002-08-29 12:12 ` color-theme.el Per Abrahamsen 2002-08-31 16:58 ` color-theme.el Richard Stallman 2002-09-01 0:05 ` color-theme.el Alex Schroeder 2002-09-02 0:01 ` color-theme.el Richard Stallman 2002-09-02 20:37 ` color-theme.el Alex Schroeder 2002-09-07 14:17 ` color-theme.el Alex Schroeder 2002-08-25 5:27 ` IRC Client for Emacs Richard Stallman 2002-08-25 13:38 ` color-theme.el Alex Schroeder 2002-08-25 15:56 ` color-theme.el Eli Zaretskii 2002-09-02 0:02 ` color-theme.el Richard Stallman
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.