small highlight problem with shr.el

small highlight problem with shr.el

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

I use a wide screen (200+ columns) but articles are wrapped at 80
columns.  So I often see this (any highlight will do, as long as it
changes the background color):

text text text <b>BOLD BOLD[column 80]bbbbbbbbbbbbbbbb[column 200]
BOLD</b> text text

Where "bbbbbbbbbbbbbbbb" is a continuation of the background
highlight to the next line.  It looks ugly.  Here's a screenshot:


[-- Attachment #2: highlight-goes-on.png --]
[-- Type: image/png, Size: 4511 bytes --]

[-- Attachment #3: Type: text/plain, Size: 5 bytes --]


Ted

Re: small highlight problem with shr.el

[Katsumi Yamaoka]

Ted Zlatanov wrote:
> I use a wide screen (200+ columns) but articles are wrapped at 80
> columns.  So I often see this (any highlight will do, as long as it
> changes the background color):

> text text text <b>BOLD BOLD[column 80]bbbbbbbbbbbbbbbb[column 200]
> BOLD</b> text text

> Where "bbbbbbbbbbbbbbbb" is a continuation of the background
> highlight to the next line.  It looks ugly.  Here's a screenshot:

I often see it in the customization buffer for string (or function,
etc.) options.  But it seems troublesome to make ELisp code exclude
newlines while highlighting text.  How about asking Emacs team to
introduce a new user option?  It defaults to t and newlines will
never be highlighted.

Re: small highlight problem with shr.el

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I often see it in the customization buffer for string (or function,
> etc.) options.  But it seems troublesome to make ELisp code exclude
> newlines while highlighting text.  How about asking Emacs team to
> introduce a new user option?  It defaults to t and newlines will
> never be highlighted.

That would be generally useful, but I'm not sure it would help in shr.
If you have indented text like this:

    Text that is
    underlined over two lines

Then you don't want the indentation to have the underline, and you don't
want to the newline to have it, either.  So I think the shr highlighting
code has to insert split font properties anyway...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: small highlight problem with shr.el

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> I often see it in the customization buffer for string (or function,
>> etc.) options.  But it seems troublesome to make ELisp code exclude
>> newlines while highlighting text.  How about asking Emacs team to
>> introduce a new user option?  It defaults to t and newlines will
>> never be highlighted.

> That would be generally useful, but I'm not sure it would help in shr.
> If you have indented text like this:

>     Text that is
>     underlined over two lines

> Then you don't want the indentation to have the underline, and you don't
> want to the newline to have it, either.  So I think the shr highlighting
> code has to insert split font properties anyway...

The new user option can be a regexp like " *\n *".  ;-p

Re: small highlight problem with shr.el

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Where "bbbbbbbbbbbbbbbb" is a continuation of the background
> highlight to the next line.  It looks ugly.  Here's a screenshot:

Should be fixed now.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: small highlight problem with shr.el

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The new user option can be a regexp like " *\n *".  ;-p

:-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: small highlight problem with shr.el

[Ted Zlatanov]

On Thu, 21 Oct 2010 03:44:53 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Where "bbbbbbbbbbbbbbbb" is a continuation of the background
>> highlight to the next line.  It looks ugly.  Here's a screenshot:

LMI> Should be fixed now.

Confirmed.  Thank you!

Ted

Re: small highlight problem with shr.el

[Ted Zlatanov]

On Thu, 21 Oct 2010 13:22:48 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 21 Oct 2010 03:44:53 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 
LMI> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> Where "bbbbbbbbbbbbbbbb" is a continuation of the background
>>> highlight to the next line.  It looks ugly.  Here's a screenshot:

LMI> Should be fixed now.

TZ> Confirmed.  Thank you!

I noticed this highlight problem happens with mouse hover.  When a link
spans a newline and the pointer hovers over the link, the newline is
highlighted to the end of the window.  It's a really minor issue but I
thought I'd mention it.

Ted

Re: small highlight problem with shr.el

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> I noticed this highlight problem happens with mouse hover.  When a link
> spans a newline and the pointer hovers over the link, the newline is
> highlighted to the end of the window.  It's a really minor issue but I
> thought I'd mention it.

That's actually not easy to fix.  :-/  shr uses `widget-convert-button'
to make stuff into buttons, and that takes a region.  If shr were to
break up the region, then there would be two buttons, and `TAB' would
stop twice in the same link...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: small highlight problem with shr.el

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> If shr were to break up the region, then there would be two buttons,
> and `TAB' would stop twice in the same link...

This is what happens with buttons in tables, by the way, and it's
slightly annoying.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen