October 2009 - Dillo-dev - lists.mailman3.com

Latest whitespace handling patches

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 28, 2009 at 10:18:25PM +0000, corvid wrote: > > Jorge wrote: > > > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > > > I could look at the possible spaces and select the one with > > > > the least-decorated style, perhaps. > > > > > > Now that you have this part of the code in your short-term > > > memory cells ;), please try to make a good link-underline test > > > page. If you can come up with a 100% solution it'd be great. > > > > I think it'll be a matter of what we want to define the solution as, > > for instance, whether there is a clear enough choice for > > <a ...>word </a><s> word</s>. > > If I put a space inside the A, I might want it, and I might not. > > I'm probably more likely to want it if it's a matter of > > U, S, or overline, and less likely to want it if it's from an A, > > but maybe that's too detailed and picky. > > In this case, the easy solution is to look what Firefox does. > For instance try the attached test page. Firefox seems to follow the original behaviour consistently :( I'm shocked by this because ff surely does whatever ms does, and so people must actually see all of those underlined spaces. It seems to me that if they saw them, they'd take them out. So I'll undo it.

Oct. 29, 2009

Latest whitespace handling patches

by jcid＠dillo.org

On Wed, Oct 28, 2009 at 10:18:25PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > > I could look at the possible spaces and select the one with > > > the least-decorated style, perhaps. > > > > Now that you have this part of the code in your short-term > > memory cells ;), please try to make a good link-underline test > > page. If you can come up with a 100% solution it'd be great. > > I think it'll be a matter of what we want to define the solution as, > for instance, whether there is a clear enough choice for > <a ...>word </a><s> word</s>. > If I put a space inside the A, I might want it, and I might not. > I'm probably more likely to want it if it's a matter of > U, S, or overline, and less likely to want it if it's from an A, > but maybe that's too detailed and picky. In this case, the easy solution is to look what Firefox does. For instance try the attached test page. -- Cheers Jorge.-

Oct. 29, 2009

Latest whitespace handling patches

by corvid＠lavabit.com

Jorge wrote: > On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > > I could look at the possible spaces and select the one with > > the least-decorated style, perhaps. > > Now that you have this part of the code in your short-term > memory cells ;), please try to make a good link-underline test > page. If you can come up with a 100% solution it'd be great. I think it'll be a matter of what we want to define the solution as, for instance, whether there is a clear enough choice for <a ...>word </a><s> word</s>. If I put a space inside the A, I might want it, and I might not. I'm probably more likely to want it if it's a matter of U, S, or overline, and less likely to want it if it's from an A, but maybe that's too detailed and picky.

Oct. 28, 2009

Latest whitespace handling patches

by jcid＠dillo.org

On Wed, Oct 28, 2009 at 06:31:56PM +0000, corvid wrote: > Jorge wrote: > > One of the few regressions I've noticed is extra underlining of > > links (the space before the first word's letter). As in: > > > > http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 > > More like a...shifting of the unpleasantness. > > We had lots of cases of "<a ...> word </a> word" > that underlined the space following the link. > Now we have some "word <a ....> word</a>" > that underline the space preceding the link. I remember thinkering on this bug several times. That's why I'm happy this is getting a cleanup! > I could look at the possible spaces and select the one with > the least-decorated style, perhaps. Now that you have this part of the code in your short-term memory cells ;), please try to make a good link-underline test page. If you can come up with a 100% solution it'd be great. -- Cheers Jorge.-

Oct. 28, 2009

Latest whitespace handling patches

by corvid＠lavabit.com

Jorge wrote: > One of the few regressions I've noticed is extra underlining of > links (the space before the first word's letter). As in: > > http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 More like a...shifting of the unpleasantness. We had lots of cases of "<a ...> word </a> word" that underlined the space following the link. Now we have some "word <a ....> word</a>" that underline the space preceding the link. I could look at the possible spaces and select the one with the least-decorated style, perhaps.

Oct. 28, 2009

Latest whitespace handling patches

by jcid＠dillo.org

