Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

>     shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophe

This still isn't quite right...

If you eval (shr-find-fill-point) on this line:

(For the full transcript of Forbes’ interview with Assange click here.)

it'll try to break after the full stop and before the end parentheses.
Which isn't right...

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

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Katsumi Yamaoka]

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

>>     shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophe

> This still isn't quite right...

> If you eval (shr-find-fill-point) on this line:

> (For the full transcript of Forbes’ interview with Assange click here.)

> it'll try to break after the full stop and before the end parentheses.
> Which isn't right...

Hm, try as I might, I couldn't reproduce it.

(let ((shr-width 70)
      (shr-kinsoku-shorten nil))
  (shr-insert "\
\(For the full transcript of Forbes’ interview with Assange click here.)"))
(For the full transcript of Forbes’ interview with Assange click
here.)nil

Is it due to a locale?

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Katsumi Yamaoka]

Katsumi Yamaoka wrote:
> Hm, try as I might, I couldn't reproduce it.
[...]
> Is it due to a locale?

Not really.  Though the string width of "’" is 1 in an English
locale whereas it is 2 in a Japanese locale[1], it is not a root
cause of why I couldn't reproduce the problem.  I've modified it
so as not to break a line between kinsoku-bol characters, i.e.
"." and ")".

[1]
(let ((c ?’)
      (lang current-language-environment)
      e j)
  (set-language-environment "English")
  (setq e (list (char-width c) (split-char c)))
  (set-language-environment "Japanese")
  (setq j (list (char-width c) (split-char c)))
  (set-language-environment lang)
  (list e j))
 => ((1 (unicode 0 32 25)) (2 (japanese-jisx0208 33 71)))

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Though the string width of "’" is 1 in an English
> locale whereas it is 2 in a Japanese locale[1], it is not a root
> cause of why I couldn't reproduce the problem.  I've modified it
> so as not to break a line between kinsoku-bol characters, i.e.
> "." and ")".

Thanks; this fixes the problem for me, too.

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

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Lars Magne Ingebrigtsen]

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

>> Though the string width of "’" is 1 in an English
>> locale whereas it is 2 in a Japanese locale[1], it is not a root
>> cause of why I couldn't reproduce the problem.  I've modified it
>> so as not to break a line between kinsoku-bol characters, i.e.
>> "." and ")".
>
> Thanks; this fixes the problem for me, too.

But now the presence of a "'" character makes shr not break before the
word at all.

(shr-find-fill-point) on the following line:

tonight when the Denver Police Department Bomb Squad detonated the 'suspicious

will move point to the end of the line, instead of after "the".

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

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Adam Sjøgren]

On Sat, 04 Dec 2010 20:35:53 +0100, Lars wrote:

> But now the presence of a "'" character makes shr not break before the
> word at all.

[...]

Would this also be why I just saw this curious line-wrap:

  Searching for the vendor id:product id of the device, 0c45:0011, didn'
  t return much - basically the only reference I could find was a blog-

in a gwene article?


  Best regards,

    Adam

-- 
 "I myself have spent many an enjoyable hour in my            Adam Sjøgren
  spare time not collecting stamps."                     asjo@koldfront.dk

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Lars Magne Ingebrigtsen]

asjo@koldfront.dk (Adam Sjøgren) writes:

> Would this also be why I just saw this curious line-wrap:
>
>   Searching for the vendor id:product id of the device, 0c45:0011, didn'
>   t return much - basically the only reference I could find was a blog-
>
> in a gwene article?

Was this with the latest git?  It's supposed to fix the
break-after-apostrophe thing.

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

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Adam Sjøgren]

On Sat, 04 Dec 2010 23:20:33 +0100, Lars wrote:

> Was this with the latest git?  It's supposed to fix the
> break-after-apostrophe thing.

I hadn't update; *blush*. Works great after a fresh pull.


  Best regards,

    Adam

-- 
 "We get our thursdays from a banana."                        Adam Sjøgren
                                                         asjo@koldfront.dk

Re: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.

[Katsumi Yamaoka]

Lars wrote:
> (shr-find-fill-point) on the following line:

tonight when the Denver Police Department Bomb Squad detonated the 'suspicious

> will move point to the end of the line, instead of after "the".

Because "'" is categorized as kinsoku-bol, that should not appear
in the beginning of a line.  But I've modified the code so as to
give it special treatment.  Thanks.

shr line breaking (was: [gnus git] branch master updated: =1= shr.el (shr-find-fill-point): Work better for kinsoku chars and apostrophes.)

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Because "'" is categorized as kinsoku-bol, that should not appear
> in the beginning of a line.  But I've modified the code so as to
> give it special treatment.  Thanks.

Thanks.  But I'm starting to wonder whether the line breaking algo
should be broken up into two bits -- one for Japanese (etc.) text an one
for the rest.

Like the following line:

names like www.example.com into the numeric IP addresses like 192.0.2.1

(shr-find-fill-point) will put point before the "1", which is wrong in
this instance.  Non-CJVK texts can only be broken where there's a space
character, so perhaps we need additional logic to find out whether a
(part of a) line is CJVK or not before trying to find the fill point?
This may be difficult on mixed texts, perhaps...

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

Re: shr line breaking

[Katsumi Yamaoka]

Lars Magne Ingebrigtsen wrote:
> Like the following line:

names like www.example.com into the numeric IP addresses like 192.0.2.1

> (shr-find-fill-point) will put point before the "1", which is wrong in
> this instance.

It happens with Japanese text, too. ;-)

www.example.com のような名前は次のような数字の IP アドレスに＞192.0.2.1

I've fixed it so that it may not break a line after a kinsoku-bol
character (i.e., "." etc.) if a non-breakable character follows.

> Non-CJVK texts can only be broken where there's a space
> character, so perhaps we need additional logic to find out whether a
> (part of a) line is CJVK or not before trying to find the fill point?
> This may be difficult on mixed texts, perhaps...

Yes, I also think it's difficult to distinguish CJVK text and others,
especially in unicode Emacsen.  For instance, even a latin-1 character
is regarded as Japanese:

(string-match "\\cj" "Ø") -> 0

In Emacs 22.3 and earlier, it was nil.

Re: shr line breaking

[Lars Magne Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> I've fixed it so that it may not break a line after a kinsoku-bol
> character (i.e., "." etc.) if a non-breakable character follows.

Thanks.  I haven't seen any odd line breaking after you applied that
patch.

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