* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. [not found] <E1PKgZg-0005td-8L@internal.in.savannah.gnu.org> @ 2010-11-23 19:50 ` Glenn Morris 2010-11-23 20:24 ` Chong Yidong 2010-11-23 21:14 ` Julien Danjou 0 siblings, 2 replies; 30+ messages in thread From: Glenn Morris @ 2010-11-23 19:50 UTC (permalink / raw) To: julien; +Cc: emacs-devel > color-lab.el: New file. This needs cl when compiling. (This is flagged by the compiler.) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 19:50 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal Glenn Morris @ 2010-11-23 20:24 ` Chong Yidong 2010-11-23 21:14 ` Julien Danjou 2010-11-23 21:16 ` Lars Magne Ingebrigtsen 2010-11-23 21:14 ` Julien Danjou 1 sibling, 2 replies; 30+ messages in thread From: Chong Yidong @ 2010-11-23 20:24 UTC (permalink / raw) To: Katsumi Yamaoka, julien; +Cc: emacs-devel Glenn Morris <rgm@gnu.org> writes: >> color-lab.el: New file. > > This needs cl when compiling. (This is flagged by the compiler.) Why is this non-gnus-related library being checked into the Gnus repository? ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 20:24 ` Chong Yidong @ 2010-11-23 21:14 ` Julien Danjou 2010-11-23 21:31 ` Chong Yidong 2010-11-23 21:16 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 30+ messages in thread From: Julien Danjou @ 2010-11-23 21:14 UTC (permalink / raw) To: Chong Yidong; +Cc: Katsumi Yamaoka, emacs-devel On Tue, Nov 23 2010, Chong Yidong wrote: > Why is this non-gnus-related library being checked into the Gnus > repository? Because it is used by Gnus? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 21:14 ` Julien Danjou @ 2010-11-23 21:31 ` Chong Yidong 2010-11-23 21:38 ` Lars Magne Ingebrigtsen 2010-11-24 8:36 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert " Richard Stallman 0 siblings, 2 replies; 30+ messages in thread From: Chong Yidong @ 2010-11-23 21:31 UTC (permalink / raw) To: emacs-devel; +Cc: Katsumi Yamaoka Julien Danjou <julien@danjou.info> writes: > On Tue, Nov 23 2010, Chong Yidong wrote: > >> Why is this non-gnus-related library being checked into the Gnus >> repository? > > Because it is used by Gnus? By that logic, we should move all of Emacs into the Gnus tree. This is a general purpose library, not specific to Gnus. It really ought to be moved out into the Emacs tree. If no one objects, I'm going to move it. Also, it is going to have be be fixed. For example, it violates function naming conventions---some functions start with `color-lab', others with `lab', and still others with no prefix at all. All this could have been caught if you'd posted the file to emacs-devel and gone through the usual process of getting a library into the Emacs tree. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 21:31 ` Chong Yidong @ 2010-11-23 21:38 ` Lars Magne Ingebrigtsen 2010-11-23 22:18 ` Chong Yidong 2010-11-24 8:36 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert " Richard Stallman 1 sibling, 1 reply; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 21:38 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > By that logic, we should move all of Emacs into the Gnus tree. This is > a general purpose library, not specific to Gnus. It really ought to be > moved out into the Emacs tree. If no one objects, I'm going to move it. It is actively being hacked on, and Gnus is the only user. After it stabilises then, yes, it should be moved, but not at present. > Also, it is going to have be be fixed. For example, it violates > function naming conventions---some functions start with `color-lab', > others with `lab', and still others with no prefix at all. All this > could have been caught if you'd posted the file to emacs-devel and gone > through the usual process of getting a library into the Emacs tree. It's being worked on. It's brand new code. Chill out. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 21:38 ` Lars Magne Ingebrigtsen @ 2010-11-23 22:18 ` Chong Yidong 2010-11-23 22:34 ` Lars Magne Ingebrigtsen 2010-11-24 0:05 ` Drew Adams 0 siblings, 2 replies; 30+ messages in thread From: Chong Yidong @ 2010-11-23 22:18 UTC (permalink / raw) To: emacs-devel Lars Magne Ingebrigtsen <larsi@gnus.org> writes: >> By that logic, we should move all of Emacs into the Gnus tree. This is >> a general purpose library, not specific to Gnus. It really ought to be >> moved out into the Emacs tree. If no one objects, I'm going to move it. > > It is actively being hacked on, and Gnus is the only user. After it > stabilises then, yes, it should be moved, but not at present. > > It's being worked on. It's brand new code. Chill out. I see. Why not just use hexrgb.el (or build on it)? It's been around long enough that such teething problems should have been eliminated. Drew Adams has an assignment on file; if he is willing to include hexrgb.el under that assignment, we could simply add that to Emacs. Whatever additional functionality you need that isn't already present, you could then simply add. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 22:18 ` Chong Yidong @ 2010-11-23 22:34 ` Lars Magne Ingebrigtsen 2010-11-24 0:12 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert " Drew Adams 2010-11-24 0:05 ` Drew Adams 1 sibling, 1 reply; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 22:34 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > I see. Why not just use hexrgb.el (or build on it)? It's been around > long enough that such teething problems should have been eliminated. The purpose of color-lab is to compute readable colours. The use case is this: Given a constant background colour in a buffer, you then have a <p style="color: blue"> HTML element. If you have a white background, then that's fine. If you have a black background, the blue colour will be unreadable. color-lab computes a "distance" between black and a blue hue that is readable, and that blue hue is used instead. It's kinda neat. So it doesn't have much to do with hexrgb.el, I think. Did you read the code? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 22:34 ` Lars Magne Ingebrigtsen @ 2010-11-24 0:12 ` Drew Adams 2010-11-24 9:08 ` Julien Danjou 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2010-11-24 0:12 UTC (permalink / raw) To: 'Lars Magne Ingebrigtsen', emacs-devel > > I see. Why not just use hexrgb.el (or build on it)? It's > > been around long enough that such teething problems should > > have been eliminated. > > ... > color-lab computes a "distance" between black and a blue > hue that is readable... > > So it doesn't have much to do with hexrgb.el, I think. Dunno. Such a particular color distance computation is I guess complementary to what is in hexrgb.el. But in general that is the kind of thing that hexrgb.el does. For example, `hexrgb-complement' returns the complement of a given color. Taking the difference between the hue values of two colors gives you a hue distance, and so on. That kind of color distance is already there - nothing to be done. You can easily combine these kinds of distance in some way - e.g. A * hue-dist + B * saturation-dist + C * value-dist = my-dist. You seem to be describing something oriented toward a particular application: "just distant enough to improve readability" or some such. It would not be off-topic for hexrgb to include such a color-distance metric. I just haven't needed that so I haven't added it. If it is decided to include hexrgb.el in Emacs then we could add such a function to hexrgb.el if the function is fairly general. Or we could add it elsewhere (e.g. gnus) and just use hexrgb.el for its definition (or not). It sounds like the real task for your function is the design: just what kind of distance function do you want? You mention "readable", so that could be one criterion of use. But the devil might well be in the details (influence of dark/light backgrounds, human eye characteristics, etc.) Certainly you can already use hexrgb.el to calculate the distance between two colors in terms of any color components. The question is what you want to do with such a difference: what distance is a good one for something to be "readable enough", etc. hexrgb.el has an approximately-equal function that you can use for this kind of thing (not approximatly equal = sufficiently distant), passing an appropriate fuzz factor. For instance, I do something similar in my palette.el code, in order to determine when a color is essentially the same as its complement. When that's the case I change the cursor color to an alternative color that stands out better against that color as background. You might look at hexrgb.el to see if you can use the functions there to define what you need. Just a suggestion. In sum, this sounds hexrgb.el-like to me, and I cannot tell whether what you want is already available using what is in hexrgb.el. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 0:12 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert " Drew Adams @ 2010-11-24 9:08 ` Julien Danjou 2010-11-24 11:35 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Julien Danjou @ 2010-11-24 9:08 UTC (permalink / raw) To: Drew Adams; +Cc: 'Lars Magne Ingebrigtsen', emacs-devel On Wed, Nov 24 2010, Drew Adams wrote: > Dunno. But you write a lot for someone who do not know. :) > You seem to be describing something oriented toward a particular application: > "just distant enough to improve readability" or some such. It would not be > off-topic for hexrgb to include such a color-distance metric. I just haven't > needed that so I haven't added it. Color-lab has been built upon a specific need, which resulted in the CIE Delta E 2000 formula to be implemented. Some helper functions dealing with colors have been written, like CIE XYZ and CIE Lab conversion in the process. All of this is not present in hexrgb, and hexrgb is not present in Emacs. I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv) which are in hexrgb, but they are even not used at all by the CIE code. So I think it's really unfair to stand up and point at this package like it's something that should not have been done. Now if you want to merge hexrgb and color-lab, why not, but stop pointing at other people work because some is not included in Emacs. I can't do anything about it. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 9:08 ` Julien Danjou @ 2010-11-24 11:35 ` Eli Zaretskii 2010-11-24 14:46 ` Stefan Monnier 2010-11-24 16:15 ` Drew Adams 2010-11-24 16:29 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Chong Yidong 2 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2010-11-24 11:35 UTC (permalink / raw) To: Julien Danjou; +Cc: larsi, emacs-devel > From: Julien Danjou <julien@danjou.info> > Date: Wed, 24 Nov 2010 10:08:13 +0100 > Cc: 'Lars Magne Ingebrigtsen' <larsi@gnus.org>, emacs-devel@gnu.org > > Color-lab has been built upon a specific need, which resulted in the CIE > Delta E 2000 formula to be implemented. Some helper functions dealing > with colors have been written, like CIE XYZ and CIE Lab conversion in > the process. > > All of this is not present in hexrgb, and hexrgb is not present in Emacs. > > I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv) > which are in hexrgb, but they are even not used at all by the CIE code. > > So I think it's really unfair to stand up and point at this package like > it's something that should not have been done. > > Now if you want to merge hexrgb and color-lab, why not, but stop > pointing at other people work because some is not included in Emacs. > > I can't do anything about it. Perhaps we could all stop being apologetic and pointing fingers at one another, and see one important lesson to be learned here: that before adding a package to Emacs, the contributor should talk to the head maintainers about where the new package should be and whether it should be a new one or an addition to an existing one. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 11:35 ` Eli Zaretskii @ 2010-11-24 14:46 ` Stefan Monnier 2010-11-24 15:30 ` Lennart Borgman 2010-11-24 22:19 ` Lars Magne Ingebrigtsen 0 siblings, 2 replies; 30+ messages in thread From: Stefan Monnier @ 2010-11-24 14:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Julien Danjou, larsi, emacs-devel > Perhaps we could all stop being apologetic and pointing fingers at one > another, and see one important lesson to be learned here: that before > adding a package to Emacs, the contributor should talk to the head > maintainers about where the new package should be and whether it > should be a new one or an addition to an existing one. Agreed. And the other side of the coin is that rather than complain about a new package that not included the way we want it, we should welcome the new addition and drool over the synergistic opportunity to merge it with some other package [yes, maybe I'm pushing it a bit, but I'm sure you see what I mean]. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 14:46 ` Stefan Monnier @ 2010-11-24 15:30 ` Lennart Borgman 2010-11-24 18:15 ` Ted Zlatanov 2010-11-24 22:19 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 30+ messages in thread From: Lennart Borgman @ 2010-11-24 15:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: Julien Danjou, Eli Zaretskii, larsi, emacs-devel On Wed, Nov 24, 2010 at 3:46 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> Perhaps we could all stop being apologetic and pointing fingers at one >> another, and see one important lesson to be learned here: that before >> adding a package to Emacs, the contributor should talk to the head >> maintainers about where the new package should be and whether it >> should be a new one or an addition to an existing one. > > Agreed. And the other side of the coin is that rather than complain > about a new package that not included the way we want it, we should > welcome the new addition and drool over the synergistic opportunity to > merge it with some other package [yes, maybe I'm pushing it a bit, but > I'm sure you see what I mean]. A problem is of course if gnus is including it to add a new possibility and that is not yet in Emacs. Maybe GELPA (or whatever it is called) could be a help in the transition. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 15:30 ` Lennart Borgman @ 2010-11-24 18:15 ` Ted Zlatanov 2010-11-24 21:37 ` Lennart Borgman 0 siblings, 1 reply; 30+ messages in thread From: Ted Zlatanov @ 2010-11-24 18:15 UTC (permalink / raw) To: emacs-devel On Wed, 24 Nov 2010 16:30:09 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: LB> A problem is of course if gnus is including it to add a new LB> possibility and that is not yet in Emacs. Maybe GELPA (or whatever LB> it is called) could be a help in the transition. I think color-lab.el is too useful to be an external package. I can see many areas of Emacs that would benefit from it. For instance it will allow for color blindness; setting that as a user preference in one place would be nice to let all of Emacs adjust color contrasts appropriately: default colors, themes, color pickers, etc. Ted ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 18:15 ` Ted Zlatanov @ 2010-11-24 21:37 ` Lennart Borgman 0 siblings, 0 replies; 30+ messages in thread From: Lennart Borgman @ 2010-11-24 21:37 UTC (permalink / raw) To: Ted Zlatanov; +Cc: emacs-devel 2010/11/24 Ted Zlatanov <tzz@lifelogs.com>: > On Wed, 24 Nov 2010 16:30:09 +0100 Lennart Borgman <lennart.borgman@gmail.com> wrote: > > LB> A problem is of course if gnus is including it to add a new > LB> possibility and that is not yet in Emacs. Maybe GELPA (or whatever > LB> it is called) could be a help in the transition. > > I think color-lab.el is too useful to be an external package. I can see > many areas of Emacs that would benefit from it. For instance it will > allow for color blindness; setting that as a user preference in one > place would be nice to let all of Emacs adjust color contrasts > appropriately: default colors, themes, color pickers, etc. I did not say it should stay in "GELPA". ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 14:46 ` Stefan Monnier 2010-11-24 15:30 ` Lennart Borgman @ 2010-11-24 22:19 ` Lars Magne Ingebrigtsen 2010-11-24 22:41 ` Use color-tweaking code to improve face defaults? [was: /srv/bzr/emacs/trunk r1...] Drew Adams 2010-11-25 4:53 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Stefan Monnier 1 sibling, 2 replies; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-24 22:19 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: > Agreed. And the other side of the coin is that rather than complain > about a new package that not included the way we want it, we should > welcome the new addition and drool over the synergistic opportunity to > merge it with some other package [yes, maybe I'm pushing it a bit, but > I'm sure you see what I mean]. I'm wondering whether it may be used in defface. Gnus now has a gazillion defface declarations like this: (defface gnus-group-news-2-empty '((((class color) (background dark)) (:foreground "turquoise")) (((class color) (background light)) (:foreground "CadetBlue4")) (t ())) Which is very general and all, but the colours chosen are usually quite garish, since (for instance) `light' commonly spans the gamut from white to gray, so we have to choose colours that pop. We could start choosing more mellifluous hues by default, and have color-lab ensure that the text would be readable for all users... That is, reduce the fruit salad-ey-ness that Emacs has now. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Use color-tweaking code to improve face defaults? [was: /srv/bzr/emacs/trunk r1...] 2010-11-24 22:19 ` Lars Magne Ingebrigtsen @ 2010-11-24 22:41 ` Drew Adams 2010-11-25 4:53 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Stefan Monnier 1 sibling, 0 replies; 30+ messages in thread From: Drew Adams @ 2010-11-24 22:41 UTC (permalink / raw) To: 'Lars Magne Ingebrigtsen', emacs-devel > Gnus now has a gazillion defface declarations like this: > > (defface gnus-group-news-2-empty > '((((class color)(background dark))(:foreground "turquoise")) > (((class color)(background light))(:foreground "CadetBlue4")) > (t ())) > > Which is very general and all, but the colours chosen are > usually quite garish, since (for instance) `light' commonly > spans the gamut from white to gray, so we have to choose > colours that pop. > > We could start choosing more mellifluous hues by default, and have > color-lab ensure that the text would be readable for all users... > That is, reduce the fruit salad-ey-ness that Emacs has now. I suggest a separate thread for this. I personally agree that an ability to tweak colors for human readability etc. _can_ sometimes help developers come up with better default values for face colors. (One might have doubts about "readable for all users", but let's assume that's feasible.) However, regardless of which colors you might come up with and propose, for whichever face defaults, there is bound to be a lively discussion (aka melee). There are lots of considerations when choosing _default_ colors for faces. That's no reason not to try or not to discuss. Just be forewarned to have pastel expectations. ;-) ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 22:19 ` Lars Magne Ingebrigtsen 2010-11-24 22:41 ` Use color-tweaking code to improve face defaults? [was: /srv/bzr/emacs/trunk r1...] Drew Adams @ 2010-11-25 4:53 ` Stefan Monnier 2010-12-10 19:19 ` Ted Zlatanov 1 sibling, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2010-11-25 4:53 UTC (permalink / raw) To: emacs-devel >> Agreed. And the other side of the coin is that rather than complain >> about a new package that not included the way we want it, we should >> welcome the new addition and drool over the synergistic opportunity to >> merge it with some other package [yes, maybe I'm pushing it a bit, but >> I'm sure you see what I mean]. > I'm wondering whether it may be used in defface. Probably, yes. > We could start choosing more mellifluous hues by default, and have > color-lab ensure that the text would be readable for all users... That > is, reduce the fruit salad-ey-ness that Emacs has now. That would be wonderful indeed. Not sure easy that would be (what with having to take into account limitations such as an 8- or 16-color text terminal), but it sounds quite intriguing. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-25 4:53 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Stefan Monnier @ 2010-12-10 19:19 ` Ted Zlatanov 0 siblings, 0 replies; 30+ messages in thread From: Ted Zlatanov @ 2010-12-10 19:19 UTC (permalink / raw) To: emacs-devel On Wed, 24 Nov 2010 23:53:52 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: >> We could start choosing more mellifluous hues by default, and have >> color-lab ensure that the text would be readable for all users... That >> is, reduce the fruit salad-ey-ness that Emacs has now. SM> That would be wonderful indeed. Not sure easy that would be (what with SM> having to take into account limitations such as an 8- or 16-color text SM> terminal), but it sounds quite intriguing. Lars' original proposition would be nice, I think, if there was a facility to convert (using his example) (defface gnus-group-news-2-empty '((((class color) (background dark)) (:foreground "turquoise")) (((class color) (background light)) (:foreground "CadetBlue4")) (t ())) to (defface gnus-group-news-2-empty ...) (color-lab-install-mellifluous-colors 'gnus-group-news-2-empty :dark (:foreground "turquoise") :light (:foreground "CadetBlue4")) ;; or... (color-lab-install-mellifluous-dark-colors 'gnus-group-news-2-empty (:foreground "turquoise")) (color-lab-install-mellifluous-light-colors 'gnus-group-news-2-empty (:foreground "CadetBlue4")) Then we can tweak `color-lab-install-mellifluous-colors' to DTRT in all circumstances, while the package author doesn't have to worry about those tweaks because his code will work regardless. In other words, we'd be switching from a purely data-driven approach with `defface' to a more flexible declarative approach of `defface' plus color-lab functions. Ted ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 9:08 ` Julien Danjou 2010-11-24 11:35 ` Eli Zaretskii @ 2010-11-24 16:15 ` Drew Adams 2010-11-24 18:11 ` Ted Zlatanov 2010-11-24 16:29 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Chong Yidong 2 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2010-11-24 16:15 UTC (permalink / raw) To: 'Julien Danjou'; +Cc: 'Lars Magne Ingebrigtsen', emacs-devel > > Dunno. > > But you write a lot for someone who do not know. :) I said I do not know whether color-lab.el "doesn't have much to do with hexrgb.el" (Lars). I did not say that I do not know anything. I wrote about what I do know about: hexrgb.el. What did I mean by "dunno" here? Read what followed "dunno": d> Dunno. Such a particular color distance computation is I guess d> complementary to what is in hexrgb.el. But in general that is d> the kind of thing that hexrgb.el does. So wrt particular content: it seems _complementary_. But in general, color difference _is_ the kind of thing that hexrgb.el does. So yes and no - dunno based only on Lars's general description of color-lab.el. > All of this is not present in hexrgb Complementary. > I admit: color-lab has 50 SLOC for 2 functions (rgb->hsl and rgb->hsv) > which are in hexrgb, but they are even not used at all by the > CIE code. I already made it clear during the discussion of rainbow-mode.el that such overlap is to be expected. These are just standard color conversions. > So I think it's really unfair to stand up and point at this > package like it's something that should not have been done. > > Now if you want to merge hexrgb and color-lab, why not, but stop > pointing at other people work because some is not included in Emacs. > > I can't do anything about it. You replied to my mail, but is this directed at me or someone else? I haven't pointed at any package as something that should not have been done. I haven't pointed at anyone's work because something is not in Emacs (?). "Really unfair", indeed. I simply replied to Yidong's mention of possibly including hexrgb.el (it's OK). And to Lars's indication that color-lab.el was about calculating a color distance and that (he thinks) that has little to do with hexrgb.el. I was going by what Lars described - I have not looked at color-lab.el myself. Whether color-lab.el _in fact_ has anything to do with hexrgb.el (e.g. same or similar subject) I dunno. And even if it does, whether the two should be included separately or merged in some way I dunno. I am not pushing for either inclusion or merger. I am not pushing and I am not pointing. ;-) To be clear, I do not really care whether hexrgb.el, color-lab.el, some combination of them, or both of them are added to Emacs. I tried to reply technically to the question of what hexrgb.el is about. That's all. I wrote hexrgb.el for myself and anyone else who wants to use it. I am glad that someone wrote color-lab.el as well. Heuristically determining readable colors would be useful - I'm glad you're working on it. Whether any of this stuff should be added to Emacs is another story, and not for me to decide. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 16:15 ` Drew Adams @ 2010-11-24 18:11 ` Ted Zlatanov 2010-11-24 21:00 ` /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Ted Zlatanov @ 2010-11-24 18:11 UTC (permalink / raw) To: emacs-devel On Wed, 24 Nov 2010 08:15:25 -0800 "Drew Adams" <drew.adams@oracle.com> wrote: DA> Such a particular color distance computation is I guess complementary DA> to what is in hexrgb.el. But in general that is the kind of thing DA> that hexrgb.el does. I also think the two should be merged. Since color-lab.el is a better name IMO, could you and Julien merge hexrgb.el into it? That would require work, obviously, but I think it's well worthwhile. I will help if necessary. On Wed, 24 Nov 2010 11:29:39 -0500 Chong Yidong <cyd@stupidchicken.com> wrote: CY> So, shall we pull the file out into Emacs? Then we can merge it with CY> hexrgb.el, and maybe move `read-color' there as well. I think we should. It's good core functionality. Ted ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal. 2010-11-24 18:11 ` Ted Zlatanov @ 2010-11-24 21:00 ` Drew Adams 2010-11-24 21:33 ` Julien Danjou 0 siblings, 1 reply; 30+ messages in thread From: Drew Adams @ 2010-11-24 21:00 UTC (permalink / raw) To: 'Ted Zlatanov', emacs-devel > I also think the two should be merged. Since color-lab.el is a better > name IMO, could you and Julien merge hexrgb.el into it? That would > require work, obviously, but I think it's well worthwhile. I > will help if necessary. It sounds like there is no overlap, except for two functions (no, I have not checked, but others seem to have). I suggest the following steps, if Yidong etc. agree: 1. Change any calls of those two functions to use the corresponding hexrgb.el functions instead. Then test the color-lab use (the two versions might not be exactly equivalent, even if they do essentially the same thing). 2. Since there is apparently no other overlap, put all of the code from the two libraries into a single file. 3. Choose a new file name and fix the name prefixes accordingly. "hexrgb" is probably not general enough (it is not even general enough for all that it does now, since the name reflects only RGB, not HSV). I don't think "color-lab" is a good name for this general library either; this is not just about CIELAB. How about just "color.el"? 4. Integrate with Emacs. This involves adjusting/removing any overlapping existing stuff - e.g. `read-color' and possibly some facemenu stuff. However, it is possible that someone might prefer that all of this functionality not be in the same file. Some hexrgb.el stuff has already been added to Emacs, and in different places if I'm not mistaken. Someone apparently thought it was a good idea to spread such stuff around. IOW, someone needs to decide whether all of these functions belong in a library, and if so whether the functions and vars should have a prefix (e.g. `foo-read-color' vs `read-color'). And in any case any existing functions that do the same thing or similar should be removed from Emacs (or merged). Yidong might want to do #4, since it involves some deciding and he is familiar with the Emacs `read-color' code and recent changes. A question I have (no, I still have not looked at color-lab.el; I don't even know where to find it): Why not merge only the parts of color-lab.el that involve color manipulations with hexrgb.el, and keep the rest (e.g. heuristics about readability and color-blindness, color-vision profiles, HTML use etc.) in a separate Emacs library? IOW, _if_ color-lab.el has both (a) general color-manipulation/conversion functions and (b) application-specific functions that use those general functions, then wouldn't it make sense to keep the latter separate? (No, I don't care - it's just a question.) I would think that we'd want to keep the merged color-manipulation library for _only_ color manipulation (and possibly the read-color command). Otherwise, there is a risk that anything at all having to do with some particular use of color will get stuffed into it. It's a slippery slope, once we start allowing in some applications of color. From the sound of it, part of color-lab.el (CIE etc.) defines color utility functions, and part of it uses those functions for particular applications. In my code, I separate the the color-manipulation library (hexrgb.el) from its users (palette.el, eyedrop.el, Icicles, DoReMi). Doesn't that make sense here too? Finally, see my previous mail about other changes and decisions that will be required in order to include the hexrgb.el code. E.g., Include eyedrop.el? If so, add its code to the new color library or keep it separate? If not, hexrgb.el will need to be purged of its few calls to the eyedrop functions. Reminder: Eyedropper just lets you pick up a foreground or background color at point or under the mouse pointer. It can save these colors in two global vars (foreground, background), which can then be used elsewhere. E.g., hexrgb.el uses them as color candidates for `hexrgb-read-color'. This means that you do not need to know what a color is (its name or its RGB or other components) in order to use it. HTH. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal. 2010-11-24 21:00 ` /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal Drew Adams @ 2010-11-24 21:33 ` Julien Danjou 2010-11-24 21:51 ` Drew Adams 0 siblings, 1 reply; 30+ messages in thread From: Julien Danjou @ 2010-11-24 21:33 UTC (permalink / raw) To: Drew Adams; +Cc: 'Ted Zlatanov', emacs-devel <#secure method=pgpmime mode=sign> On Wed, Nov 24 2010, Drew Adams wrote: > 1. Change any calls of those two functions to use the corresponding hexrgb.el > functions instead. Then test the color-lab use (the two versions might not be > exactly equivalent, even if they do essentially the same thing). These 2 functions are not used by any code in color-lab (or Gnus). They have been merged in because, well, I wrote them so it seemed like a good idea to no throw them in the trash right. > 2. Since there is apparently no other overlap, put all of the code from the two > libraries into a single file. > > 3. Choose a new file name and fix the name prefixes accordingly. "hexrgb" is > probably not general enough (it is not even general enough for all that it does > now, since the name reflects only RGB, not HSV). I don't think "color-lab" is a > good name for this general library either; this is not just about CIELAB. > > How about just "color.el"? Since it will end in Emacs, fine with me. I did not choose color.el on start on Lars advice, since, that name was too generic. But a generic name for a generic color library in Emacs sounds good. :) > Yidong might want to do #4, since it involves some deciding and he is familiar > with the Emacs `read-color' code and recent changes. I agree. > Why not merge only the parts of color-lab.el that involve color manipulations > with hexrgb.el, and keep the rest (e.g. heuristics about readability and > color-blindness, color-vision profiles, HTML use etc.) in a separate Emacs > library? It's already in a separate library called shr-color.el. > IOW, _if_ color-lab.el has both (a) general color-manipulation/conversion > functions and (b) application-specific functions that use those general > functions, then wouldn't it make sense to keep the latter separate? (No, I > don't care - it's just a question.) It has only (a). What I can do on my side is: 1. Rename color-lab.el to color.el 2. Merge things other people sends inside, as long as it's basic color manipulation related stuff (conversion, etc). Sounds good? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal. 2010-11-24 21:33 ` Julien Danjou @ 2010-11-24 21:51 ` Drew Adams 0 siblings, 0 replies; 30+ messages in thread From: Drew Adams @ 2010-11-24 21:51 UTC (permalink / raw) To: 'Julien Danjou'; +Cc: 'Ted Zlatanov', emacs-devel > Sounds good? Sounds fine to me. hexrgb.el is here: http://www.emacswiki.org/emacs/hexrgb.el. See my earlier mail for some specific considerations. Let me know if you have any questions. Someone will need to decide about the eyedropper stuff. You can DTRT based on that decision. Since there are currently no dependencies between the hexrgb stuff and the CIE stuff, we might want to have two separate sections in the file, separated by, e.g., `C-q C-l' and a comment. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 9:08 ` Julien Danjou 2010-11-24 11:35 ` Eli Zaretskii 2010-11-24 16:15 ` Drew Adams @ 2010-11-24 16:29 ` Chong Yidong 2 siblings, 0 replies; 30+ messages in thread From: Chong Yidong @ 2010-11-24 16:29 UTC (permalink / raw) To: Drew Adams; +Cc: 'Lars Magne Ingebrigtsen', emacs-devel Julien Danjou <julien@danjou.info> writes: >> You seem to be describing something oriented toward a particular >> application: "just distant enough to improve readability" or some >> such. It would not be off-topic for hexrgb to include such a >> color-distance metric. I just haven't needed that so I haven't added >> it. > > Color-lab has been built upon a specific need, which resulted in the > CIE Delta E 2000 formula to be implemented. Some helper functions > dealing with colors have been written, like CIE XYZ and CIE Lab > conversion in the process. I see; thanks for the explanation, and for writing the CIEDE functions, and I apologize if I was too gruff in my earlier emails. But the basic point stands. The color-lab.el file describes itself thusly: ;; This package provides color manipulation functions. No mention of CIEDE here, and rightly so; what's needed is a general-purpose color manipulation library, and CIEDE is only one piece of such a library. Such a library does not belong in the Gnus subdirectory tree. So, shall we pull the file out into Emacs? Then we can merge it with hexrgb.el, and maybe move `read-color' there as well. ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 22:18 ` Chong Yidong 2010-11-23 22:34 ` Lars Magne Ingebrigtsen @ 2010-11-24 0:05 ` Drew Adams 1 sibling, 0 replies; 30+ messages in thread From: Drew Adams @ 2010-11-24 0:05 UTC (permalink / raw) To: 'Chong Yidong', emacs-devel > I see. Why not just use hexrgb.el (or build on it)? It's been around > long enough that such teething problems should have been eliminated. > > Drew Adams has an assignment on file; if he is willing to include > hexrgb.el under that assignment, we could simply add that to Emacs. > Whatever additional functionality you need that isn't already present, > you could then simply add. Almost missed this mail - haven't been following this thread. Yes, you can include hexrgb.el in Emacs if you want. There is no doubt some overlap between `hexrgb-read-color' in hexrgb.el and `read-color' in Emacs (originally from hexrgb.el, but modified since). Someone should take a look, to see if you need to merge/adapt some things (e.g. in facemenu.el). Some things like extra defcustom :group's will need to be removed from the hexrgb.el code. Some of the hexrgb.el code uses functions and vars from eyedropper.el, but not in any essential way. This part lets you use colors that you pick up from under the cursor or the pointer, as with an eyedrop. These parts can be cut out of the hexrgb.el code, or you can also include eyedropper.el in Emacs (it is small). Some of the eyedropper.el functions have already been added to Emacs (`face-at-point' is `eyedropper-face-at-point' etc.). That's another possibility: add the eyedropper.el code but drop the prefix `eyedrop-'. There are two places where the hexgrb.el code is conditional for Emacs 20: - work around an Emacs 20 bug: (= N N) returns t for a Nan - use of `try-completion' if `test-completion' is not defined These are short enough and benign enough that I'd hope they could stay in the code. I'm willing to make changes that you request. If there are no incompatible changes, so I can also use it for my local needs, then I won't need to also maintain it separately (locally). Otherwise (incompatible changes, stuff removed that I need), then I will either need to also maintain a local version or move the differences to another local file. Depends on what changes you require. The code is here: http://www.emacswiki.org/emacs/hexrgb.el http://www.emacswiki.org/emacs/eyedropper.el ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 21:31 ` Chong Yidong 2010-11-23 21:38 ` Lars Magne Ingebrigtsen @ 2010-11-24 8:36 ` Richard Stallman 2010-11-24 14:42 ` Stefan Monnier 1 sibling, 1 reply; 30+ messages in thread From: Richard Stallman @ 2010-11-24 8:36 UTC (permalink / raw) To: Chong Yidong; +Cc: yamaoka, emacs-devel By that logic, we should move all of Emacs into the Gnus tree. This is a general purpose library, not specific to Gnus. It really ought to be moved out into the Emacs tree. If no one objects, I'm going to move it. Hear, hear. There has been a tendency for all sorts of code unrelated to Gnus to get installed in Emacs through Gnus. Some of these things were worth including in Emacs, but handling them as part of Gnus meant they did not get properly integrated, properly documented, etc. I moved some of them out of Gnus, but I didn't have time to do them all. It would be really good to start always handling these programs the right way, by installing them in Emacs outside of Gnus. -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-24 8:36 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert " Richard Stallman @ 2010-11-24 14:42 ` Stefan Monnier 0 siblings, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2010-11-24 14:42 UTC (permalink / raw) To: rms; +Cc: Chong Yidong, yamaoka, emacs-devel > There has been a tendency for all sorts of code unrelated to Gnus to > get installed in Emacs through Gnus. Some of these things were worth > including in Emacs, but handling them as part of Gnus meant they did > not get properly integrated, properly documented, etc. I think there is a dual way to look at it: Gnus goes through the trouble to try and cleanly modularize its code into sub-packages that can be useful in their own right. I think it's not very realistic to expect them to first get the package included in Emacs, since Gnus also supports older Emacsen (as well as (S)XEmacs). So, yes, maybe the Gnus maintainers could be more proactive in discussing new sub-packages with us, but we should also try to be more understanding. I really don't think there's ill-will on either side. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 20:24 ` Chong Yidong 2010-11-23 21:14 ` Julien Danjou @ 2010-11-23 21:16 ` Lars Magne Ingebrigtsen 2010-11-23 22:19 ` Ted Zlatanov 1 sibling, 1 reply; 30+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-11-23 21:16 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@stupidchicken.com> writes: > Why is this non-gnus-related library being checked into the Gnus > repository? It's used by the HTML rendering library used by Gnus. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 21:16 ` Lars Magne Ingebrigtsen @ 2010-11-23 22:19 ` Ted Zlatanov 0 siblings, 0 replies; 30+ messages in thread From: Ted Zlatanov @ 2010-11-23 22:19 UTC (permalink / raw) To: emacs-devel; +Cc: Katsumi Yamaoka On Tue, 23 Nov 2010 22:16:51 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Chong Yidong <cyd@stupidchicken.com> writes: >> Why is this non-gnus-related library being checked into the Gnus >> repository? LMI> It's used by the HTML rendering library used by Gnus. There are others like it, living in the Gnus repo and outside of Gnus in the Emacs repo (e.g. message.el and imap.el). We just need Yamaoka-san to adjust the synchronization scripts to drop color-lab.el into a different location in the Emacs tree. I don't know how he does it but it's not a big deal for other packages like message.el and imap.el IIUC. Ted ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal. 2010-11-23 19:50 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal Glenn Morris 2010-11-23 20:24 ` Chong Yidong @ 2010-11-23 21:14 ` Julien Danjou 1 sibling, 0 replies; 30+ messages in thread From: Julien Danjou @ 2010-11-23 21:14 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel On Tue, Nov 23 2010, Glenn Morris wrote: >> color-lab.el: New file. > > This needs cl when compiling. (This is flagged by the compiler.) I'll try to take a look to remove that, thanks. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2010-12-10 19:19 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E1PKgZg-0005td-8L@internal.in.savannah.gnu.org> 2010-11-23 19:50 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert colors to hexadecimal with shr-color->hexadecimal Glenn Morris 2010-11-23 20:24 ` Chong Yidong 2010-11-23 21:14 ` Julien Danjou 2010-11-23 21:31 ` Chong Yidong 2010-11-23 21:38 ` Lars Magne Ingebrigtsen 2010-11-23 22:18 ` Chong Yidong 2010-11-23 22:34 ` Lars Magne Ingebrigtsen 2010-11-24 0:12 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert " Drew Adams 2010-11-24 9:08 ` Julien Danjou 2010-11-24 11:35 ` Eli Zaretskii 2010-11-24 14:46 ` Stefan Monnier 2010-11-24 15:30 ` Lennart Borgman 2010-11-24 18:15 ` Ted Zlatanov 2010-11-24 21:37 ` Lennart Borgman 2010-11-24 22:19 ` Lars Magne Ingebrigtsen 2010-11-24 22:41 ` Use color-tweaking code to improve face defaults? [was: /srv/bzr/emacs/trunk r1...] Drew Adams 2010-11-25 4:53 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Stefan Monnier 2010-12-10 19:19 ` Ted Zlatanov 2010-11-24 16:15 ` Drew Adams 2010-11-24 18:11 ` Ted Zlatanov 2010-11-24 21:00 ` /srv/bzr/emacs/trunk r102478: shr.el(shr-tag-color-check):Convert colors to hexadecimal withshr-color->hexadecimal Drew Adams 2010-11-24 21:33 ` Julien Danjou 2010-11-24 21:51 ` Drew Adams 2010-11-24 16:29 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check):Convert colors to hexadecimal with shr-color->hexadecimal Chong Yidong 2010-11-24 0:05 ` Drew Adams 2010-11-24 8:36 ` /srv/bzr/emacs/trunk r102478: shr.el (shr-tag-color-check): Convert " Richard Stallman 2010-11-24 14:42 ` Stefan Monnier 2010-11-23 21:16 ` Lars Magne Ingebrigtsen 2010-11-23 22:19 ` Ted Zlatanov 2010-11-23 21:14 ` Julien Danjou
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).