* 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: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: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: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: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: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: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: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: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
* 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: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: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
* 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
* 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: [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: 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-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 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-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
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).