Hi, The latest cleanups and whitespace handling patches have come like a fresh breeze removing unnecessary code. They're good for better code clarity. One of the few regressions I've noticed is extra underlining of links (the space before the first word's letter). As in: http://www.dwheeler.com/blog/2009/10/27/#dod-oss-2009 BTW, I'm close to commiting the DPIP changes. Hopefully near this month's end. -- Cheers Jorge.-

Oct. 28, 2009

Re: NULL for default tag close?

by jcid＠dillo.org

On Tue, Oct 27, 2009 at 05:09:37PM +0000, corvid wrote: > Would it be all right if I changed the default_close()s to NULL? > I think it makes Tags[] easier to read, I'd prefer it as is for the same reason! :-) > and testing for NULL would > mean less time calling an empty function anyway... I'd be surprised if the gain is more than 0.1%. BTW, today in one part of the DPIP code I found that avoiding thousands of read() calls made no noticeable difference. With write() it was a different story though. Most probably gcc optimizes out empty functions too. -- Cheers Jorge.-

Oct. 27, 2009

Re: link signal emission from layout?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Oct 24, 2009 at 03:48:55PM +0000, corvid wrote: > > I never liked all of the connectSignals() for all of the > > textblocks and images and whatever else in html.cc. > > Why not? So much signal connection for the listitems and the tablecells and everything, and all redundant, since it's all going back to the same receiver in html. > > Would you have any opinion about moving the > > (perhaps increasingly-inaccurately-named) > > link signal emission to layout? > > Could be. > > > I was just playing with the idea, and, at least after > > a moment's test :) , it seemed to be working. > > And, as a bonus, it lets me pop up menus when > > pressing button 3 below the bottom of page content. > > I miss this feature. Also being able to popup a menu over > a bare image would be a plus. Random thought: it would nice if there were a mechanism to change the size of images. > > (I left the event emitter alone for the moment, but I > > think the only thing using it right now is plain.cc. > > If so, it would be nice to rip that out in any case, > > even if plain doesn't have "links" exactly...) > > I don't know why it's currently done in html.cc, maybe it's > just grouping by required functionality, maybe not. If the new > approach is simpler and provides the same and more as you > pointed, id say: +1. It's simpler for src/, but the ickiness is preserved for dw/, since what was excised from Widget gets implanted into Layout. > BTW, please move this thread to dillo-dev.

Oct. 25, 2009

[patch]: fix w3c_plus_heuristics=NO

by onepoint＠starurchin.org

Jorge Arellano Cid wrote: > ... that part of the code had always been tricky and the patch looks > like a big boolean algebra simplification that makes it much easier > to undersatand. I think we can do more to make it easier to understand. Here's a patch that separates the code that does the cleaning up from the logic that decides what to do. Regards, Jeremy Henty

Oct. 21, 2009

[patch]: fix w3c_plus_heuristics=NO

by jcid＠dillo.org

On Sun, Oct 18, 2009 at 11:35:43AM +0100, Jeremy Henty wrote: > > As I understand it, the purpose of the w3c_plus_heuristics preference > is to control whether Dillo will force close some tags when it sees an > unmatched close tag. But it seems to have no effect! If you try this > HTML: > > <html> > <head><title></title></head> > <body> > <p> > <table><tr><td><s></table> > </body> > </html> > > then the <s> tag is closed no matter what w3c_plus_heuristics is! > > The bug is in Html_tag_cleanup_at_close() in html.cc, in this code: > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > ((w3c_mode && > Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || > ((!w3c_mode && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel))) { > --stack_idx; > } > > The indentation makes it appear that the comparison between the > TagLevel fields is bracketed with !w3c_mode but both the indentation > and the bracketing are wrong. In fact this code is equivalent to: > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > ((w3c_mode && > Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O') || > (!w3c_mode && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O')) || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel)) { > --stack_idx; > } > > which is in turn equivalent to > > /* Look for the candidate tag to close */ > stack_idx = html->stack->size() - 1; > while (stack_idx && > (cmp = (new_idx != html->stack->getRef(stack_idx)->tag_idx)) && > (Tags[html->stack->getRef(stack_idx)->tag_idx].EndTag == 'O' || > Tags[html->stack->getRef(stack_idx)->tag_idx].TagLevel < > Tags[new_idx].TagLevel)) { > --stack_idx; > } > > so that w3c_mode has no effect. In other words w3c_plus_heuristics is > effectively always YES, even if dillorc says otherwise. > > I have attached a patch that implements (what I *think* is) the > correct behaviour. Committed! Thanks Jeremy, that part of the code had always been tricky and the patch looks like a big boolean algebra simplification that makes it much easier to undersatand. -- Cheers Jorge.-

Oct. 20, 2009