417931 - insertHyphenatedWord doesn't respect whitespace at all

Status: RESOLVED FIXED

(Other Applications Graveyard :: ChatZilla, defect)

Description

[James Ross]

The munger uses insertHyphenatedWord everywhere, when it has plain text it wants to add; the problem is that it mearly splits the text up into 20-character chunks (almost), rather than looking for sections of non-whitespace that are >=20ch. This means you get output like this:

Then I guess that <wbr/>(compiled) Python <wbr/>code does not have <wbr/>a simple logical <wbr/>(not texture) repres<wbr/>entation that can <wbr/>be accessed and <wbr/>manipulated from <wbr/>within a Python <wbr/>program, like in <wbr/>e.g. in Mathematica.<wbr/> Is this correct?

splitLongWord looks +/- 5ch for a good place to split, but lands in the middle of "representation" here and has nowhere to go. I think it should probably be using the same regexp as the munger entry to find places to split (or we should find a better way to apply just the word-hyphenator munger to some text).

Comment 1

[:Gijs (he/him)]

Can we just trust Gecko to wrap the spaces? If so, we can simply match for 20+ continuous non-space characters, and split there only (send them into splitLongWord). Does that make sense?

Comment 2

[James Ross]

Yes, we should do some approximation of the munger regexp (or use it directly) to find suitable text to split.

Comment 3

[James Ross]

Attachment: Split insertHyphenatedWord into insertText and itself

The main aim of the split is to differentiate between cases we know need splitting (insertHyphenatedWord) and cases we haven't yet checked (insertText). insertText does a very, very basic munger-like process on the text to call insertHyphenatedWord on the long bits it finds.

I also optimised the use of <span>s when these two functions are used.

Comment 4

[:Gijs (he/him)]

Comment on attachment 383257 [details] [diff] [review]
Split insertHyphenatedWord into insertText and itself

This looks good! r=me

Comment 5

[James Ross]

Checked in --> FIXED.