* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix [not found] <E1PPcjn-0002Xs-00@quimby.gnus.org> @ 2010-12-06 15:24 ` Lars Magne Ingebrigtsen 2010-12-06 15:26 ` Lars Magne Ingebrigtsen 2010-12-06 15:54 ` Julien Danjou 0 siblings, 2 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 15:24 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > - (let ((color (cdr (assq :color shr-stylesheet))) > - (background (cdr (assq :background-color > - shr-stylesheet)))) > - (when (and shr-stylesheet > - (or color background)) > - (shr-colorize-region start (point) color background))))) > + ;; Apply style > + (shr-colorize-region start (point) > + (cdr (assq 'color shr-stylesheet)) > + (cdr (assq 'background-color shr-stylesheet))))) The point of doing it this way is that if you have <p style="color: red">foo<p>bar<p>zot then each of these will apply "red" to their own bits. That's slow an unnecessary, since, just having the top-level <p> do it will yield exactly the same result, won't it? > - (shr-stylesheet (list (cons :color fgcolor) > - (cons :background-color bgcolor)))) > - (shr-generic cont) > - (shr-colorize-region start (point) fgcolor bgcolor))) > + (shr-stylesheet (if fgcolor > + (if bgcolor > + `((color . ,fgcolor) > + (background-color . ,bgcolor) ,@shr-stylesheet) > + `((color . ,fgcolor) ,@shr-stylesheet)) > + (if bgcolor > + `((background-color . ,bgcolor) ,@shr-stylesheet) > + shr-stylesheet)))) > + (shr-generic cont))) Same thing here, basically. A <body bgcolor> will now result in absolutely every element compute and apply their colour, which is slow. Etc. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 15:24 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Lars Magne Ingebrigtsen @ 2010-12-06 15:26 ` Lars Magne Ingebrigtsen 2010-12-06 15:54 ` Julien Danjou 1 sibling, 0 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 15:26 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > <p style="color: red">foo<p>bar<p>zot > > then each of these will apply "red" to their own bits. That's slow an > unnecessary, since, just having the top-level <p> do it will yield > exactly the same result, won't it? I mean with <divs>. And with more and better grammer. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 15:24 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Lars Magne Ingebrigtsen 2010-12-06 15:26 ` Lars Magne Ingebrigtsen @ 2010-12-06 15:54 ` Julien Danjou 2010-12-06 16:00 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 15:54 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1232 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > The point of doing it this way is that if you have > > <p style="color: red">foo<p>bar<p>zot > > then each of these will apply "red" to their own bits. That's slow an > unnecessary, since, just having the top-level <p> do it will yield > exactly the same result, won't it? In that example yes. But with: <p style="background-color: red">foo<p style="color: red">bar<p>zot The result should be quite different. With the previous code, you would: - Insert `foo' - Insert `bar' - Paint `bar' in red - Insert zot - Paint the backgruond for foobarzot in red. bar was invisible: red on red. The color checker had no clue that the background was red. Now it does: - Insert `foo' - Enhance the style of the next p with "background-color: red" - Insert `bar' - Paint `bar' in red with a red background… Wait? No the color check steps in and choose better color in the rainbow just for you! HAHA! - Insert `zot' - Paint foobarzot with a red background, but not bar, since shr-put-color have some magic to not override color information IIUC. Sounds good? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 15:54 ` Julien Danjou @ 2010-12-06 16:00 ` Lars Magne Ingebrigtsen 2010-12-06 16:03 ` Lars Magne Ingebrigtsen 2010-12-06 16:17 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Julien Danjou 0 siblings, 2 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:00 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > In that example yes. But with: > > <p style="background-color: red">foo<p style="color: red">bar<p>zot > > The result should be quite different. > > With the previous code, you would: > - Insert `foo' > - Insert `bar' > - Paint `bar' in red > - Insert zot > - Paint the backgruond for foobarzot in red. > > bar was invisible: red on red. The color checker had no clue that the > background was red. Are you sure? Since it inherited the background-color from the parent, it should have used it when it rendered the bar. So that you didn't get red-on-red. Let's see... yup: (when (and style (string-match "color" style)) (setq shr-stylesheet (nconc (shr-parse-style style) shr-stylesheet))) We add our stuff to what our parent(s) had... [...] (let ((color (cdr (assq 'color shr-stylesheet))) (background (cdr (assq 'background-color shr-stylesheet)))) (when (and shr-stylesheet (or color background)) (shr-colorize-region start (point) color background))))) ... and then use it. Should work, I think. Well, actually, it's rendering things too much -- it should have a (and (string-match "color" style)) in there, too, probably. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:00 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:03 ` Lars Magne Ingebrigtsen 2010-12-06 16:18 ` Julien Danjou 2010-12-06 16:17 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Julien Danjou 1 sibling, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:03 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Should work, I think. This is actually the test case I was using while writing the code: ----- <body bgcolor="yellow"> <div style="color: red; background-color: white;"> Foo la la la <div style="color: white;"> Bar </div> </div> <div style="color: blue;"> Zot ----- The "Bar" is white on white, but is rendered legibly through the magic of color.el. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:03 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:18 ` Julien Danjou 2010-12-06 16:25 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 16:18 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 515 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > This is actually the test case I was using while writing the code: > > ----- > <body bgcolor="yellow"> > <div style="color: red; background-color: white;"> > Foo la la la > <div style="color: white;"> > Bar > </div> > </div> > <div style="color: blue;"> > Zot > ----- Btw, I just saw that the libxml function seems to mangle the <style> tag content. How's that? -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:18 ` Julien Danjou @ 2010-12-06 16:25 ` Lars Magne Ingebrigtsen 2010-12-06 16:36 ` Julien Danjou 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:25 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Btw, I just saw that the libxml function seems to mangle the <style> tag > content. How's that? In what way? This is the parse tree I'm getting from (libxml-parse-html-region (mark) (point)): (html nil (body nil "\n" (div ((style . "color: red; background-color: white;")) "\nFoo la la la\n" (div ((style . "color: white;")) "\nBar\n") "\n") "\n" (div ((style . "color: blue;")) "\nZot\n"))) Or, more understandably :-) (pp (shr-transform-dom a) (current-buffer)) (html (body (text . "\n") (div (:style . "color: red; background-color: white;") (text . "\nFoo la la la\n") (div (:style . "color: white;") (text . "\nBar\n")) (text . "\n")) (text . "\n") (div (:style . "color: blue;") (text . "\nZot\n")))) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:25 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:36 ` Julien Danjou 2010-12-06 16:41 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 16:36 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 544 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > Julien Danjou <julien@danjou.info> writes: > >> Btw, I just saw that the libxml function seems to mangle the <style> tag >> content. How's that? > > In what way? I do mean <style>, not <bla style="bar"> (with-temp-buffer (insert "<body> <style> a { color: red; } </style> </body>") (libxml-parse-html-region (point-min) (point-max))) => (html nil (body nil " " (style nil nil))) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:36 ` Julien Danjou @ 2010-12-06 16:41 ` Lars Magne Ingebrigtsen 2010-12-06 16:55 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:41 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I do mean <style>, not <bla style="bar"> Oh. Huh. Why would it do that? Is libxml2 special-casing the <style> tag? I would have expected it to just return the body as a string... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:41 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:55 ` Lars Magne Ingebrigtsen 2010-12-06 17:32 ` colourising newlines (was: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix) Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:55 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Oh. Huh. Why would it do that? Is libxml2 special-casing the <style> > tag? I would have expected it to just return the body as a string... Oh, I found the bug. I'll push a fix now. (The <style> contents are parsed as a CDATA section, naturally enough, which isn't handled by xml.c.). -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* colourising newlines (was: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix) 2010-12-06 16:55 ` Lars Magne Ingebrigtsen @ 2010-12-06 17:32 ` Lars Magne Ingebrigtsen 2010-12-14 23:51 ` colourising newlines Ted Zlatanov 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 17:32 UTC (permalink / raw) To: ding Which reminds me: Do we want to colourise the newlines or don't we? It can be somewhat awkward either way. If we do, them background colours extend to the end of the frame. If we don't, then the text with the background colour looks ragged. Both look, er, non-optimal, but I think I may prefer the text to extend to the right, now that I've used it for several minutes... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-06 17:32 ` colourising newlines (was: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix) Lars Magne Ingebrigtsen @ 2010-12-14 23:51 ` Ted Zlatanov 2010-12-15 19:30 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Ted Zlatanov @ 2010-12-14 23:51 UTC (permalink / raw) To: ding On Mon, 06 Dec 2010 18:32:16 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Which reminds me: Do we want to colourise the newlines or don't we? LMI> It can be somewhat awkward either way. If we do, them background LMI> colours extend to the end of the frame. If we don't, then the LMI> text with the background colour looks ragged. LMI> Both look, er, non-optimal, but I think I may prefer the text to extend LMI> to the right, now that I've used it for several minutes... The background should extend to the end of the max line length in the current paragraph + 1 more space. I know it's a pain but it will look good. Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-14 23:51 ` colourising newlines Ted Zlatanov @ 2010-12-15 19:30 ` Lars Magne Ingebrigtsen 2010-12-15 21:03 ` Ted Zlatanov 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-15 19:30 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > The background should extend to the end of the max line length in the > current paragraph + 1 more space. I know it's a pain but it will look > good. But that means inserting spaces at the end of the lines. It looks good, but it sucks for cut'n'paste and the like. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 19:30 ` Lars Magne Ingebrigtsen @ 2010-12-15 21:03 ` Ted Zlatanov 2010-12-15 21:30 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Ted Zlatanov @ 2010-12-15 21:03 UTC (permalink / raw) To: ding On Wed, 15 Dec 2010 20:30:52 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> The background should extend to the end of the max line length in the >> current paragraph + 1 more space. I know it's a pain but it will look >> good. LMI> But that means inserting spaces at the end of the lines. It looks good, LMI> but it sucks for cut'n'paste and the like. Does it? Maybe you can font-lock it to take N spaces but actually be zero. I don't know, honestly, but dammit I know what looks good and ragged backgrounds are not it :) Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 21:03 ` Ted Zlatanov @ 2010-12-15 21:30 ` Lars Magne Ingebrigtsen 2010-12-15 21:40 ` Ted Zlatanov ` (2 more replies) 0 siblings, 3 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-15 21:30 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > Does it? Maybe you can font-lock it to take N spaces but actually be > zero. I don't think that's possible with Emacs' display engine, but I'd love to be wrong on that point. > I don't know, honestly, but dammit I know what looks good and ragged > backgrounds are not it :) No, it looks quite awkward at present. Perhaps colourising the newline (i.e., extending the colour block up to the right frame end) is the best of two not very good options. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 21:30 ` Lars Magne Ingebrigtsen @ 2010-12-15 21:40 ` Ted Zlatanov 2010-12-16 15:54 ` Lars Magne Ingebrigtsen 2010-12-16 20:25 ` Eric S Fraga 2011-01-19 22:24 ` Ted Zlatanov 2 siblings, 1 reply; 33+ messages in thread From: Ted Zlatanov @ 2010-12-15 21:40 UTC (permalink / raw) To: ding On Wed, 15 Dec 2010 22:30:00 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> Does it? Maybe you can font-lock it to take N spaces but actually be >> zero. LMI> I don't think that's possible with Emacs' display engine, but I'd love LMI> to be wrong on that point. Who would know, emacs-devel? >> I don't know, honestly, but dammit I know what looks good and ragged >> backgrounds are not it :) LMI> No, it looks quite awkward at present. Perhaps colourising the newline LMI> (i.e., extending the colour block up to the right frame end) is the best LMI> of two not very good options. I'll go with whatever you think is best. On my system I have a 2000+ pixels wide monitor so that's a *lot* of extension, but it's better than ragged backgrounds. Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 21:40 ` Ted Zlatanov @ 2010-12-16 15:54 ` Lars Magne Ingebrigtsen 2010-12-16 20:43 ` Ted Zlatanov 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-16 15:54 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > LMI> I don't think that's possible with Emacs' display engine, but I'd love > LMI> to be wrong on that point. > > Who would know, emacs-devel? I guess so... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-16 15:54 ` Lars Magne Ingebrigtsen @ 2010-12-16 20:43 ` Ted Zlatanov 0 siblings, 0 replies; 33+ messages in thread From: Ted Zlatanov @ 2010-12-16 20:43 UTC (permalink / raw) To: ding On Thu, 16 Dec 2010 16:54:15 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: LMI> I don't think that's possible with Emacs' display engine, but I'd love LMI> to be wrong on that point. >> >> Who would know, emacs-devel? LMI> I guess so... Asked in <87oc8la5u2.fsf@lifelogs.com> Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 21:30 ` Lars Magne Ingebrigtsen 2010-12-15 21:40 ` Ted Zlatanov @ 2010-12-16 20:25 ` Eric S Fraga 2010-12-17 16:43 ` Lars Magne Ingebrigtsen 2011-01-19 22:24 ` Ted Zlatanov 2 siblings, 1 reply; 33+ messages in thread From: Eric S Fraga @ 2010-12-16 20:25 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Ted Zlatanov <tzz@lifelogs.com> writes: > >> Does it? Maybe you can font-lock it to take N spaces but actually be >> zero. > > I don't think that's possible with Emacs' display engine, but I'd love > to be wrong on that point. > >> I don't know, honestly, but dammit I know what looks good and ragged >> backgrounds are not it :) > > No, it looks quite awkward at present. Perhaps colourising the newline > (i.e., extending the colour block up to the right frame end) is the best > of two not very good options. What about using an overlay (with appropriate face) instead of font-locking, as is done by hl-line mode (cf. hl-line.el in emacs 23.2 at least). This mode overlays a background from the left edge of the window to the right edge regardless of the number of characters on the line (i.e. no space padding required) and the code in hl-line-move looks like it could easily be extended to cover a number of lines instead of just a single line? Just a thought from an elisp novice... so feel free to ignore me (as many do ;-). -- : Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 23.2.1 + No Gnus v0.11 ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-16 20:25 ` Eric S Fraga @ 2010-12-17 16:43 ` Lars Magne Ingebrigtsen 2010-12-18 19:20 ` Eric S Fraga 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-17 16:43 UTC (permalink / raw) To: ding Eric S Fraga <e.fraga@ucl.ac.uk> writes: > This mode overlays a background from the left edge of the window to > the right edge regardless of the number of characters on the line > (i.e. no space padding required) Avoiding having the background colour extend to the right edge was was this debate was about. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-17 16:43 ` Lars Magne Ingebrigtsen @ 2010-12-18 19:20 ` Eric S Fraga 0 siblings, 0 replies; 33+ messages in thread From: Eric S Fraga @ 2010-12-18 19:20 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Eric S Fraga <e.fraga@ucl.ac.uk> writes: > >> This mode overlays a background from the left edge of the window to >> the right edge regardless of the number of characters on the line >> (i.e. no space padding required) > > Avoiding having the background colour extend to the right edge was was > this debate was about. :-) <blush> mis-read the thread... :( Apologies for noise etc. </blush> -- Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2010-12-15 21:30 ` Lars Magne Ingebrigtsen 2010-12-15 21:40 ` Ted Zlatanov 2010-12-16 20:25 ` Eric S Fraga @ 2011-01-19 22:24 ` Ted Zlatanov 2011-01-22 3:02 ` Lars Ingebrigtsen 2 siblings, 1 reply; 33+ messages in thread From: Ted Zlatanov @ 2011-01-19 22:24 UTC (permalink / raw) To: ding On Wed, 15 Dec 2010 22:30:00 +0100 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: LMI> Ted Zlatanov <tzz@lifelogs.com> writes: >> Does it? Maybe you can font-lock it to take N spaces but actually be >> zero. LMI> I don't think that's possible with Emacs' display engine, but I'd love LMI> to be wrong on that point. >> I don't know, honestly, but dammit I know what looks good and ragged >> backgrounds are not it :) LMI> No, it looks quite awkward at present. Perhaps colourising the newline LMI> (i.e., extending the colour block up to the right frame end) is the best LMI> of two not very good options. Chong Yidong had a suggestion about this on emacs-devel, I don't know if you saw it. Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2011-01-19 22:24 ` Ted Zlatanov @ 2011-01-22 3:02 ` Lars Ingebrigtsen 2011-01-24 19:46 ` Ted Zlatanov 0 siblings, 1 reply; 33+ messages in thread From: Lars Ingebrigtsen @ 2011-01-22 3:02 UTC (permalink / raw) To: ding Ted Zlatanov <tzz@lifelogs.com> writes: > Chong Yidong had a suggestion about this on emacs-devel, I don't know if > you saw it. I don't think so? -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: colourising newlines 2011-01-22 3:02 ` Lars Ingebrigtsen @ 2011-01-24 19:46 ` Ted Zlatanov 0 siblings, 0 replies; 33+ messages in thread From: Ted Zlatanov @ 2011-01-24 19:46 UTC (permalink / raw) To: ding On Sat, 22 Jan 2011 04:02:13 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: LI> Ted Zlatanov <tzz@lifelogs.com> writes: >> Chong Yidong had a suggestion about this on emacs-devel, I don't know if >> you saw it. LI> I don't think so? Cross-posted followup. Basically he said "use a display string on top of the newline." I have no idea if it will work. Ted ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:00 ` Lars Magne Ingebrigtsen 2010-12-06 16:03 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:17 ` Julien Danjou 2010-12-06 16:22 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 16:17 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1925 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > Let's see... yup: > > (when (and style > (string-match "color" style)) > (setq shr-stylesheet (nconc (shr-parse-style style) > shr-stylesheet))) > > We add our stuff to what our parent(s) had... I think you're cheating. :) Yes you are inheriting, I did not change that code, but the parent did not set the background-color in shr-styleshset. It does now that I changed some code to things like: (defun shr-tag-font (cont) - (let ((start (point)) - (color (cdr (assq :color cont)))) - (shr-generic cont) - (shr-colorize-region start (point) color))) + (let* ((start (point)) + (color (cdr (assq :color cont))) + (shr-stylesheet (if color + `((color . ,fgcolor) ,@shr-stylesheet) + shr-stylesheet))) + (shr-generic cont))) OTOH, there was a subtle bug. You wrote: (shr-stylesheet (list (cons :color fgcolor) (cons :background-color bgcolor)))) Initially, where as it should have been 'color and 'background-color (: vs quote). So maybe I fixed too much stuff because of that. ;) > (let ((color (cdr (assq 'color shr-stylesheet))) > (background (cdr (assq 'background-color > shr-stylesheet)))) > (when (and shr-stylesheet > (or color background)) > (shr-colorize-region start (point) color background))))) > > ... and then use it. > > Should work, I think. Well, actually, it's rendering things too much -- > it should have a (and (string-match "color" style)) in there, too, > probably. shr-colorize-region does nothing if both colors are nil, so I don't think there is too much to optimize here, unless assq is considered to be slow (I don't know). -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:17 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Julien Danjou @ 2010-12-06 16:22 ` Lars Magne Ingebrigtsen 2010-12-06 16:27 ` Lars Magne Ingebrigtsen 2010-12-06 16:33 ` Julien Danjou 0 siblings, 2 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:22 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: >> (when (and style >> (string-match "color" style)) >> (setq shr-stylesheet (nconc (shr-parse-style style) >> shr-stylesheet))) >> >> We add our stuff to what our parent(s) had... > > I think you're cheating. :) > > Yes you are inheriting, I did not change that code, but the parent did > not set the background-color in shr-styleshset. It adds all the stuff from style="" to the (inherited) style sheet, so if background-color is present, it's inherited. > It does now that I changed some code to things like: [...] > (defun shr-tag-font (cont) Yeah, I didn't do <FONT>. Wasn't part of my test case. :-) > Initially, where as it should have been 'color and 'background-color > (: vs quote). > So maybe I fixed too much stuff because of that. ;) Yeah, I think so. :-) >> (when (and shr-stylesheet >> (or color background)) >> (shr-colorize-region start (point) color background))))) >> >> ... and then use it. >> >> Should work, I think. Well, actually, it's rendering things too much -- >> it should have a (and (string-match "color" style)) in there, too, >> probably. > > shr-colorize-region does nothing if both colors are nil, so I don't > think there is too much to optimize here, unless assq is considered to > be slow (I don't know). If any parent had color/background-color, then shr-colorize-region will be called with those colours. That's the optimisation problem: (let ((color (cdr (assq 'color shr-stylesheet))) (background (cdr (assq 'background-color shr-stylesheet)))) shr-stylesheet here isn't the style="" from the current tag, but the inherited one (that includes the current tag, at this point). -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:22 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:27 ` Lars Magne Ingebrigtsen 2010-12-06 16:48 ` Julien Danjou 2010-12-06 16:33 ` Julien Danjou 1 sibling, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:27 UTC (permalink / raw) To: ding Lars Magne Ingebrigtsen <larsi@gnus.org> writes: > Yeah, I didn't do <FONT>. Wasn't part of my test case. :-) So could you revert all the stuff, and reapply the <font> thing in the old-stylee? It's really much faster for the user. -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:27 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:48 ` Julien Danjou 2010-12-06 17:26 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 16:48 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 320 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > So could you revert all the stuff, and reapply the <font> thing in the > old-stylee? It's really much faster for the user. I've revert all the stuff, and re commit just 2 fixes. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:48 ` Julien Danjou @ 2010-12-06 17:26 ` Lars Magne Ingebrigtsen 2010-12-06 17:30 ` Julien Danjou 0 siblings, 1 reply; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 17:26 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > I've revert all the stuff, and re commit just 2 fixes. Great. I think it now should work... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 17:26 ` Lars Magne Ingebrigtsen @ 2010-12-06 17:30 ` Julien Danjou 2010-12-06 17:33 ` Lars Magne Ingebrigtsen 0 siblings, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 17:30 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 209 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > Great. I think it now should work... Yes, it's not that bad now. :) -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 17:30 ` Julien Danjou @ 2010-12-06 17:33 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 17:33 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Yes, it's not that bad now. :) High praise indeed. :-) -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:22 ` Lars Magne Ingebrigtsen 2010-12-06 16:27 ` Lars Magne Ingebrigtsen @ 2010-12-06 16:33 ` Julien Danjou 2010-12-06 16:36 ` Lars Magne Ingebrigtsen 1 sibling, 1 reply; 33+ messages in thread From: Julien Danjou @ 2010-12-06 16:33 UTC (permalink / raw) To: ding [-- Attachment #1: Type: text/plain, Size: 1381 bytes --] On Mon, Dec 06 2010, Lars Magne Ingebrigtsen wrote: > It adds all the stuff from style="" to the (inherited) style sheet, so > if background-color is present, it's inherited. Yes, but you are forgetting about tag attributes like 'bgcolor': <body bgcolor=...> ^^^^ this one was NOT added to shr-stylesheet, that's what I am talking about. :) > If any parent had color/background-color, then shr-colorize-region will > be called with those colours. That's the optimisation problem: > > (let ((color (cdr (assq 'color shr-stylesheet))) > (background (cdr (assq 'background-color > shr-stylesheet)))) > > shr-stylesheet here isn't the style="" from the current tag, but the > inherited one (that includes the current tag, at this point). I understand, but somehow you have to give the parent's background color so if a children as a foreground color it can check the color. One thing what still does not work correctly though: <body bgcolor="yellow"> <div style="color: red; background-color: white;"> Foo la la la <div style="color: white;"> <font color="red">dwq</font> Bar </div> </div> <div style="color: blue;"> Zot </div> </body> "dwq" will not be in red. That's because I think we are not calling shr-colorize at the right place. -- Julien Danjou // ᐰ <julien@danjou.info> http://julien.danjou.info [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix 2010-12-06 16:33 ` Julien Danjou @ 2010-12-06 16:36 ` Lars Magne Ingebrigtsen 0 siblings, 0 replies; 33+ messages in thread From: Lars Magne Ingebrigtsen @ 2010-12-06 16:36 UTC (permalink / raw) To: ding Julien Danjou <julien@danjou.info> writes: > Yes, but you are forgetting about tag attributes like 'bgcolor': > > <body bgcolor=...> > ^^^^ > this one was NOT added to shr-stylesheet, that's what I am talking > about. :) Because of the typo in :color vs 'color? Yes, that's true... >> If any parent had color/background-color, then shr-colorize-region will >> be called with those colours. That's the optimisation problem: >> >> (let ((color (cdr (assq 'color shr-stylesheet))) >> (background (cdr (assq 'background-color >> shr-stylesheet)))) >> >> shr-stylesheet here isn't the style="" from the current tag, but the >> inherited one (that includes the current tag, at this point). > > I understand, but somehow you have to give the parent's background color > so if a children as a foreground color it can check the color. Yes, that's what happening here. This child will now see the parent's background-color. > <font color="red">dwq</font> [...] > "dwq" will not be in red. That's because I think we are not calling > shr-colorize at the right place. Yes, the <font> tag didn't have a colourisation going on... -- (domestic pets only, the antidote for overdose, milk.) larsi@gnus.org * Lars Magne Ingebrigtsen ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2011-01-24 19:46 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <E1PPcjn-0002Xs-00@quimby.gnus.org>
2010-12-06 15:24 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Lars Magne Ingebrigtsen
2010-12-06 15:26 ` Lars Magne Ingebrigtsen
2010-12-06 15:54 ` Julien Danjou
2010-12-06 16:00 ` Lars Magne Ingebrigtsen
2010-12-06 16:03 ` Lars Magne Ingebrigtsen
2010-12-06 16:18 ` Julien Danjou
2010-12-06 16:25 ` Lars Magne Ingebrigtsen
2010-12-06 16:36 ` Julien Danjou
2010-12-06 16:41 ` Lars Magne Ingebrigtsen
2010-12-06 16:55 ` Lars Magne Ingebrigtsen
2010-12-06 17:32 ` colourising newlines (was: [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix) Lars Magne Ingebrigtsen
2010-12-14 23:51 ` colourising newlines Ted Zlatanov
2010-12-15 19:30 ` Lars Magne Ingebrigtsen
2010-12-15 21:03 ` Ted Zlatanov
2010-12-15 21:30 ` Lars Magne Ingebrigtsen
2010-12-15 21:40 ` Ted Zlatanov
2010-12-16 15:54 ` Lars Magne Ingebrigtsen
2010-12-16 20:43 ` Ted Zlatanov
2010-12-16 20:25 ` Eric S Fraga
2010-12-17 16:43 ` Lars Magne Ingebrigtsen
2010-12-18 19:20 ` Eric S Fraga
2011-01-19 22:24 ` Ted Zlatanov
2011-01-22 3:02 ` Lars Ingebrigtsen
2011-01-24 19:46 ` Ted Zlatanov
2010-12-06 16:17 ` [gnus git] branch master updated: =2= shr: colorize only in one place ; shr: shr-colorize-region fix and stylesheet color retrieval fix Julien Danjou
2010-12-06 16:22 ` Lars Magne Ingebrigtsen
2010-12-06 16:27 ` Lars Magne Ingebrigtsen
2010-12-06 16:48 ` Julien Danjou
2010-12-06 17:26 ` Lars Magne Ingebrigtsen
2010-12-06 17:30 ` Julien Danjou
2010-12-06 17:33 ` Lars Magne Ingebrigtsen
2010-12-06 16:33 ` Julien Danjou
2010-12-06 16:36 ` Lars Magne Ingebrigtsen
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 NNTP newsgroup(s).